Subject: IETF areas re-organisation steps

From: IETF Chair <[email-masked]>
Date: Thu, 8 Jan 2015 13:00:08 +0200

This message was originally sent during holidays, but I was asked to
re-send it now that most of us are back in the office.

Dear Community:

In October, we let you know that we would be coming up with some proposals
and consulting with you on the topic of re-organizing the IESG and the IETF 
areas with the intent to increase flexibility as IETF work evolves, to ensure that
all IETF work is covered by an AD, and to balance and reduce the workload
across the ADs [1]. We committed to developing a re-organization proposal by
May 2015 (thus including ADs that will be newly seated in March 2015). We
have taken several steps since then toward that goal: we recommended that the
nomcom not to fill the APP AD vacancy in the current nomcom cycle [2], and we
are taking steps to redistribute workload in order to allow for more resources
to be focused on YANG model coordination [3].

This message provides an outline of further steps we propose to take in 2015
as part of the re-organization and invites community feedback on those steps.
Step I below is already in progress. Step II in particular requires timely
action, and therefore we are requesting community feedback by January 15,
2015 on that step in particular and on the overall proposal.

None of the steps below should be viewed as permanent or overly constraining
how the IESG and the areas might be organized in future years. In general we’d
like to increase the ability for the IESG to be flexible going forward. We are
suggesting the steps below as measures to experiment with as a means to
determine their effectiveness. The IESG intends to continue to re-evaluate all
of the steps on a regular basis.

PRINCIPLES

The IESG believes the re-organization should proceed according to the
following principles:

1) Agility: The IESG should be able to adapt as Internet engineering evolves.
When work focus shifts and new technologies emerge, it is critical that the
the IESG can follow the shift and effectively manage the new work.

2) Relevance: The organization of the technical work must facilitate the
IETF's continued relevance to the industry. As we change how we develop
technology throughout the Internet, the IETF must be able to change how our
standards development works with the technology development.

3) Flexibility: The organization of the IESG and of the technical areas should
accommodate variations in workloads, time commitments, and AD skillsets, as
well as changes in those over time. It is important to make it possible for
more IETF participants to be able to serve as Area Directors and to make the
work co-exist with their normal jobs.

4) Sustainability: The Area Director role should be a position that
accomplished engineers aspire to and that employers want to support. We should
emphasize the "steering" and "director" aspects, supporting and guiding the
technical work in the working groups.

THREE STEPS

We suggest taking the three steps described below to fulfill these principles.

I.  FURTHER SHIFTING OF WG RESPONSIBILITY TO OUT-OF-AREA ADS

The ability to react to changes in the industry, for example the IESG YANG
Model Work Redistribution [3], requires flexibility within the IETF leadership
positions. There are numerous instances where the constituency of a WG exists
in a particular IETF area, but the most appropriate AD for that work happens
to be in a different area, or where the ADs in the area are simply overloaded
and an AD outside of the area is perfectly capable of managing the work. To
address these possibilities, the IESG is moving towards a model where a WG can
exist in one area, but its shepherding AD comes from another area. This
flexibility will allow the IESG to apply its skills where they can be of most
use while still keeping related WGs together within an area. The IESG proposes
to experiment with this approach initially by shifting to out-of-area ADs for
RADEXT, DIME, LMAP, and ANIMA, perhaps with another few WGs to follow.

In order to achieve the above, there is some tools development work needed.
Many components of the IETF tool set (e.g., the datatracker) make assumptions
about WG/AD relationships based on the WG's assigned area. That issue is
currently being worked on by the tools team, but will take a few months' time.
During this intermediate period (prior to the tools work completing), the
cross-area shepherding effort will be done informally by the IESG. This
informal approach will address:

a. Shepherding AD - Each WG will still have an AD assigned to it from its
area, referred to as the Home Area AD. The actual shepherding AD will be
temporarily listed as the Technical Advisor. The shepherding AD will be in
charge of all WG management issues. The IESG will develop a way to explicitly
indicate the shepherding AD on the WG's charter page.

b. E-mail aliases - WG chairs and participants who wish to reach the ADs for a
WG via the <foo>-ads tools aliases should explicitly include the AD listed as
Technical Advisor for the WG.

c. Document shepherding - When a WG chair submits a publication request, that
request will flow to the Home Area AD. The Home Area AD should then delegate
shepherding responsibilities to the shepherding AD for handling.

d. Appeals - IETF participants should be directed to send any appeals related
to the WG to the shepherding AD rather than the Home Area AD.

II.  ADDING A THIRD RTG AD

The IESG is considering requesting that the currently seated nomcom select an
additional routing AD, such that two new routing ADs, rather than one, would
be seated for two-year terms in spring 2015. The reasoning behind this request
is that the load in the RTG area is currently unsustainably high. The
placement of a third AD will have the effect of spreading that load such that
the time requirement may now be more consistent with the work loads of ADs in
other areas. The total number of ADs on the IESG would not change if the APP
seat remains vacant.

This request is further justified by the considerable increase in
management-related work in the RTG area. Specifically, there are a lot of new
YANG models being written. Although the coordination of YANG across the IETF
falls as the responsibility of the OPS ADs (specifically the Management AD) it
is expected that the RTG ADs will need to work on an increasing number of YANG
documents as well.

If an additional RTG AD were to be seated, the IESG would propose to move
three working groups from the INT area to the RTG area to balance AD loads:
L2TPEXT, LISP, and TRILL.

As with all of the proposed organizational changes, the IESG would expect to
re-evaluate the need for this third RTG AD in future years and balance that
need against the need to have other skill sets or more generalist roles
represented on the IESG.

Work is underway to create support for this model in our process documentation:
http://tools.ietf.org/html/draft-dawkins-iesg-one-or-more-04.

III.  MERGING OF UPPER LAYER PROTOCOL AREAS

As previously noted [1], a significant amount of the work that is going on in
the APP area pertains to the web protocols, but that has a good deal of
crossover with work in RAI. There is also some crossover work between the APP
and TSV areas. To accommodate these overlaps and provide better WG management
across these three areas, the IESG is proposing to merge the APP, RAI, and TSV
areas into one combined Network Applications (NAPP) area. From March
2015-March 2016, this combined area would be overseen by the five remaining
ADs from APP, RAI, and TSV, with some redistribution of WG shepherding
responsibilities among them to balance workloads. DISPATCH, TSVWG, and APPSAWG
would continue to function much as they currently do.

The NAPP ADs would continue to encourage progress towards closure of the many
WGs in the area that are close to completing their chartered work. As such,
the IESG would expect to request in the 2015-16 nomcom cycle a reduction in
NAPP AD headcount, yielding four seated NAPP ADs starting in March 2016. If
possible, we could reduce down to 4 NAPP ADs prior to that time and re-assign
the fifth AD’s duties to further help balance IESG load.

Jari Arkko for the IESG

REFERENCES

[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13314.html 
[2] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13364.html 
[3] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13576.html

---

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Jan 2015 11:54:07 -0800

Jari,

Thanks for re-posting this and for the community engagement on the topic.
Some comments below.

> The IESG believes the re-organization should proceed according to the
​Are these roughly in order of importance to the IESG?  If so, I think
the order is wrong.  As relevance here means "doing good work people use"
and maybe even "doing the work only this organization can do", it has
to come first.  After that, I'd put sustainability, since the ability to
continue to do that work is supported by it.  ​

> RADEXT, DIME, LMAP, and ANIMA, perhaps with another few WGs to follow.
​So, I think this increasing your flexibility, but does nothing much for
sustainability.
You still are having the same pool of bodies do the work, simply taking AD
capacity
from one area and using it another.  That may be nice, but it increases the
level of cooperation needed between the area management and the visiting
ADs, so it is really only a marginal gain even for the area getting the
outside talent.

To make a dent in this, you actually have to increase the number of bodies
available to do the work.  And to do that, you have to reformulate some of
the
work so that bodies who do it don't have to have the tag AD.  (The document
shepherd opening up to non WG chairs is a good example here).​

​I'm really hesitant to support tool development work here until the bang
for
the buck here is larger.  Formalizing a method for robbing Peter to pay Paul
isn't much ​to get excited spending money on.

> need against the need to have other skill sets or more generalist roles
​This justification seems to hint at a "Model Language AD" who
can serve the whole IETF as a shepherd of YANG work across areas.
Why is that not a better answer here?

Noting that you are short of routing AD attention and shifting other
work into the area after fixing that problem also seems to ignore the
"out of area" AD mechanism introduced above--why is that not
sufficient?  I also note that the proposed shift changes the useful
skillsets for both routing and INT, and that doing so at this point in
the nomcom cycle isn't exactly optimal.

> the fifth AD’s duties to further help balance IESG load.
​So, I thoroughly agree that the name here is distractingly bad, but I
also believe that you're building the wrong bike shed.  As it stands,
coordinating
four or five people's schedules to have calls and agree on document
processing either
means a fairly large investment in time spent on Doodle polls or allowing
the area to have "mini-Areas" whose coordination remains loose. As
Robert Sparks pointed out, the failure to use common methods (like DISPATCH)
is going to run into trouble and exacerbate that.  ​

​There are a lot organizational principles possible here. RAI was organized
more or
less as a topic area with "all those things relating to Internet Telephony
(plus a few)"​
as the topic.  This meta-area doesn't seem to have such an organizational
principle,
and the "there are overlaps" argument doesn't seem that strong given the
large number
of _other_ overlaps.  I understand that folks are tempted by the "select a
bunch of generalists"
and let them work it out as a free-form approach to the AD job, and that
this could be
a mini version of that.   Personally, though,  I think having set areas
remains valuable, in
part because it shows how the overall organization understands the way the
work interconnects.
Putting too much in a single bucket muddies the interconnection into
incomprehnsibility,
at least to me.

To return a moment to the question of sustainability, I think the key
element is always offload.
When all the site selection and contract work left the IESG and was taken
up by the IAOC,
the IESG gained cycles over all.  That might have been hard to see at the
time because of
the overall transition, but it is obvious now.  I think the IESG might get
more bang for its
re-organizational buck if it focused on areas where its tasks could be
handed over to new
bodies.  As a very small example, if the conflict review work were done by
a different group,
with each area sending a delegate, would that hurt anything much?  Would it
gain any real
time?  This may be a small example, but I think the principle is
general--please focus on
areas where the IESG can differentiate its workload and then delegate the
bits that
can be done elsewhere.

My thanks again for the opportunity to comment,

Ted Hardie

> Jari Arkko for the IESG
>
>
> REFERENCES
>
> [1]
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13314.html
> [2]
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13364.html
> [3]
> http://www.ietf.org/mail-archive/web/ietf-announce/current/msg13576.html
>
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jan 2015 18:41:39 +0200

I wanted to provide a brief summary of various comments made in the discussion. Note that each of these has had some discussion, and there are responses in those threads. I have attempted to provide some answers below for the most clear cases. These answers are my personal view, and more IESG thoughts will be forthcoming.

PRINCIPLES

Is the order significant? (Ted H) Answer: no.

THREE STEPS

Will the proposal change time commitment for the ADs? I think the IESG might get more bang for its re-organizational buck if it focused on areas where its tasks could be handed over to new bodies. (Ted, etc) Answer: No, this is largely about having the right subdivisions within the IETF. The IESG recognises the need to push more work from the ADs to the working groups, but that is considered as a separate change. We will probably need both the right areas/flexibility, and handing off tasks to working groups and other entities.

A counter-proposal is to flatten the hiearchy. Lose the concept of areas, and consider the IESG as a group of people, each one assigned to the most appropriate task. (Nico) Answer: there is some value in the areas for both management and participants.

We should try reducing structure rather than adding to it, particularly if we are experimenting. (Nico)

The IESG proposal has the downsides of both Nico's proposal and the existing rigid system. (Andrew)

There is a too big overall workload in the IETF, would raising the bar for accepting work be useful? (Brian C) Answer: The IETF should do the work that needs to be done and is suitable for our experience base. If scalability is a problem, it would be better to find more scalable organisational models.

This should be an experiment, and there will be no shame in unwinding the change in a few months or a couple of years if it fails. (Brian C)

FURTHER SHIFTING RESPONSIBILITIES TO OUT-OF-AREA ADS

If we have a system of ADs managing WGs that are not in their area, it means that the assignment of areas is incorrect. (Brian C) Answer: Depends on whether you consider the areas to be primarily a feature for the IESG or the participants. For the participants, an area can make sense, even if it happens to be that the AD in charge of a WG is from another area, but just has the necessary knowledge to deal with this WG.

Does cross-area work need to be more explicitly noted in the descriptions (Dave)? Answer: yes.

IESG member assignments might become matters of IETF debate. (Nico)

ADDING A THIRD RTG AD

What is the term for 3rd RTG AD: shall this be 1, 2, or 3 years, and how do we ensure that on the average, we balance the requirement to select approximately half of the IESG every year? (Brian C, Michael R, etc.)

What are the qualifications expected from the 3rd RTG AD (Michael)? Answer: we have a proposal, and it will be close to what the current descriptions are.

MERGING OF UPPER LAYER PROTOCOL AREAS

How do the job descriptions change (Eliot, Ted H)? Answer: we have a proposal for the 3rd RG AD case, but the rest clearly needs work. New descriptions would be needed for the NAPP, even if much of the material can come from the existing ones.

The three area combination is too large and complex, and TSV is not a good match to the others; what benefit you expect to gain from creating a mega-area that offsets the resulting issues of focus, scheduling, and increased inter-AD communication required? How long would it take for the ADs in the big around to agree, or to communicate? (Brian C, Robert, Ted H, etc.) Answer: For at least a partial answer, see the mail from Alissa.

It is important the congestion control back-stop review still happens, even if TSV is combined into applications areas. (Brian T) Answer: Yes. The point about directorates and review teams focusing on transport issues is a good one.

How will the Dispatch WG be handled after the merging of RAI and other areas? Is there a conflict to what RFC 5727 defines for the DISPATCH process? (Olle, Robert) 

NAPP name is not good. (Robert) Answer: This is obviously a detail, but the name could be changed of course.

What does it mean for an area to be an area? (Yoav). Answer: Multiple things, it is a collection of work around a technology area or a topic. But it is also a set of working groups managed by the same area directors. Finally, areas are considered in scheduling sessions to avoid too much overlap within the same area.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Jan 2015 14:54:45 -0500

If the IESG should choose to eliminate Areas, the AD back-up supplied
by current arrangements could be provided by having a primary and
secondary Director for each WG.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 15 Jan 2015 15:50:43 -0500

On Thu, Jan 15, 2015 at 11:41 AM, Jari Arkko <[email-masked]> wrote:

> ...
> A counter-proposal is to flatten the hiearchy. Lose the concept of areas,
> and consider the IESG as a group of people, each one assigned to the most
> appropriate task. (Nico) Answer: there is some value in the areas for both
> management and participants.
>

We are (mostly) not managers (except reluctantly). And we are not the type
of managers that do major reorgs.

There are two main ways to organize a company, by function and by lines of
business. Most large companies tend to move from one to the other every 20
years or so. I asked a management specialist why they do it knowing that it
will be costly and both approaches have known flaws. The answer being that
the underlying objective is to stir things up and get different groups
talking to each other.

One constraint on the organization is that quite a few areas of Internet
technology require an incredible degree of domain specific expertise.
Application oriented folk such as myself really don't much care about
routing so long as Olafur and co keep feeding those pigeons.

We do have some cross-disciplinary groups - the IESG, IAB of course and the
Security Directorate.

I think we could do with more but I am not convinced organization gets us
there. After all, the fact that DPRIV is in Ops or whatever rather than
security really has no bearing on me as a participant.