My notes on draft-carpenter-newtrk-questions-00.txt

["Spencer Dawkins" <spencer at mcsr-labs.org>]

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