Subject: RE: [newtrk] Comments on draft-klensin-newtrk-std-repurposing-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Sun, 5 Sep 2004 16:12:54 -0700

> FWIW, my perhaps naive impression is that these days people care least
> at the top, and at the bottom, of the protocol stack (the battle in
> SubIP was to get people to care that the tunneling mechanisms were
> even RFCs), but that's not to say that other people cared a whole
> bunch more.

That is true about the IETF in general. In practice, the IETF importance
is higher when you are close to "the neck of the hourglass", i.e. IP,
TCP or UDP above it, PPP under it. But even so, we have seen
specification reach "must implement" status in the community as internet
drafts -- BGP 4 comes to mind. We have also seen specifications reach
proposed standard status and nobody cared much.

-- Christian Huitema

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Sep 2004 10:45:16 +0200

> proposed standard status and nobody cared much.

I don't recall if it was Erik Fair or Brian Kantor who first said this 
in the context of Internet standards, but one of the primary purposes of 
RFCs and standards is to document existing practices so that others 
might develop interoperable implementations.  Use of Proposed/Draft/Full 
Standard is merely a recognition of how widely deployed those defacto 
standards are.

Keeping track of what is current for the sake of interoperability and 
safety (as in the case as such ideas as slow start), is an important 
function.  Not all of us have been part of the history, and the record 
is poorly documented.  Someone starting from scratch ought not have such 
a disadvantage, especially if the result could impact others (as would 
be the case in a poorly implemented TCP).

Eliot
.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2004 12:24:42 -0400

--On Monday, 06 September, 2004 10:45 +0200 Eliot Lear
<[email-masked]> wrote:

>...
> I don't recall if it was Erik Fair or Brian Kantor who first
> said this in the context of Internet standards, but one of the
> primary purposes of RFCs and standards is to document existing
> practices so that others might develop interoperable
> implementations.  Use of Proposed/Draft/Full Standard is
> merely a recognition of how widely deployed those defacto
> standards are.
>...

And of whether the hypothesis of interoperability has actually
been tested, in implementation and in deployment, rather than
being merely an assertion.  IMO, it would be bad to lose sight
of that particular part of the definitions.

While I understand the reasons why we moved away from making
statements about "optional", "recommended", "mandatory", etc., I
believe they have had an unintended side effect.  As I
understand it, your point --and that of Erik and Brian-- is
that, traditionally, the IETF Standards Track is about clarity
of specification, implementability, and interoperability.  It is
much less, if at all, about recommendations of ultimate
goodness, especially if there is deployed existing practice that
is viewed as successful by someone.   

While we didn't use those recommendation categories regularly or
well, their existence at least provided a useful distinction.
Without them, we seem to be moving ever more down the path of
not wanting to get (or advance) anything on the standards track,
no matter how widely deployed and successful, unless it passes
(mostly unstated) requirements for virtue and goodness.   And
that, IMO, is profoundly unhealthy.

>From that particular perspective, "std-repurposing" and
"antiques" are two aspects of the same issue.  The first would
actually permit the community to say, for the first time since
we got rid of the possibility of "standard but not recommended"
--and much more clearly-- "look, this protocol stinks because...
but it is widely deployed, the specification describes it
adequately, and there are lots of interoperable implementations
out there".  The importance of that seems to become more obvious
with each passing month.

The second is an attempt to get us back on the track of being
able to say "widely deployed, good specification, interoperable"
about things that have proven themselves by deployment and in
the marketplace, even if they don't pass IETF's theoretical and
philosophical criteria for Goodness.  It is clearly, IMO, less
important, just as "historical" is, but part of the puzzle.

    john

.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 06 Sep 2004 19:02:50 +0200

John,

I guess what I was saying is that it's important for the status of our 
standards to reflect reality.  The value judgment of what is good and 
bad  or safe or unsafe *IS* useful, but you're right.  It's different.

I think a good case study is SNMPv1.  If I recall it was made Historic 
while it was still in very broad use, largely because the SNMP community 
felt it needed a little bump to get people to implement V3.  I feel 
fairly confident in saying that only a minority of the SNMP traffic is 
v3.  Does that make the IESG's decision wrong?  Tough call.

Eliot

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2004 15:13:07 -0400

--On Monday, 06 September, 2004 19:02 +0200 Eliot Lear
<[email-masked]> wrote:

> John,
> 
> I guess what I was saying is that it's important for the
> status of our standards to reflect reality.  The value
> judgment of what is good and bad  or safe or unsafe *IS*
> useful, but you're right.  It's different.
> 
> I think a good case study is SNMPv1.  If I recall it was made
> Historic while it was still in very broad use, largely because
> the SNMP community felt it needed a little bump to get people
> to implement V3.  I feel fairly confident in saying that only
> a minority of the SNMP traffic is v3.  Does that make the
> IESG's decision wrong?  Tough call.

It is certainly the case that deciding to deprecate (explicitly
or by use of an ambiguous label like "Historic") something that
was in active use would require significantly more explanation
and effort with "std repurposing" in place than "a little bump".
And that would be true whether the motivation for the bump was
hidden in the Protocol Action notice or hidden entirely.

Depending on how one looks at the world, that would make things
either better or worse.  I'm convinced enough of the value of
openness and explicitness about what we have done and why to
believe that the balance comes out as "better".  But, if one is
trying to quietly leverage one protocol or practice out of
existence without being able to _prove_ that it is harmful, one
might take a position in which a bit less transparency was an
advantage.  And, of course, that brings us back to the question
of how much attention implementers pay to maturity levels when
market demand is sending a different message.

   john 

.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 06 Sep 2004 23:03:10 +0200

> hidden in the Protocol Action notice or hidden entirely.

In this particular case, RFC 3410 was written to explain the decision in 
more than a little detail.....             Introduction and Applicability 
Statements for
                 Internet Standard Management Framework
....
   The document explains why using SNMPv3 instead of SNMPv1 or SNMPv2 is
   strongly recommended.  The document also recommends that RFCs 1157,
   1441, 1901, 1909 and 1910 be retired by moving them to Historic
   status.  This document obsoletes RFC 2570.

... and it's probably indicative of the need for "the index" that it took 
me about 5 minutes to find the RFC number even though I *knew* the document 
existed.....

We know (at times) how to explain things, but not how to make it easy to 
find the explanations we have written....

                Harald

.

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2004 17:18:43 -0400

--On Monday, 06 September, 2004 23:03 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

>>> Historic while it was still in very broad use, largely
>>> because the SNMP community felt it needed a little bump to
>>> get people to implement V3.  I feel fairly confident in
>>> saying that only a minority of the SNMP traffic is v3.  Does
>>> that make the IESG's decision wrong?  Tough call.
>> 
>> It is certainly the case that deciding to deprecate
>> (explicitly or by use of an ambiguous label like "Historic")
>> something that was in active use would require significantly
>> more explanation and effort with "std repurposing" in place
>> than "a little bump". And that would be true whether the
>> motivation for the bump was hidden in the Protocol Action
>> notice or hidden entirely.
> 
> In this particular case, RFC 3410 was written to explain the
> decision in more than a little detail.....
> Introduction and Applicability Statements for
> ... and it's probably indicative of the need for "the index"
> that it took me about 5 minutes to find the RFC number even
> though I *knew* the document existed.....

>From the standpoint of my advocacy of the suggestions of
draft-klensin-newtrk-std-repurposing-00.txt, Q.E.D.   :-(

> We know (at times) how to explain things, but not how to make
> it easy to find the explanations we have written....

Which, I think, is an excellent description/ definition of a
problem that needs solving :-).   And the strongest argument for
the current draft in that context is that it does not require
completely rebuilding the standards process, which, unlike some
documentation changes, cannot be done in any time frame that any
of us would recognize as "timely" or "quickly".

So we are probably in violent agreement on this one.  Or at
least I hope we are.

    john

.