Found 2 records.

Status: Verified (1)

RFC 4450, "Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents", March 2006

Errata ID: 84
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Sam Weiler
Date Reported: 2006-03-29

Section 8 says:

    This experiment would have been completely useless without
    participation of the members of the old-standards mailing list.
    Most notably, Pekka Savalo, Bob...

It should say:

    This experiment would have been completely useless without
    participation of the members of the old-standards mailing list.
    Most notably, Pekka Savola, Bob...

Notes:

Typo in Pekka Savola's name

Status: Rejected (1)

RFC 4450, "Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents", March 2006

Errata ID: 776
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-03-18
Rejected by: Eliot Lear

(1)

Near the top of page 3, section 3 of RFC 4450 states the
reasons for removal from the list -- i.e. *not* moving
to HISTORIC state:
  o  RFC 1584  -- an expected future dependency;
  o  RFC 1755  -- believed to be actively in use.

Nevertheless, these two RFCs have been moved to HISTORIC
status along with the publication of RFC 4450, as can be
seen in rfcxx00.txt .
This is quite surprising. (Perhaps, you know what happened.)

Preferrably, the final RFC text would better have been
coordinated with the actual Standards Actions performed --
for example, by addition of an IESG statement explaining the
deviation from the text.


(2)

Due to the 'numeric limitation' applied (restriction to RFCs
with numbers in the range ~700...2000) there are now a couple
of RFCs that have lost their 'normative background'.

For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,
2456, 2457, and 2582) more or less depend on the now deprecated
basic SNA node MIBs, RFCs (1665->)1666 and 1747.  [ "xx->yy"
is my shorthand notation for "RFC xx obsoleted by RFC yy". ]
Arguably, in this case, these dependant RFCs might be considered
candidates for a move to HISTORIC as well.
But there certainly are other cases as well (I have not yet
checked all the details).

It therefore should perhaps be considered to repeat the
RFC 4450 'experiment' with an extended numeric range of RFCs,
e.g. up to RFC 2500.


(3)

On the other hand, the restriction to Standards Track documents
has other undesired implications:

a) In the past, usually at least an Experimental RFC has been
published as a first try for a new protocol (or an Informational
RFC, in the case of a third-party protocol), before a Standards
Track version has been developed.  Unfortunately, in this process
it obviously has been avoided very often to formally OBSOLETE
the predecessor RFC[s] when the Standards Track version has been
published.  (Similar undue 'politeness' can be observed, e.g.,
on the transition path of MIBs from SMIv1 to SMIv2.)
Caused by RFC 4450 we now have non-deprecated RFCs predating
RFCs moved to HISTORIC state.
(The example instances I've been aware of at first glance, though
still being listed as EXPERIMENTAL in the RFC index, fortunately
already had been removed in the past from the 'Experimental RFCs'
Section of rfcxx00.txt .)
It would be very useful, for clarity, to move these RFCs to
HISTORIC status as well.

b) There are 'companion documents' to Standards Track RFCs that
have been published as Informational RFCs for various (legitimate)
reasons.  These RFCs are outdated with their respective related
specifications, and as such, for clarity, should better be moved
to HISTORIC status as well.

For example, IMHO the following Informational and Experimental RFCs,
being closely related to RFCs that now have been deprecated, should
be considered candidates for deprecation (being made HISTORIC) as
well, for clarity, consistency, and/or historical context:

o  RFC 1477 (IDPR Introduction);
o  RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;
o  RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;
o  RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;
o  RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings
            of which (RFCs 1552 and 1553) have been made HISTORIC;
o  RFC 1791 (TCP+UDP over IPX);     \  both still in
o  RFC 1792 (TCP/IPX MIB);          /  rfcxx00.txt !
o  RFC 1834 (WHOIS++ Introduction);
o  RFC 1875 (UNINETT PCA Policy) -- based on PEM.

It might therefore perhaps be useful to perform a RFC 4450 like
'experiment' for Informational and Experimental RFCs as well.


(4)

The restriction in the RFC 4450 effort on Proposed Standards
detracts from the fact that there are [Full] Standard RFCs as
well which are clearly outdated, or of questionable quality and/or
precision.
My personal (incomplete) hot list of candidates comprises:
     STDs 15, 16, 17, 19, 35, 40, 42, 44, 49
(Other legacy Standards doubtlessly should be updated, e.g.
STDs 5, 7, 13.)

Note: In particular the situation with STDs 16+17 is annoying.
      Replacements are established, but vendors do not switch
      to SMIv2 and the newer MIBs (and do not offer SNMPv3,
      with its improved security features!) because these old
      specifications are still listed as Standard.

I also strongly suspect that there are a few Draft Standard RFCs
that might be considered outdated.

It therefore might be worth repeating the RFC 4450 'experiment'
for Draft and Full Standards as well.

It should say:

[see above]

Notes:

From Eliot Lear <lear@cisco.com>

Alfred,

Thanks for taking the time to read the document. I'd like to encourage
you to share your comments with the newtrk working group. You can find
information on how to subscribe by going to http://www.ietf.org and
clicking on "Working Groups".

As to your specific comments...

Alfred ? wrote:
> Hello,
> I'd like to send you a few comments on the recently
> published RFC 4450 (Cruft Removal) authored by you.
>
> First of all, thanks for your effort!
>
> After reading the RFC and looking into the changes
> performed to rfcxx00.txt, I noticed a few issues.
>
>
> (1)
>
> Near the top of page 3, section 3 of RFC 4450 states the
> reasons for removal from the list -- i.e. *not* moving
> to HISTORIC state:
> o RFC 1584 -- an expected future dependency;
> o RFC 1755 -- believed to be actively in use.
>
> Nevertheless, these two RFCs have been moved to HISTORIC
> status along with the publication of RFC 4450, as can be
> seen in rfcxx00.txt .
> This is quite surprising. (Perhaps, you know what happened.)
>
> Preferrably, the final RFC text would better have been
> coordinated with the actual Standards Actions performed --
> for example, by addition of an IESG statement explaining the
> deviation from the text.
>

There was intended to be no deviation from the text. The RFC Editor is
also the one who keeps track of how specifications are classified.
>
> (2)
>
> Due to the 'numeric limitation' applied (restriction to RFCs
> with numbers in the range ~700...2000) there are now a couple
> of RFCs that have lost their 'normative background'.
>
> For example, the higher level SNA MIBs (RFCs 2051, (2155->)2455,
> 2456, 2457, and 2582) more or less depend on the now deprecated
> basic SNA node MIBs, RFCs (1665->)1666 and 1747. [ "xx->yy"
> is my shorthand notation for "RFC xx obsoleted by RFC yy". ]
> Arguably, in this case, these dependant RFCs might be considered
> candidates for a move to HISTORIC as well.
> But there certainly are other cases as well (I have not yet
> checked all the details).
>
> It therefore should perhaps be considered to repeat the
> RFC 4450 'experiment' with an extended numeric range of RFCs,
> e.g. up to RFC 2500.
>

I believe the problem you refer to would occur no matter what point we
stop. Also, at this time the normative limitation is being reconsidered.

>
> (3)
>
> On the other hand, the restriction to Standards Track documents
> has other undesired implications:
>
> a) In the past, usually at least an Experimental RFC has been
> published as a first try for a new protocol (or an Informational
> RFC, in the case of a third-party protocol), before a Standards
> Track version has been developed. Unfortunately, in this process
> it obviously has been avoided very often to formally OBSOLETE
> the predecessor RFC[s] when the Standards Track version has been
> published. (Similar undue 'politeness' can be observed, e.g.,
> on the transition path of MIBs from SMIv1 to SMIv2.)
> Caused by RFC 4450 we now have non-deprecated RFCs predating
> RFCs moved to HISTORIC state.
> (The example instances I've been aware of at first glance, though
> still being listed as EXPERIMENTAL in the RFC index, fortunately
> already had been removed in the past from the 'Experimental RFCs'
> Section of rfcxx00.txt .)
> It would be very useful, for clarity, to move these RFCs to
> HISTORIC status as well.
>
> b) There are 'companion documents' to Standards Track RFCs that
> have been published as Informational RFCs for various (legitimate)
> reasons. These RFCs are outdated with their respective related
> specifications, and as such, for clarity, should better be moved
> to HISTORIC status as well.
>

I think it's a matter of how you want to use the marking of "HISTORIC".
I apply it only to specifications that are only on the standards track.
You are correct that these docs are related, and the ISD effort would
probably merge them, but it's not clear to me how that would affect status.
> For example, IMHO the following Informational and Experimental RFCs,
> being closely related to RFCs that now have been deprecated, should
> be considered candidates for deprecation (being made HISTORIC) as
> well, for clarity, consistency, and/or historical context:
>
> o RFC 1477 (IDPR Introduction);
> o RFC 1482 (NSFNET Policy-Based Routing Database) -- IDPR related;
> o RFC 1585 (MOSPF Analysis and Experience) -- depending on RFC 1584;
> o RFC 1593 (SNA APPN Node MIB) -- 1st ed., eff.->2155->4255;
> o RFC 1634 (IPX over WAN Media) -- successor to RFC 1551, the siblings
> of which (RFCs 1552 and 1553) have been made HISTORIC;
> o RFC 1791 (TCP+UDP over IPX); \ both still in
> o RFC 1792 (TCP/IPX MIB); / rfcxx00.txt !
> o RFC 1834 (WHOIS++ Introduction);
> o RFC 1875 (UNINETT PCA Policy) -- based on PEM.
>
> It might therefore perhaps be useful to perform a RFC 4450 like
> 'experiment' for Informational and Experimental RFCs as well.
>
>
> (4)
>
> The restriction in the RFC 4450 effort on Proposed Standards
> detracts from the fact that there are [Full] Standard RFCs as
> well which are clearly outdated, or of questionable quality and/or
> precision.
> My personal (incomplete) hot list of candidates comprises:
> STDs 15, 16, 17, 19, 35, 40, 42, 44, 49
> (Other legacy Standards doubtlessly should be updated, e.g.
> STDs 5, 7, 13.)
>
> Note: In particular the situation with STDs 16+17 is annoying.
> Replacements are established, but vendors do not switch
> to SMIv2 and the newer MIBs (and do not offer SNMPv3,
> with its improved security features!) because these old
> specifications are still listed as Standard.
>
> I also strongly suspect that there are a few Draft Standard RFCs
> that might be considered outdated.
>
> It therefore might be worth repeating the RFC 4450 'experiment'
> for Draft and Full Standards as well.
>

And you might want to run that experiment. We had to start somewhere.
There is clearly more cruft.

Thanks,

Eliot

from pending

Report New Errata