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.
signature.asc
Description: Message signed with OpenPGP using GPGMail