Subject: IETF areas re-organisation steps

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Dec 2014 21:16:26 +0200

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: Robert Sparks <[email-masked]>
Date: Fri, 26 Dec 2014 10:27:03 -0600

I have several reactions to this, but one in particular I wanted to get 
into the conversation early.

Why did you settle on a proposed name for the combined upper-layers area 
that implies it will be sleeping?

This is more than just trying to pick a nit on the name. The IESG 
certainly couldn't have collectively missed that interpretation.

I'm surprised at the message this seems to be sending - can you share 
more about what the group has been discussing and thinking that led to 
this choice?

I would think it would make getting ADs even harder to be asking 
companies to sponsor an AD of napping.

RJS

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Dec 2014 11:41:25 -0500

On Dec 26, 2014, at 11:27 AM, Robert Sparks <[email-masked]> wrote:
> Why did you settle on a proposed name for the combined upper-layers area that implies it will be sleeping?

Napt is past tense.   It foreshadows a refreshing awakening, not sleep.

> I would think it would make getting ADs even harder to be asking companies to sponsor an AD of napping.

We could choose a different name.   How about Transport, Applications and Realtime (TAR)?

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 26 Dec 2014 17:47:38 +0100

> We could choose a different name.   How about Transport, Applications and Realtime (TAR)?

When TAR becomes warm or hot it will be sticky and slows down progress...

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Dec 2014 08:48:08 -0800

> We could choose a different name.   How about Transport, Applications and Realtime (TAR)?

Probably ought to rank the sequence by the amount of activity in each.
That's probably realtime, application, transport...

More generally, I'm impressed to find out that transport and apps have
so much in common, given how little interaction the two areas have had
over the years, in spite of explicit efforts.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 26 Dec 2014 08:50:37 -0800

> Why did you settle on a proposed name for the combined upper-layers area that implies it will be sleeping?

+1

> This is more than just trying to pick a nit on the name. The IESG certainly couldn't have collectively missed that interpretation.
> 
> I'm surprised at the message this seems to be sending - can you share more about what the group has been discussing and thinking that led to this choice?
> 

It would also be harder to get new participants to want to come to the IETF.

Maybe we can take a short hiatus from our relentless cute naming and call it what it is: UPPER.

--Paul Hoffman

---

From: Steve Crocker <[email-masked]>
Date: Fri, 26 Dec 2014 11:50:55 -0500

From http://en.wikipedia.org/wiki/Nap_(textile)

> Primarily, nap is the raised (fuzzy) surface on certain kinds of cloth, such as velvet.

Not a bad analogy for the upper layers of the protocol stack.

Steve

On Dec 26, 2014, at 11:27 AM, Robert Sparks <[email-masked]> wrote:

> I have several reactions to this, but one in particular I wanted to get into the conversation early.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Dec 2014 11:57:24 -0500

> When TAR becomes warm or hot it will be sticky and slows down progress...

On the contrary, TAR is the glue that binds the internet together!

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Dec 2014 12:06:56 -0500

[I guess maybe future discussion might call this the "Xmas IESG Reorg"?]

Jari Arkko <[email-masked]> wrote:
    > 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.

I think that this is good.
...

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

Good... 

    > 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

I think that this is perhaps the most important result.

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

I'm a little bit surprised that the RTG area load has gone up like this,
and so quickly.  Is it the various SDN things that are pushing this, or is it
that the RTG area currently has the most enthusiasm for YANG work?

<nomcom hat>
I want to note to the community that the list of RTG AD candidates is large
and highly qualified. Will the desired qualifications change in any way?
Will the community need a chance to provide further feedback on this?
When will the IESG make this decision?
</nomcom hat>

    > 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

Oh, please can we call it the "Network Working Group" :-)

seriously: I think that this is a great idea.
I'm curious if over time the four/five ADs would wind up specializing
(SIP things, email things, web-things, congestion-related things), or
if the Home AD for would be intentionally mixed up so as keep silos from
forming.

I imagine the various directorates will remain.
I suggest that the WGs remain "affliated" to directorates, and we may want to
create more of them, and that perhaps, in general, that WGs will affliate to
areas identified by directorates rather than by ADs.

THIS AFFLIATION might be prove useful and important when doing meeting scheduling.

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

I would raise the possibility that the fifth ADs' role could be that of
either "IETF Chair-in-training" or "past-IETF Chair", and that the process of
succession planning for IETF Chair could perhaps be made more explicit.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Dec 2014 12:12:29 -0500

> area that implies it will be sleeping?

Good question.
I figured "NetAPP" was taken :-)

Here is perhaps the worst alternative I can think of:
    Networked Applications and Transport (NAT).

and yet...

I too would like a more inspired name.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Scott Brim <[email-masked]>
Date: Fri, 26 Dec 2014 12:16:22 -0500

> On the contrary, TAR is the glue that binds the internet together!

Do not underestimate the power of the dark side.

---

From: Ole Jacobsen <[email-masked]>
Date: Fri, 26 Dec 2014 09:20:22 -0800 (PST)

Could we maybe start doing them in reverse: RAT or TAN?

Ole J. Jacobsen
Editor and Publisher
The Internet Protocol Journal
Office:  +1 415-550-9433
Web: protocoljournal.org
E-mail: [email-masked]
E-mail: [email-masked]
Skype: organdemo

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Dec 2014 09:25:40 -0800

> Maybe we can take a short hiatus from our relentless cute naming and call it what it is: UPPER.

That's reasonable.

An alternative that is equally un-cute but highlights one of the more
salient aspects of this realm of work:

   End2End (E2E)

The technologies in this new area all reside in the end systems, rather
than the underlying packet-switching infrastructure.

d/

---

From: Alia Atlas <[email-masked]>
Date: Fri, 26 Dec 2014 12:46:54 -0500

Hi Michael,

> that the RTG area currently has the most enthusiasm for YANG work?

It's a mixture of things combined with RTG already being at the very top
edge
of workload.  In RTG we have/will have about 21 active WGs; if we add a
third routing AD,
then RTG will absorb 3 WGs from INT.  Granted that one is not active and may
be merged in, we are still looking at about 23 WGs for RTG with a more
average
load being about 8 WGs/AD.

Of course, in the next two years, it is likely that at least a couple WGs
will close.
The load from YANG work may decrease and regardless, the structure being
well established should reduce the work.

Between these three factors, a third routing AD would be quite useful in
making
the load more reasonable - possibly down to a theoretical 80%.

> When will the IESG make this decision?

Obviously, the IESG is soliciting feedback from the community now; I expect
that process to continue until mid-January.

I am quite aware that we have lots of excellent routing AD candidates this
time.
I personally do not see a reason to change the desired qualifications.

Regards,
Alia

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Dec 2014 08:40:22 +1300

On 27/12/2014 06:46, Alia Atlas wrote:
...
> It's a mixture of things combined with RTG already being at the very top edge
> average load being about 8 WGs/AD.

So let's be frank about this. Today (excluding the General Area AD
with his crippling load of 1 WG) we have 129 WGs for 14 Ads,
which is 9.2 WGs/AD. That is clearly too many, so should there
be a target ratio and a plan for reaching it?

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 26 Dec 2014 19:52:01 +0000

> be a target ratio and a plan for reaching it?

I don't think so. There are just huge differences in how different
WGs impinge on AD workload. I think we should look to try to spot
any imbalances that exist and adjust where needed. We do that already
within the SEC area, and ADs in other areas also do, but I don't
think we can use a number-of-WGs-per-AD metric except as the most
coarse grained measure. (And the out-of-area AD thing gives us
another tool to balance workloads.)

S.

---

From: Alia Atlas <[email-masked]>
Date: Fri, 26 Dec 2014 14:59:00 -0500

Hi Brian,

> be a target ratio and a plan for reaching it?

No, as you well know, it depends on the size and business of the WGs, the
management load, etc., as well as the number.  Clearly we don't want to not
create new WGs when appropriate nor to discourage existing useful work.
This is a question of balancing load and there is a surge of YANG-related
work
which does require more focused management.  Is it better to have 2 ADs at
100%-120% and others with less load when the size of the IESG would be
otherwise
reduced.  Are you suggesting that suggesting another routing AD to take
load from RTG and INT
is a bad idea compared to dropping the IESG to 14 & eventually 13?

Are you simply concerned with the dynamics of how many ADs have the various
perspectives on the IESG?

Obviously, we are looking for feedback and opinions and ideas.  Do you have
other
well thought out suggestions?

Regards,
Alia

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 26 Dec 2014 20:16:48 +0000

> than the underlying packet-switching infrastructure.

But where do the endpoints lie?

The funny thing about the mail system we are using for this conversation is
that it is not end-2-end. The application endpoints are mail clients and/or
Web browsers. There are multiple transport endpoints, the inbound and
outbound MTAs, spam filters, the list serve...

When we get into the trust and security issues the endpoints are people and
organizations, not machines.

I see a division between two types of 'applications' work. One is work
defining actual applications. Things like Jabber, Mail, Minion Rush, Chat,
etc. In the early days of the Internet, the IETF had 100% of the
applications work. Today there are tens of thousands of applications in
widespread use. It is clearly beyond the capacity of the IETF to support
development of all such protocols even if it tried.

The other type of applications work is to provide standardized
infrastructure that can be used to build applications. So just like there
are standards for screw sizes, pitches, heads, etc. and these are vitally
important to people who make cars, boats and airplane engines, there should
be standards for applications infrastructure, like how to map an API to a
JSON based Web Service.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 27 Dec 2014 11:22:16 +1300

Hi Alia,

On 27/12/2014 08:59, Alia Atlas wrote:
>> On 27/12/2014 06:46, Alia Atlas wrote: ...
>>>> I'm a little bit surprised that the RTG area load has gone up 
>>>> like this, and so quickly.  Is it the various SDN things that 
>>>> are pushing this, or is it
>>> It's a mixture of things combined with RTG already being at the 
>>> very top edge of workload.  In RTG we have/will have about 21
>>> active WGs; if we add a third routing AD, then RTG will absorb 3
>>> WGs from INT. Granted that one is not active and may be merged
>>> in, we are still looking at about 23 WGs for RTG with a more
>> which is 9.2 WGs/AD. That is clearly too many, so should there be
>> a target ratio and a plan for reaching it?
>> 
> 
> No, as you well know, it depends on the size and business of the
> WGs, the management load, etc., as well as the number.  Clearly we
> don't want to not create new WGs when appropriate nor to discourage 
> existing useful work.

Of course, an average is only an average, but the point is: we've
had about 125 WGs for at least ten years now, and we've had
over-burdened ADs for all that time. That seems to be a fundamental
problem, regardless of the sort of adjustments the IESG is currently
proposing.

There are two words in your second sentence above implying a value
judgment: "appropriate" and "useful". Unfortunately, as far as I can
tell, the only way to truly manage the IESG workload is by raising
the bar for "appropriate" and "useful". (The same applies to
the bar for a WG to adopt a particular work item.)

> This is a question of balancing load and there is a surge of 
> YANG-related work which does require more focused management.  Is it 
> better to have 2 ADs at 100%-120% and others with less load when the 
> size of the IESG would be otherwise reduced.  Are you suggesting
> that suggesting another routing AD to take load from RTG and INT is a
> bad idea compared to dropping the IESG to 14 & eventually 13?

No, I was specifically trying to avoid being specific. I think we have a
general long-term problem.

It's entirely appropriate for the IESG to propose workload re-balancing
to deal with the current workload. I may have some quibbles, but it's the
IESG's decision.

> Are you simply concerned with the dynamics of how many ADs have the 
> various perspectives on the IESG?
> 
> Obviously, we are looking for feedback and opinions and ideas.  Do 
> you have other well thought out suggestions?

In terms of the long-term problem, unless I am mistaken, neither the IESG
nor the community has ever said much about how to make the judgment calls
that new work is useful and appropriate for the IETF. We've got a very
good document to help BOF proponents (RFC 5434) but I don't think we've
ever tackled the next bit: deciding whether this work should be chartered?

One result of that is that proponents who have what they think is a
successful BOF are sometimes very puzzled and frustrated by their
failure to form a WG. Another result is that it's a bit harder for
the IESG to say "no" than it would be if the decision criteria were
a bit more transparent. A third aspect is that every new IESG member
has to discover for herself how this vital bit of the process works
on the inside.

I think my suggestion is that to have any serious hope of controlling
the workload *in the long term*, we need to have something (it could be
an IESG statement, it could be an RFC) the stakes out a position on
what it means for a WG or work item to be judged appropriate and useful.

Regards
   Brian

---

From: Ted Hardie <[email-masked]>
Date: Fri, 26 Dec 2014 17:24:23 -0800

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 <[email-masked]> wrote:

> evolves.
> should
> [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: Sat, 27 Dec 2014 03:27:55 +0200

> another tool to balance workloads.)

Which I think is the point - the proposed re-organisation is largely about the IESG becoming more flexible. We need that flexibility to tune our operations to the current topics today and in the future.

Also, there’s another question about what the proper workload is for an AD, and a third question about ways in which we can move more of the IESG work to WGs. Those are important questions, too, but we still need the flexibility to address topics as they grow and shrink.

Jari

---

From: Alia Atlas <[email-masked]>
Date: Sat, 27 Dec 2014 00:52:20 -0500

Hi Brian,

> problem, regardless of the sort of adjustments the IESG is currently

Absolutely - and in that regard, this reorganization is just working on
better
balancing the existing load among the IESG.  We are also trying out some
ideas, such as the cross-area shepherding AD, to see how well they can
work for better balancing between ADs while leaving areas intact.  Areas
have impact for whom participates, what WGs are seen as relevant or
connected to another, and generally lots of the community and people
aspects.  It's the document reviewers, authors,editors, WG chairs,
directorates, and all those who volunteer to do work who make the IETF
work - and to ignore those dynamics to make the IESG's job easier would
be a mistake.

> the bar for a WG to adopt a particular work item.)

There are a few things we can do.  Some things that I've been trying to
do in Routing include:
  a) discouragement of progressing many use-case and requirements drafts.
      We had drifted towards having WGs producing some to help articulate
what
      needed to be done - but then more and more appear and only some
      actually provide more useful feedback to the architecture or
protocol.  I
      would rather see WGs produce things that can be implemented with the
      necessary context than spend years working on use-cases and
requirements.
      I'm past the waterfall model of software development.

  b) Encourage WG chairs to think about the need for ACTIVE consensus rather
      than passive.  If there isn't the enthusiasm to review and improve a
draft or
      implement it, then does it really need to be an RFC?

  c) Better and early cross-WG review once a draft is adopted as a WG draft.
      Well-written drafts without serious issues are much faster to manage,
review,
      and progress.

  d) Be willing to let WGs fail - by also letting them just get on with
doing solutions.

I don't know how much those are raising the bar and how much those are
pushing
better process and more work back into the WGs.  I do think that (a) and
(b) may raise the bar in a way that I personally am comfortable with.  I'm
certainly
willing to listen and happy to hear other ideas.

It is tempting to think that poorly written and poorly reviewed drafts may
not
fall into the 'useful" camp, but that can vary based upon a WG and editors
losing
their energy and enthusiasm.  One of the worst parts there is really the
time it
takes when people don't consciously put in time to do the standardization
work;
an unstaffed project rarely completes quickly, after all.

> general long-term problem.

Yes - but which part of the elephant are you describing?  This load
rebalancing
may not be the only thing that the IESG considers - it is merely clear steps
to handle the immediate problem of workload re-balancing.

As one of those who was willing to admit that I could really do a better
job with
3/4 of the current workload, I'm a bit sensitive to considering the
generalities.

> ever tackled the next bit: deciding whether this work should be chartered?

Not that I know of, but so far, I'm not convinced that it would be feasible
to
clearly articulate and avoid unfortunate gaming.

> what it means for a WG or work item to be judged appropriate and useful.

Interesting - I was expecting to hear more about multi-level IESG or
off-loading
more work towards the directorate or WG chairs.

Thanks for the suggestion.  I'll certainly think about it more.

Regards,
Alia

P.S.  I'm another of those who is checking email sporadically during
vacation.
There's plenty of time for discussion in January too.

---

From: Melinda Shore <[email-masked]>
Date: Fri, 26 Dec 2014 21:24:23 -0900

On 12/26/14 8:52 PM, Alia Atlas wrote:
>       We had drifted towards having WGs producing some to help
> articulate what
>       than passive.  If there isn't the enthusiasm to review and improve
> a draft or
>       Well-written drafts without serious issues are much faster to
> manage, review,
>       and progress.
> 

These are all things I'd love to see implemented across the
organization, as well as raising the bar on BOFs - I've seen
some ADs put a massive amount of effort into BOFs that are
held around ideas that aren't fully-formed (it's not necessarily
that they're bad ideas, but rather the problem is that the
proposals are awfully immature).

I've been trying to decide what I think of the proposed
reorganization and I guess I'm neutral on it - it seems that
the workload problem isn't necessarily going to go away with
a reorganization, but that the two problems (structural
efficiency and manageable workload) would need to be
tackled in parallel.  I think Alia's list is a good start
on the workload issue.

Melinda

---

From: "Eggert, Lars" <[email-masked]>
Date: Sat, 27 Dec 2014 09:26:55 +0000

On 2014-12-27, at 03:24, Ted Hardie <[email-masked]> wrote:
> 
> 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.

+1

Will have more feedback after the holidays.

Lars

---

From: Nico Williams <[email-masked]>
Date: Sun, 28 Dec 2014 03:20:12 -0600

On Fri, Dec 26, 2014 at 05:24:23PM -0800, Ted Hardie wrote:
> that well thought out.  [...]
>                                                        [...].  Why it is
> valuable.  [...]

That's my take as well: if formal areas are too difficult to manage,
then get rid of them altogether as a formal organizing principle.

One concern that might come up then is: will each assignment of an IESG
members (no longer "ADs") to WGs become a matter of debate for the IETF?
That would be death by a thousand paper cuts.

IMO: lose areas as a formal organizing principle, design a light-weight
process for "AD" assignments to WGs, move on.

'Areas' as an organizing principle are... distracting -- at least some
areas that exist or are being proposed are.  I rougly know what areas
named "transport" or "security" are and what fits there.  But then you
look at the details and oddities pop up.  Just get rid of them.  But
keep the directorates!

Nico
--