ietf
[Top] [All Lists]

Re: IETF areas re-organisation steps

2014-12-26 11:47:20
Hi Michael,

On Fri, Dec 26, 2014 at 12:06 PM, Michael Richardson 
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:


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

Jari Arkko <jari(_dot_)arkko(_at_)piuha(_dot_)net> 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?


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


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


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



    > 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  [
]     mcr(_at_)sandelman(_dot_)ca  http://www.sandelman.ca/        |   ruby on
rails    [