Subject: [newtrk] updated draft on cruft / draft-alvestrand-newtrk-cruft-00.txt

From: John C Klensin <[email-masked]>
Date: Mon, 30 Aug 2004 16:24:25 -0400

Eliot, Harald,

Two quick comments on this draft, based on what I thought was
agreed to in San Diego.

(1) You were told to "mention" "my idea".  That was, in
retrospect, ambiguous, but I thought the plan was to mention
both the STD stuff (draft-klensin-newtrk-std-repurposing /
draft-loughney-what-standards) and the "promote, not just
demote" material (draft-klensin-newtrk-antiques).  Instead, this
draft seems to have completely ignored the latter and to have
mischaracterized the former as involving moving "such
information into web pages and out of the technical documents".
If there were any clear conclusions in San Diego about the
details of the STD stuff, they included support for the
"standards document with clear change history" approach rather
than the more volatile and descriptive web pages that could have
been read into the "what standards" document.  I don't know that
either is a major problem at this point, but it is a little
disappointing, especially given the "p.s." below.

(2) I may have been napping or concentrating on what I was going
to say about the John-and-John proposals, but I don't recall any
discussion/ conclusion/ or even tentative consensus during the
WG discussions about creating a whole new standards maturity
level.  Yes, there were concerns about further overloading and
confusion about the meaning of Historic.  But it seems to me
that a new level is a very major step, especially at a time when
we have proposals to reduce the number of levels to reduce
confusion.  And this document doesn't provide _nearly_ enough
justification for introducing a new level term, especially one
that is weakly defined (the explanation that 'merely "old and
crufty"' and "old, crufty, and dangerous" doesn't do nearly
enough for me relative to the costs and risks of introducing new
levels and new terminology.

regards,
      john

p.s. I think that, as agreed post-meeting, John and I are
waiting for comments from you about reducing the size and
explanatory content of the std-repurposing draft.  If you
understood that draft as suggesting "web pages", perhaps it
needs more, rather than less, clarification.   One way or the
other, can we expect those comments soon so we can get another
draft together and posted?  Thanks.

.
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: Tue, 31 Aug 2004 13:44:52 +0200

John,

First, thanks for your comments.  Please see below.

John C Klensin wrote:

> demote" material (draft-klensin-newtrk-antiques).  

Others should correct me if I'm wrong, but my understanding coming out 
of San Diego was that people preferred that promoting be kept separate 
from demoting.  This is why it is mentioned only in the most oblique way 
as an action item for the IESG.

> Instead, this

I certainly did mention your draft, but the I don't make it normative 
because my expectation is that this draft can move faster.  Also, my 
understanding from the working group was that we should be able to try 
this idea relatively quickly.

> confusion.

As mentioned in the meeting, Historic was viewed as overloaded.  I am 
perfectly happy to consolidate if that is what the WG wants.  I'm not 
entirely happy with the wording here, myself.  But see below.

> And this document doesn't provide _nearly_ enough

Ultimately the issue is this: do we wish to make a distinction between 
those standards, when used as advertised, are dangerous either to the 
user or to the Internet as a whole, and those that have been found to be 
not generally useful?  If so, then I need a term for that purpose.  If 
people agree with Scott, Historic -> dangerous and we shouldn't reuse 
Historic to mean otherwise.  But beyond this I don't care if the marking 
is "4F".

> draft together and posted?  Thanks.

Yes, but I've had to do one draft at a time.

Eliot
.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2004 14:19:42 +0200

I don't see where it is written that Historic = Dangerous.
We can't expect the world to know that intention.
(Dave Crocker can tell us whether RFC 652 is dangerous,
for example.)

If we are going to introduced an Outdated classification (which
is reasonably self-explanatory) then shouldn't we simultaneously
introduce a Deprecated classification for things that really are
dangerous?

Then the cruft committee can have another little job, i.e.
deciding whether existing Historic RFCs should be reclassified
as Outdated or as Deprecated.

     Brian

.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 31 Aug 2004 09:31:00 -0400

Hi Brian,

>as Outdated or as Deprecated.

I know that this was meant lightheartedly, but it rather disturbs me...

How much time are we willing to spend on documents that are (as 
implied by the fact that we might make them historical, outdated or 
deprecated) not relevant to the Internet?

I guess there is some belief that by clearing out the cruft, we will 
make the non-cruft more valuable or more relevant?  If so, I'm not 
sure I buy that...  I'll give a couple of examples from my own 
experience of why not:

I've been a director-level product marketing and/or product line 
manager for networking products at a few companies (shh, don't tell 
anyone :-)), and I can honestly say that it _never_ occurred to me to 
look through the RFC index to determine what should be implemented in 
my products.  I asked customers what they needed, I did competitive 
evaluations, and I determined how newish standards-body work (IETF 
and IEEE mostly) might apply to known customer problems.  I didn't 
care enough about the classification of the I-Ds and RFCs I was 
requiring in my Market Requirements Documents (MRDs) to even bother 
to look them up.

I've also developed a reasonable amount of networking software.  In 
most cases, what I developed was driven by customer demand and/or by 
MRDs, not by what the IETF did (or didn't) tell me to implement.  The 
one notable exception is when I was implementing IPv6 -- it was early 
enough that customer demand was not established, and I was guided by 
what the WG charter page and additional web pages referred to as the 
"IPv6 Core Specs".  I wasn't daunted by the fact that some of these 
specs were still I-Ds, nor would I have noticed if some of them had 
been informational or experimental rather than PS.

So, I wonder if twiddling with the classifications of these documents 
will have any real value, or if we'll just be talking to ourselves...

Do others have counter-examples where the reclassification of RFCs 
would have some sort of positive effect on real-world implementations 
or deployments?

Margaret

.

---

From: Susan Harris <[email-masked]>
Date: Tue, 31 Aug 2004 11:22:51 -0400 (EDT)

Greetings - a few comments on the draft.
---------------------------------------

> Network Working Group                                      H. Alvestrand
> Internet-Draft                                             Cisco Systems
> Updates: 2026 (if approved)                                      E. Lear
> Expires: February 24, 2005                            Cisco Systems GmbH
>                                                           August 26, 2004
>
>
>      Getting rid of the cruft: A procedure to deprecate old standards
>                    draft-alvestrand-newtrk-cruft-00.txt

A nit, but can we omit "cruft" from the title?  I know we use the word a
lot, but it's too colloquial for a written doc.  Maybe just "A Procedure
to Deprecate Old Standards,"  draft-alvestrand-newtrk-deprecate-00.txt?

<snip>

> Abstract
>
>     This document describes a procedure for performing the downgrading of
>     old standards described in RFC 2026, as well as BCPs, without placing
>     an unreasonable load on groups charged with performing other tasks in
>     the IETF.
>
>     It defines a new group, called the "Cruft Committee", which shall

"RFC Review Committee?"

>     recommend to the IESG downgrading or progressing documents on the
>     IETF standards track.  Ultimate decisions still rest of with the
>     IESG, with appeal to the IAB.  A new status of "Outdated" is created.

As John K. mentioned, this new designation seems to have come out of the
blue. If we decide one's needed, see my next comment.

<big snip>

> 3.2  Evaluation criteria
>
>     The decision on when to ask for reclassification is made by the
>     Committee.
>
>     Criteria that should be considered are:
>     o  Implementations.  A spec that is unimplemented should go to
>        Outdated.
>     o  Usage.  A protocol or feature that is safe to use but is no longer
>        generally useful should go to Outdated.
>     o  Potential for harm.  A protocol that is unsafe shall be marked
>        Historical.  In the latter case, the danger must be documented in
>        the permanent record either with a brief RFC under current
>        practice, or with a notation kept with the standard status (as
>        envisioned in NEWTRK).
>     o  Interest in further work.  If there is a reasonable expectation
>        that the specification will be updated or advanced within a
>        reasonable timeframe, the Committee should do nothing.

Looking over Eliot's and John's later exchange on the new designation,
it's interesting to see what words we associate with "unsafe."  To me,
"Outdated" sounds more unsafe than "Historical." Maybe "Prohibited" for
unsafe?
.
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: Tue, 31 Aug 2004 17:57:08 +0200

Margaret Wasserman wrote:
> Do others have counter-examples where the reclassification of RFCs would 
> have some sort of positive effect on real-world implementations or 
> deployments?

COPS - no privacy capabilities.  TLS, while being mentioned, is not in 
fact specified.  And it's not actually implemented by anyone.  This 
protocol is taken seriously by the folks in the ITU and yet as specified 
is definitely substandard.

Eliot

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 Aug 2004 12:21:03 -0400

--On Tuesday, 31 August, 2004 17:57 +0200 Eliot Lear
<[email-masked]> wrote:

>> So, I wonder if twiddling with the classifications of these
>> documents  will have any real value, or if we'll just be
>> talking to ourselves...
>> 
>> Do others have counter-examples where the reclassification of
>> RFCs would  have some sort of positive effect on real-world
>> implementations or  deployments?
> 
> COPS - no privacy capabilities.  TLS, while being mentioned,
> is not in fact specified.  And it's not actually implemented
> by anyone.  This protocol is taken seriously by the folks in
> the ITU and yet as specified is definitely substandard.

But that description would seem to qualify it for "dangerous",
which is not the category you propose for the cruft-reduction
effort.   As Brian pointed out, you are headed down the path
toward a committee that has to distinguish between "old and
probably unused" and "old and seriously undesirable".  That
requires a different kind of committee, a different set of
skills, and introduces a rather more radical idea than was
discussed in San Diego.  I think that inferring from the San
Diego discussions that you have significant backing for it would
be wrong, since any statement along  the lines of "don't use
this because it is bad" (rather than "no one seems to be using
this") takes us very far into A/S territory.

--On Tuesday, 31 August, 2004 11:22 -0400 Susan Harris
<[email-masked]> wrote:

> Looking over Eliot's and John's later exchange on the new
> designation, it's interesting to see what words we associate
> with "unsafe."  To me, "Outdated" sounds more unsafe than
> "Historical." Maybe "Prohibited" for unsafe?

At the risk of trying to reuse something with which we actually
have experience, how about "not recommended".  Note, however,
that anything along those lines takes us down the path toward
recommendations and applicability statements (see above).  It
seems that what Eliot was asking for above (and hence my reason
for combining these responses) is more like "bad - should not
have been approved in the first place".  That is, arguably, a
maturity level statement rather than an applicability one, but
one that we have no mechanism for making (other than, perhaps,
to try to reclassify the document as experimental).

     john

.

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 Aug 2004 12:32:18 -0400

--On Tuesday, 31 August, 2004 13:44 +0200 Eliot Lear
<[email-masked]> wrote:

> Others should correct me if I'm wrong, but my understanding
> coming out of San Diego was that people preferred that
> promoting be kept separate from demoting.  This is why it is
> mentioned only in the most oblique way as an action item for
> the IESG.

ok.  it was a little too oblique for me to recognize it.

>> information into web pages and out of the technical
>> documents". If there were any clear conclusions in San Diego
>> about the details of the STD stuff, they included support for
>> the "standards document with clear change history" approach
>> rather than the more volatile and descriptive web pages that
>> could have been read into the "what standards" document.  I
>> don't know that either is a major problem at this point, but
>> it is a little disappointing, especially given the "p.s."
>> below.
> 
> I certainly did mention your draft, but the I don't make it
> normative because my expectation is that this draft can move
> faster.  Also, my understanding from the working group was
> that we should be able to try this idea relatively quickly.

But what you said about that draft was that it involved putting
things on web pages.  That is explicitly what it does _not_ say.
It even explains the reasons why not.

As far as what can advance faster, I salute your optimism, but
believe that what could move forward quickly on the basis of San
Diego discussions would be an improved version of the document/
discussion there.  Introducing new standards maturity level
categories, trying to separate "old" and "dangerous", etc., are
new ideas for which there was no San Diego support because there
was no San Diego consensus.  And, on those things, it seems to
me that you are starting from square one, and with some
resistance from a few of us.  Put differently and from my
personal point of view, if you want to propose a committee to
review older documents and make some recommendations to the
IESG, I'd say "worthwhile experiment" and "probably something
that can be tried under the "July 14" rules.  But, as soon as
you start talking about new categories, you are involved with a
heavy-duty change to how we define the standards and the
standards process.  I don't see any way to fast-track a change
like that.

>...
> Ultimately the issue is this: do we wish to make a distinction
> between those standards, when used as advertised, are
> dangerous either to the user or to the Internet as a whole,
> and those that have been found to be not generally useful?  If
> so, then I need a term for that purpose.  If people agree with
> Scott, Historic -> dangerous and we shouldn't reuse Historic
> to mean otherwise.  But beyond this I don't care if the
> marking is "4F".

The problem, as I see it, is that we have ample procedural
justification for classifying old and unused documents (or even
documents that have not advanced on the standards track) as
"historic" (whatever that means and accepting the ambiguity).  A
slightly different procedure for identifying candidates is still
within the general spirit of the rules we have.   But, if you
want to make up new maturity levels/terminology, we have no
mechanisms in place.  And I suspect that identifying things
separately as "old and unused but harmless" versus "old and
dangerous" really should require analysis, writeups, and
community last call on a per-document basis, for at least one of
those category/ groupings.  And, like Margaret (if I correctly
understand her), I'm not convinced that taking the energy and
resources away from new work to do that is worth it.

      john

.

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 31 Aug 2004 10:29:06 -0600 (MDT)

On Tue, 31 Aug 2004, Eliot Lear wrote:

>> So, I wonder if twiddling with the classifications of these documents will 
>> have any real value, or if we'll just be talking to ourselves...
>> 
> COPS - no privacy capabilities.  TLS, while being mentioned, is not in fact 
> specified.  And it's not actually implemented by anyone.  This protocol is 
> taken seriously by the folks in the ITU and yet as specified is definitely 
> substandard.

The question is not whether COPS is dangerous, but whether 
reclassification of RFCs would have some sort of positive effect on 
real-world COPS or TLS implementations or deployments. Would OpenSSL 
library, for example, drop TLS support if IETF publishes a "Dangerous" 
TLS RFC?

As far as I can see, Margaret's experience directly confirms that 
assigning one-size-fits-all stage labels to RFCs is pointless. Vendors 
have their own, custom notions of stability, implementability, 
maturity, etc.  The best we can do is to record and maintain [possibly 
conflicting] vendor statements for each RFC.

On the other hand, there are always counter examples. The job of this 
WG is to decide whether those counter examples are important enough to 
create (or keep) RFC stages/labels for them.

Alex.
.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 31 Aug 2004 19:45:09 +0300 (EEST)

> as Outdated or as Deprecated.

FWIW, my assumption has always been that the "cruft committee" would
produce an informational RFC (or something like that) when it moves a
set of documents to historic, or at least does that once a year or at
some intervals, so that we have documentation why docs were moved to
historic.

Such a document can explain with a paragraph or two what were the 
reasons for moving to Historic: dangerous, just simply unused, or 
something else.

If we assume that, the label we use for the multiple kinds of
"historic" RFCs looks like just semantics, and not (IMHO) worth
spinning new labels for.

-- 
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: Eliot Lear <[email-masked]>
Date: Tue, 31 Aug 2004 20:02:15 +0200

Hi John,

Please see below:

John C Klensin wrote:
 >> [ COPS example ]
> probably unused" and "old and seriously undesirable".

Again, if the group is hung up on the difference, and would rather see 
it removed, I'll remove it.  I'm neutral.  I put it in on request, but I 
propose a bit of an alternative that perhaps you'll prefer.  To argue 
the other side for a moment, however...

>  That
> discussed in San Diego.  

All you need in a committee is a recognition that something is not just 
useless but dangerous.  In those cases you want some words to state just 
that.  Here's where your proposal comes in.  Either those words go into 
an RFC or they go into the composite document that you and John are 
proposing.  Which depends on timing.  I tried to say this.  Perhaps poorly?

> I think that inferring from the San

In that specific case what it takes is someone to write words.  What we 
DON'T want to do is to NOT have those words when something is dangerous. 
  And so in this way, we don't want to change the status quo.

> to try to reclassify the document as experimental).

Yah, if you recall, John, there were a few examples.  Some of them fit 
the bill of "shouldn't have been approved in the first place", but 
others were more "useful for their time".  A good example is SLIP.  Same 
with some of the earlier directory work that I mentioned in the 
presentation.

To Susan's more general point about wording, I'm a folksy kind of guy. 
I got that way largely by maturing within the Internet community and 
Silicon Valley that doesn't stand on formalism.  I could agree that 
"cruft" is ill defined as a formalism.

Here's a proposal that deals with both issues.  Go back to using "Not 
recommended" but add a "WHY" that specifies whether it is due to 
security or if there's a better way of doing things (and give a 
reference, perhaps).

Eliot
.

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 Aug 2004 18:26:30 -0400

--On Tuesday, 31 August, 2004 20:02 +0200 Eliot Lear
<[email-masked]> wrote:

> All you need in a committee is a recognition that something is
> not just useless but dangerous.  In those cases you want some
> words to state just that.  Here's where your proposal comes
> in.  Either those words go into an RFC or they go into the
> composite document that you and John are proposing.  Which
> depends on timing.  I tried to say this.  Perhaps poorly?

I may have been misunderstanding this all along, but the
committee I pictured from reading your initial draft would focus
primarily on "no longer in use" (if ever) and not on protocol
quality ("dangerous" or otherwise).  The advantage of such a
committee is that the job it is to perform is largely a research
activity; it is not required to do a [re-]analysis of the
protocol in today's context.  A research committee --one that
tries to determine whether something is in use-- is attractive
for many reasons, not least of which is that it could presumably
be populated by people who were relatively new to the IETF who
could thereby both make a significant contribution and learn a
lot in the process.  By contrast, a committee charged with doing
protocol analysis would have to be more senior and experienced
and probably would need to consist largely of people with a
skill-set similar to that for which we select the IESG.  That
would be a harder group to populate and the community would
presumably need to make some decisions about whether this was
the best way for such people to invest their time.

Either activity (and group) might be worthwhile, but I'm much
more skeptical about being able to staff the second one.

That skepticism is increased by the observation that the work of
a group that is going to classify something as e.g., "actively
dangerous" would run headlong into part of the argument that
motivated draft-klensin-newtrk-antiques-00.  To state it
differently, as long as the IETF functions as a standards body
and not, e.g., as an arbiter of network taste, morals, and
etiquette, there should be an extremely strong bias that
something that is significantly deployed and in use is
acceptable practice.  Whether it is dangerous in theory is
interesting, but the compelling argument should be that nothing
has broken so seriously as to result in the deployment of
whatever-it-is going down.  Now it is quite reasonable to be
able to overcome that bias by clear reasoning and examples.
Certainly there are things that are deployed in the Internet
today that the IETF might rationally deprecate even if we had
never approved them in the first place.  But the quality and
extent of analysis that, IMO, ought to be needed to say "in
spite of the fact that is widely deployed and not obviously
harmful, it is dangerous nonetheless and its use should be
deprecated" is entirely different --and much less appropriate to
a committee that is sweeping through old documents-- than the
analysis needed to say "no one is using this and it isn't clear
that it was a good idea".

>> Diego discussions that you have significant backing for it
>> would be wrong, since any statement along  the lines of
>> "don't use this because it is bad" (rather than "no one seems
>> to be using this") takes us very far into A/S territory.
> 
> In that specific case what it takes is someone to write words.
> What we DON'T want to do is to NOT have those words when
> something is dangerous.   And so in this way, we don't want to
> change the status quo.

But, again, concluding that something that is deployed and that
has been in use for some time is dangerous --at least when that
has not become obvious to all concerned-- is, IMO, a fairly
significant activity that should require strong community
understanding and consensus.

Let me give an example to illustrate this.  We have a protocol
called "finger".  It certainly does not meet contemporary norms
for mutual authentication of client and server, nor for data
integrity protection of the query and the response.  On the
other hand, it is fairly widely deployed and in active use in
some communities.  It would certainly be desirable, if anyone
felt like doing the work, to attach an analysis of security
issues to the protocol, cautioning about the degree of care that
should be taken in its use and perhaps about circumstances under
which it would or would not be appropriate.  But, over the
years, the market has decided, loudly and frequently enough,
that finger is useful that deprecating it because of some
contemporary ideas about security would not change anyone's
behavior... other than to bring the IETF, its decision-making
process, and the degree to which we are in touch with reality,
into disrepute.

>> At the risk of trying to reuse something with which we
>> actually have experience, how about "not recommended".  Note,
>> however, that anything along those lines takes us down the
>> path toward recommendations and applicability statements (see
>> above).  It seems that what Eliot was asking for above (and
>> hence my reason for combining these responses) is more like
>> "bad - should not have been approved in the first place".
>> That is, arguably, a maturity level statement rather than an
>> applicability one, but one that we have no mechanism for
>> making (other than, perhaps, to try to reclassify the
>> document as experimental).
> 
> Yah, if you recall, John, there were a few examples.  Some of
> them fit the bill of "shouldn't have been approved in the
> first place", but others were more "useful for their time".  A
> good example is SLIP.  Same with some of the earlier directory
> work that I mentioned in the presentation.

But, unless I've forgotten them, all of the examples, certainly
including SLIP and that directory work, have fallen into disuse
or were never significantly deployed at all.  Just as the
marketplace has decided to keep "finger", et al, regardless of
how we would dispose of similar things if they arose, brand new,
today, it has decided to drop SLIP et al.  And that, rather than
their protocol quality, qualifies them for "historic" in the
most traditional IETF sense of that term, which I would contend
is simply "no longer relevant in the marketplace or as a basis
for further design".  For such documents, we don't need to do
the work to determine levels of badness: "irrelevant" simply
trumps that issue.

>...
> Here's a proposal that deals with both issues.  Go back to
> using "Not recommended" but add a "WHY" that specifies whether
> it is due to security or if there's a better way of doing
> things (and give a reference, perhaps).

I could probably live with this, but see above.  Note that
"better way of doing things" ought to be covered by "Obsoleted
by", not "Historic", although some other mechanism or model may
be needed when the better technology is not recognized by, or
documented within, the IETF process.

best,
   john

.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 31 Aug 2004 21:06:09 -0500

> documents will have any real value, or if we'll just be talking to 
> ourselves...
>
> would have some sort of positive effect on real-world 

I'll wait, and not go out on a limb with my prediction that there are 
no counter-examples, but if we don't end up deciding that 
reclassification will not affect what's running on the Internet today 
in any significant way, I'll be AMAZED...

I DO like "cleaning out the cruft/obsolete/historical/whatever", but 
that's because it makes it easier for people to newly implement and 
deploy what is left over, not because I have any poorly-justified 
faith that people will turn anything off or upgrade anything because 
we reclassified something obsolete, especially if we don't also 
reclassify anything as obsolete-and-dangerous.

Spencer 

.