I'm sorry you see these explanations as whining. I believe that we have to recognize that part of our problem is how WGs operate before we can be willing to solve that problem. So I try to describe that problem in a way that people will recognize it. Maybe people already realize that we have this problem and I don't actually need to illustrate it.
As for solutions - I have been thinking about possible solutions for several years. But I'm much better at protocol engineering than I am at engineering management or social structures, so I don't have much confidence in my ideas for how to solve the problem.
Recently I've begun to suspect that a good answer to some of these problems might involve a layer of management between IESG and working groups - a set of people who had responsibility to give some technical oversight to working groups, monitor their progress, and keep the ADs up-to-date on the state of things. I say "oversight" rather than "direction" because "direction" would be too strong a term. I don't see the supervisor (let's call him a supervisor for now) telling the group what technical decisions to make. I do see the supervisor making sure that the group investigates important issues - setting short-term milestones and an agenda for the group.
What I'm thinking is that the person in charge of supervising a WG ends up consulting with the chair and/or document authors on a regular basis (say, every three or four weeks) and agreeing on the next set of near-term goals and deliverables for that WG. The supervisor might say "you need to understand and document the nature of the disagreement between these two concerns" or "you need to pick a mandatory-to-implement encryption algorithm", or "you need to solicit cross-area review for this issue" or "you need to analyze whether this ABNF grammar can be implemented with only one symbol of look-ahead" or "defer that question for now, the thing you have to decide before you do anything else is how much you are going to constrain yourself to be backward compatible with this legacy protocol that we all know is broken".
As I see it, the supervisor would offload some of the present Chair's duties and some of the present Responsible AD's duties. The chairs would still be responsible for managing the group discussion and making sure process rules were followed. The ADs would still approve charter changes (overall goals, long-term milestones), review documents before publication, and be the first level of appeal.
The supervisor would try to make sure that important issues were identified and dealt with early, and in plenty of time to get them resolved before the specification is finalized; he would also make sure that measurable progress was being made every few weeks and report progress or lack thereof to the AD.
Another part of the supervisor's job would be to ensure that when the document finally goes to IESG, neither the WG nor the IESG are surprised by how the other reacts to it. Along with the specification presented to IESG should be supporting material to give the IESG confidence in the document, for example: a list of goals and requirements (written before the specification); a list of changes to those goals and requirements with the rationale for each change; a list of issues and contentious design choices that arose, how each was resolved, and why; what kinds of review the specification was subjected to, the results of that review, and what changes (if any) were made based on that feedback; documentation of any analysis that was done on the protocol; description of early implementations (prototypes) and how they differ from the final specification. This material would take the place of the "writeup" that an AD is now expected to do before a document from his working group goes to IESG ballot.
Similarly for face-to-face meetings - the Chair would preside, but the supervisor would work out the agendas of face-to-face meetings in consultation with the Chair. The meeting time would be used to reach closure on divisive issues.
The supervisor would be expected to NOT have a strong interest in the outcome of the WG (other than to see that quality work is done), nor to closely follow or regularly participate in group discussion. His job would be to keep a higher-level perspective on things. When identifying issues that must be resolved he could state an opinion but must clearly separate his opinion from the description of the issue. WGs would be allowed to "push back" on an issue definition if they thought it unreasonably constrained the resolution, and suggest an alternate way of framing the issue.
The concept of Technical Supervisors could be tried on two or three working groups and refined based on experience. Initially the supervisors might be appointed by the AD and confirmed by IESG; eventually there might be a separate mechanism for nominating and vetting potential supervisors. Ideally a working group would keep the same supervisor as long as it is chartered, though it would be possible to change a WG's supervisor - particularly one who wasn't doing his job well.
Supervising a WG shouldn't require more than say 2 hours per week.
There would need to be some way to recognize the contributions of WG supervisors, and perhaps some incentives for taking on a job with low visibility and minimal creative input.
--
so there you have one half-baked idea. I'm sure it's not too difficult to poke holes in it, but I think it's a more promising avenue of inquiry than one which tries to move the final technical review outside of IESG. In a world with technical supervisors, the IESG mostly continues to do what it is doing now, but its job should get easier because it will get better specifications and more supporting material with which to evaluate the specifications. it might let the IETF grow larger because ADs will be able to spend less effort keeping up with their working groups' progress and less effort reviewing documents - IESG's workload would be more closely related to the number of documents reviewed than the number of working groups.
Keith
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf