ietf
[Top] [All Lists]

Re: IETF areas re-organisation steps

2014-12-26 19:24:59
Hi Jari,

A couple of comments.  The first is that I am on vacation until the new
year, as are a lot of other people.  Having a major restructuring
discussion kick off in the time between Christmas and New Years seems
terribly unfortunate; there are a lot of folks who won't comment or will
have to join the conversation when it is mid-stream.  If it were being
presented as a *fait accompli,* it would look like a newsdump (releasing
information when it is guaranteed minimal attention); thankfully it is not
a *fait accompli*, but it is still very odd timing.  Please consider
re-sending this message again in early January, so that those folks who
declared an email bankruptcy know what is going on.  (Frankly, I will send
the message to get a few thoughts out and then disappear until January 2nd,
as I have family travel between now nd then.  I hope, though, that I will
not have to declare email bankruptcy.)

The second is that you don't do a very good job of tying together how the
proposed restructuring meets the goals set out, and that's unfortunate.
One of the most important goals, in my opinion, is making it possible for
folks to actually volunteer for the posts, which means reducing the overall
number of hours an AD must serve to do her or his job.  How this is meant
to achieve that goal or whether it isn't meant to is not really clear (I
had inferred it was a shared goal based on message 1 linked in your
message, but possibly wrongly so).  I would really like the IESG to explain
to the community the impact on that they believe this change will have on
time commitment and how it achieves it.

The third is that the proposal for a single mega-area that handles all
upper-layer protocols and transports does not strike me, personally, as
that well thought out.  The reality is that there are multiple contexts
within the upper layers and that the overlap those contexts have is often
at the border with the lower layers, rather than with each other.  The
result of that is that finding someone who understands the full context of
the work within the mega area will be difficult.  Within the APPs area that
used to result in the area having a "web AD" and a "messaging AD"; making
an upper layer body which then informally has a "web AD", a "messaging AD",
a "VoIP AD" and a "Transport AD" thus seems likely to result.  Why it is
better for that to be informal, rather than formalized into areas doesn't
get set out that well in the statement you've given, and if that isn't the
expectation, more explanation of how you expect that to work would be
valuable.  I'm also, frankly, concerned that it will look to the rest of
the industry like the IETF is minimize the importance of the work in those
contexts.  That would be a very bad result indeed.

As I said, I don't expect to read much IETF mail between now and January
2nd, but I hope that when you and the IESG return to this topic, you lay
out for the community in fairly blunt terms:

1) What the time commitment of ADs will be, post-change.

2) What skill changes in the AD requirements will be, post change.

3) 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.

Thanks for your efforts, and Happy New Year,

regards,

Ted Hardie


On Thu, Dec 25, 2014 at 11:16 AM, Jari Arkko 
<jari(_dot_)arkko(_at_)piuha(_dot_)net> wrote:

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