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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 12 Jul 2006 00:16:35 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 Jul 2006 15:05:09 +0300 (EEST)

> http://rtg.ietf.org/~fenner/ietf/deps/viz/sip.pdf, for SIP.

Is there an expectation that the IETF should define which 
specifications should be implemented to constitute "implements IPv6", 
"implements SIP", or whatever?

I guess folks have since abandoned the concept of IETF deciding on 
behalf of users and vendors which features are necessary in a given 
scenario or trying to determine what needs to be implemented to 
interoperate with already deployed implementations.

Don't get me wrong, I love documents like 
draft-ietf-tcpm-tcp-roadmap-06.txt.  They just take a long time and 
significant energy to produce.  However, the main purpose (AFAICS) of 
those documents is not to specify which specifications must be 
implemented to interoperate, so many of the arguments of 
newtrk-questions section 2 do no apply.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Eric Rosen <[email-masked]>
Date: Wed, 12 Jul 2006 14:28:37 -0400

The focus on document relationships rather than on simplifying the standards
track is  what (well, is one  of the things)  that sent newtrk off  into the
weeds. 

Frankly, I don't  care if someone on a desert island  cannot figure out from
the RFCs alone how  to implement some protocol.  I just don't  see that as a
problem we have to solve.   Anyway, implementing a protocol requires so much
more knowledge than can be obtained  from the RFCs that no amount of messing
with the document strategy is going to have any impact on the ability of our
castaway to become a successful implementer. 

> it's worth revisiting  the whole ISD/SRD thing with one  new ground rule -
> no more work for IESG in steady state

Let  me suggest a  second new  ground rule:  no more  work for  the document
authors, document editors, or the WG chairs.

---

From: John Leslie <[email-masked]>
Date: Wed, 12 Jul 2006 15:17:11 -0400

Eric Rosen <[email-masked]> wrote:
> track is what... sent newtrk off into the weeds. 

   Wandering in the weeds isn't always wrong.

   (We did make serious attempts to "simplify the standards track", BTW.)
`
> problem we have to solve.

   Thanks for expressing that opinion.

   (Unfortunately, it's not obvious how to find common ground between it
and other expressed opinions that too many folks are guessing wrong about
which documents to follow.)

> Anyway, implementing a protocol requires so much more knowledge than
> can be obtained from the RFCs that no amount of messing with the
> document strategy is going to have any impact on the ability of our

   If our castaway lacks Internet access, IMHO, s/he should give up!

   OTOH, if we can help him/her learn where to look on the Internet, it
seems like a win/win.

> authors, document editors, or the WG chairs. 

   Hmmm...

   At first blush, that seems extreme...

   Nonetheless, I could easily agree that we shouldn't _require_ more
work by any of these before we can demonstrate a benefit.

--
John Leslie <[email-masked]>

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 14 Jul 2006 06:59:34 -0700 (PDT)

On Wed, 12 Jul 2006, Eric Rosen wrote:
> The focus on document relationships rather than on simplifying
> the standards track is what (well, is one of the things)  that
> sent newtrk off into the weeds.

I completely agree.

> Frankly, I don't care if someone on a desert island cannot
> figure out from the RFCs alone how to implement some protocol.  
> I just don't see that as a problem we have to solve.  Anyway,
> implementing a protocol requires so much more knowledge than can
> be obtained from the RFCs that no amount of messing with the
> document strategy is going to have any impact on the ability of
> our castaway to become a successful implementer.

Very well said.  As I said in my message of 18 June, my advice would
be to make a relatively minor set of clarifications to BCP 9 (RFC
2026) and move on.  It would also be OK for newtrk to refocus on its
original charter of simplifying the standards track.  But I would be
very dismayed to see it focus on document relationships.

Mike Heard

---

From: Douglas Otis <[email-masked]>
Date: Fri, 14 Jul 2006 11:40:38 -0400

On Jul 14, 2006, at 9:59 AM, C. M. Heard wrote:
>
> Very well said.  As I said in my message of 18 June, my advice  
> would be to make a relatively minor set of clarifications to BCP 9  
> (RFC 2026) and move on.  It would also be OK for newtrk to refocus  
> on its original charter of simplifying the standards track.  But I  
> would be very dismayed to see it focus on document relationships.

Few RFCs are stand-alone elements for developing interchange.  When  
flattening document categorization, conveying levels of interchange  
remains problematic.  Evolution of document relationships remain an  
element poorly handled by composing these sets within RFCs  
themselves, which are likely rapidly dated.  A tracking system not  
encumbered with inclusion of normative language ensures a working-set  
can be tracked in a reasonable fashion.  Much of the RFC review  
process and utilization depends upon understanding what is the  
intended set.  The Name.Serial proposals as found in both the ISD and  
SRD proposals provides a means for both tracking this evolution,  
while also stabilizing references used to uncover document sets.   
Often as documents change, reference to the prior set may be  
considered by the community as Stable, whereas the latest set, as  
Current.  Stable versus Current is too dynamic to be tracked by a  
highly formalized process.  The IETF could publish a list of  
interchange categories as just Name.Serial on a web page, for example.

Once the process is understood to be broken, it should also be  
obvious that it would have also been fixed had this information been  
useful.  Those actually using the information have been well served  
by the efforts focused upon providing document relationships.  It  
would also seem more appropriate to categorize the document sets  
rather than individual RFCs.  There could by a set that includes the  
single RFC, but that will likely be the exception and not the rule.

-Doug