Subject: [newtrk] Moving forward from draft-lear-newtrk-decruft-experiment-01.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 15 Jul 2005 17:54:38 -0500

Eliot,

Thank you for updating this draft.

The draft contains four mutually exclusive potential next steps in 
Section 5:

 1.  Accept the results of this experiment, issue a last call, and
     deprecate standards that remain on the list past last call.  This
     is an aggressive approach that would preserve the intent of RFC
     2026.
 2.  Do not accept the results of this experiment and update RFC 2026
     to indicate a new practice.
 3.  Revise the procedure based on the results of this experiment,
     based on feedback from the IESG.  This option might take into
     account the different types of old standards as described above.
 4.  Do nothing.  This would leave the IETF and the IESG practice
     inconsistent with documented practice.

My preference would be for #1.

We still have a question about whether it is ok to go Historic with 
the specification for a protocol that is still in use.

My preference would be for "yes".

If it really is necessary to distinquish between obsolete and evil 
specifications, I would rather add "obsolete" as a document status 
than continue trying to represent two conditions with one bit, as it 
were.

Spencer 

.
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, 18 Jul 2005 09:49:02 +0200

Spencer,

Thanks.  I would be happy with any of the answers except doing nothing.
 What we call the category is not the subject of the experiment but
clearly is relevant.

Eliot
.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 22 Jul 2005 11:19:46 +0200

Just so that I have stated my preference on the mailing list before the 
time allocated for discussing it in Paris:

I think that the group should recommend option #1:

 1.  Accept the results of this experiment, issue a last call, and
     deprecate standards that remain on the list past last call.

I think the experiment has generated a clear indication that there exist a 
number of documents for which there is no reason for them to remain on the 
standards track, and that comparatively little IETF energy is required to 
finish the discussion of those documents and get them reclassified.

The "comparatively little energy" part is a direct result of the fact that 
anything that is even a little bit controversial gets removed from the list 
at once - this means that the following piece of the document is somewhat 
troubling:

>    As one peruses this list one sees several classes of documents:
>
>    o  Multiprotocol functions for protocols that are obsolete, such as
>       Appletalk or X.400.
>    o  Protocols that were defined but not used, such as PEM or Whois++
>    o  Functions that require at the very least updated applicability
>       statements, such as the ESP DES-CBC transform.
>
>    Of the set above it is clear that additional process for the later
>    one is unnecessary, since a document should be written one way or
>    another.

It seems to me that the document should list those standards that are in 
the last category separately, so that we can be clear on what is being 
proposed for retirement and what is being proposed as "recommend doing 
something about this, but not as part of this effort". I think the 
documents in question are only the DES ESP transform (1829) and the CIDR 
documents (1518, 1519), but I could be wrong - I don't have the whole 
discussion in my head.

                             Harald

.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Jul 2005 14:59:01 +0300 (EEST)

On Fri, 22 Jul 2005, Harald Tveit Alvestrand wrote:
> It seems to me that the document should list those standards that are in the 
> last category separately, so that we can be clear on what is being proposed 
> for retirement and what is being proposed as "recommend doing something about 
> this, but not as part of this effort". I think the documents in question are 
> only the DES ESP transform (1829) and the CIDR documents (1518, 1519), but I 
> could be wrong - I don't have the whole discussion in my head.

As I've said earlier, I believe the ultimate draft being last-called 
should describe the reason (one sentence is enough) per obsoleted RFC. 
This would fix this concern as well.

(As it is, the details are buried in mailing-list (which isn't hosted 
by the secretariat) archives.  That's better than nothing, of course.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
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: Fri, 22 Jul 2005 15:17:14 +0200

> This would fix this concern as well.

This wouldn't work since we only discussed a small subset of the
remnants.  Remember, default was "obsolete" with a low threshold to do
otherwise.

Eliot
.

---

From: John Leslie <[email-masked]>
Date: Fri, 22 Jul 2005 10:53:36 -0400

>> This would fix this concern as well.

   That would indeed be "a nice thing"...

> remnants.  Remember, default was "obsolete" with a low threshold to do

   I must agree with Eliot here: introducing "one sentence" at this
late date would open multiple cans of worms (per sentence). Better not
to start down that path.

   :^(

--
John Leslie <[email-masked]>
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Jul 2005 17:55:40 +0300 (EEST)

> late date would open multiple cans of worms (per sentence). Better not

Umm. Can't we think of a generic statement that applies to all the 
documents which haven't had any more specific discussion?  Seems 
simple to me.  For example,

   This document is believed to be obsolete, and there have been
   no comments indicating otherwise.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jul 2005 17:19:14 +0200

Pekka Savola wrote:
> documents which haven't had any more specific discussion?  Seems simple
> to me.  For example,
> 

If it covers most documents, then saying it a single time seems to make
more sense.  We can call out any exceptions (there are few).

Eliot
.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 22 Jul 2005 18:24:00 +0300 (EEST)

> more sense.  We can call out any exceptions (there are few).

That kind of approach would be fine with me, of course.  For example, 
arranging the list in 2-4 subsections could fluently allow for 
RFC-specific obsoletion reasons or capturing the discussions we had.

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 22 Jul 2005 11:34:59 -0400

>    no comments indicating otherwise.

Sounds reasonable. Separating the list on a per-RFC basis permits
modification based on Last-Call comments (in case some IETFer who
missed the earlier announcements knows of a specific reason why a
particular RFC should be treated differently).
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 22 Jul 2005 10:34:08 -0700

> particular RFC should be treated differently).

The outcome from developing comprehensive SRDs to cover all useful  
RFCs would expose several related issues.  These SRDs could be  
initially generated using scripts with perhaps a bit of human input  
to classify the relationships.  These "sentences" could be placed  
into the Status database linked to the SRD where it becomes easier to  
review a more comprehensive effort.  It would also help assure  
something is not being overlooked, and should not be much more effort  
than creating a sentence per RFC believed to be obsolete.  These  
obsolete RFCs would likely be isolated by such a process where they  
would stand alone.

-Doug
.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Jul 2005 11:19:04 +0200

> My preference would be for #1.

Mine too, but I observe that it doesn't exclude #2 and #3 as well.

> 
> We still have a question about whether it is ok to go Historic with the 
> specification for a protocol that is still in use.

The word "deprecate" is not a defined term in RFC 2026. I've been involved
in two specific "deprecation" RFCs (3879 and 4048) and the meaning seems
to vary from case to case. So we need some very precise language in the
version of -decruft that goes to Last Call. "Deprecate" isn't a neutral word,
so we might want to simply avoid it. The simplest, and non-2026-violating,
solution is simply:

    This document reclassifies all the specifications listed in Section 3
    as Historic (section 4.2.4 of [1]).

By the way, that section says:

    Note: Standards track specifications normally must not depend on
    other standards track specifications which are at a lower maturity
    level or on non standards track specifications other than referenced
    specifications from other standards bodies.  (See Section 7.)

so somebody needs to check that none of the cruft RFCs are normative
references.

> specifications, I would rather add "obsolete" as a document status than 
> continue trying to represent two conditions with one bit, as it were.

If we are declaring something evil, that needs a justification
(such as RFC 3879). Just putting a label on the RFC doesn't do it,
IMHO.

     Brian

.

---

From: Bill Fenner <[email-masked]>
Date: Thu, 28 Jul 2005 12:49:42 -0400

>so somebody needs to check that none of the cruft RFCs are normative

Queries such as
http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=rfc1518&depx=on
may help here.  I'll caution that this can result in false negatives,
since references by document title but without a reference to the
RFC string don't get caught.  (This is more of a problem with drafts.)

(Yes, the title of the page implies drafts only, but the database also
contains RFCs.)

Of course, normativeness (normativity?) will mostly have to be determined
by inspection, since split references didn't start showing up until
about 2002.

  Bill
.