Subject: RE: IETF areas re-organisation steps - TSV

From: "Black, David" <[email-masked]>
Date: Thu, 15 Jan 2015 19:55:19 +0000

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

>From my (TSV-centric) perspective, that mail's focus on the difficulty in
finding ADs seems misplaced.

I do hope that further IESG thoughts on this topic address the technical and
architectural rationale for TSV inclusion in the area merge, as well as the
underlying AD workload (and related employer support) problem that is a primary
cause of difficulty in finding TSV ADs (and is probably limiting AD candidate
pools elsewhere, albeit not to the extent seen in TSV).

I was pleased to see Jari's recognition of the importance of the AD workload
problem (http://www.ietf.org/mail-archive/web/ietf/current/msg91345.html), and
hope that there is more to come in addressing that.

Thanks,
--David

> -----Original Message-----
> From: WGChairs [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Thursday, January 15, 2015 11:42 AM
> To: ietf
> Cc: IETF WG Chairs
> Subject: Re: IETF areas re-organisation steps
> 
> 
> 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.
>