Keith, You've raised these points, over a number of years, but I wonder if it would be useful to explore implications of some of your comments: > 2. IESG's scaling problems are a direct result of low-quality output > from working groups, and we can't do much to address that problem > by changing how IESG works. > > 3. I don't think we can make IESG significantly larger, I don't think > we can dispense with final document review and keep document quality > up, and I don't think that additional reviewers can signficantly > relieve IESG of the need to do final review. I do think that > additional reviewers could be very valuable in giving WGs feedback from > early drafts, keeping them on the right track, and keeping IESG > informed about the status of the WGs. I also think that a document > that has enjoyed such review and feedback throughout its life cycle > will be much easier for IESG to review, and that (without any changes > to IESG's organization or process) it will be harder for IESG to reject > such documents without sound technical justification. Here, in the Problem WG and other places, you've raise the point that increasing the IESG probably won't help. You've implied that we probably have too many working groups and too many drafts in the working groups. The implications of these are that the IETF has too much work in too many areas to be effective. One remedy is to scale back the IETF; not accept so much work. The implications could be that other SDOs pick-up the slack. Instead of 3GPP(2)/IEEE/ITU-T bringing work to the IETF, they could do it themselves. 3GPP is doing a lot with SIP, let them handle it; 3GPP2 is using Mobile IP, let them continue the development; IEEE could handle RADIUS & EAP; ITU-T could handle AAA & QoS; let's let the ATM Forum handle all of the Sub-IP layer stuff. My feeling is that the IESG has been concerned that this would cause fragmentation and a lot of problems. Another result of pushing back on work would mean that vendors might not document their work, or document it via vendor specifications. We also see a rise of open source communities creating their own mechanisms for creating running code standards - stuff that is documented in Linux Kernel updates, SourceForge sites, or simply documented in running code. I think all of the above scenarios are already happening, to some extent, today. The question is, do we want the IETF to assume responsiblity for key pieces of the Internet or not. If the answer is yes, then the real discussion is how to make it happen. I think sticking with the current model because we choose not to think differently is not a good answer. If I understand some of Dave's and John K's comments, they are willing to entertain thoughts on how to do things better (& differently) in order to ensure that the IETF remains relevant. John L. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf