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