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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf