Subject: RFC 4450

From: Alfred Hönes <[email-masked]>
Date: Tue, 18 Apr 2006 16:05:37 +0200 (MESZ)

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.

(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.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+