I thought it would be helpful to send these onlist, rather than blather at a
mike at the Wednesday night plenary, so I'm at least getting people to the
bar sooner.
If you have comments on my comments, please grab me anytime before the
plenary - I'd like to better understand what I'm seeing...
Thanks,
Spencer
Brian,
Thanks for spending the time to write your thoughts down. Having said
this...
1. Introduction
... deleted down to
The three possible ways forward are:
1. Agree that, apart from day to day efforts to improve efficiency,
the problems with the existing standards track are not serious
enough to justify the effort needed to make substantial changes.
Conclude that [RFC3774] exagerrated the problem and we only need
to make a relatively minor set of clarifications to BCP 9
[RFC2026].
While punting is enormously tempting (even to me), it is the wrong thing to
do. I have been talking to people about incomplete and confusing BCP text
since the late 1990s.
I have had a conversation about "whether Proposed Standards are really
standards
or not" in the past year. Our BCP text says "not ready for prime time". We
ignore that.
I am tempted to ask, "can we at least remove the misleading text about
periodic review of proposed standards and draft standards, since we have
always planned to do this but have never done it in the history of the
Internet standards process?", but am not sure that the document would be
improved by removing a few outstanding examples of B/non-C/P text.
2. Focus on document relationships
Today, users of IETF standards have no way to unambiguously identify
the complete current set of specifications for a given standard. In
particular, there is no effective structured document identification
scheme and no systematic approach to documenting the relationship
between various parts and versions of a standard.
This issue is best illustrated by example.
Actually, the IPv4 example in the document is quite good, but looking at
dependency graphs like http://rtg.ietf.org/~fenner/ietf/deps/viz/ipv6.pdf
(for IPv6, but that's
also interesting) is an even better illustration. Or
http://rtg.ietf.org/~fenner/ietf/deps/viz/sip.pdf, for SIP.
This stuff is not a surprise, and is not a secret. I know Bill has been
showing it to people for three years.
I live in SIP, and Jonathan has done an excellent job on the Hitchiker's
Guide draft
(http://www.ietf.org/internet-drafts/draft-ietf-sip-hitchhikers-guide-00.txt).
It has an even 100 references to SIP specifications, and people are still
typing. We need help in more than a few places - probably not everywhere,
but it would be nice if the result of Jonathan's labors could be kept up to
date after the first publication, and there's no reasonable way to do this
today.
My understanding was that IESG was concerned about doubling (at least) the
last call and approval overhead using ISDs, and about who would write the
(normative) text. These are not small concerns, but it's worth revisiting
the whole ISD/SRD thing with one new ground rule - no more work for IESG in
steady state - and see if anything can be done.
3. Focus on maturity levels
The current three stage standards track is perceived to be under-used
and to have specific problems that make some aspects of it
unrealistic. (It should be noted that the number of stages in the
standards track does not affect the time taken to move a draft
through the approval process and to publish it, so the problem under
discussion is distinct from the issues of the time taken to obtain
IESG approval and RFC publication.)
I have produced proposals for an adjusted three-stage standards track, a
two-stage standards track, a one-stage standards track, and working group
snapshots. It was fun, but not that much fun. My recommendation is "don't
waste your time on this".
No one cares, except that we have higher standards for Proposed Standards in
practice than RFC 2026 requires (see previous rant on confusing BCP text).
Most of the time, publication as Proposed Standard is the only time IESG can
push back on a protocol, since most of the time they will never see the
protocol being advanced on the standards track.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf