Re: IETF areas re-organisation steps

[Michael Richardson <[e-mail]>]

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

Jari Arkko <[e-mail]> 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.
...

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

Good... 

    > 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

I think that this is perhaps the most important result.

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

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>

    > 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

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  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [