Subject: RE: [newtrk] Re: Question about Obsoleted vs. Historic

From: [email-masked]
Date: Tue, 12 Jul 2005 09:02:19 +0300

Brian,

> Sure, but the logic is nevertheless a bit contorted - but rather than
> debating what the current system *means* could be concentrate
> on what we should do in future?
> 
> Incidentally 3596 (a DS) obsoletes 3152 (a BCP). That's unusual,
> but it isn't illogical. However, 3152 isn't shown as Obsolete
> in http://www.rfc-editor.org/rfcxx00.html#BCPbyBCP.
> 
>      Brian
> 
> Eliot Lear wrote:
> > I would point out that it is historically useful to be able to track
> > changes between draft and full or proposed and draft and we don't list
> > status information in the RFCs...

What I would like is that the RFC Index would accurately convey the current
status of any RFC.  So, if I needed to check the status of a protocol which
I am not intimately familiar with, I would not need to subscribe to a WG
mailing list or ask an IESG/IAB/WG chair to interpret the RFC List for me.

Its past the new draft cut-off, but if the RFC Editor was willing & a Tools
Team member was willing (& at least a few people thought it was useful) perhaps
we (together) could mock-up an improved RFC Index.

John

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Bruce Lilly <[email-masked]>
Date: Tue, 12 Jul 2005 10:02:51 -0400

> mailing list or ask an IESG/IAB/WG chair to interpret the RFC List for me.

I believe that the rfc-index does accurately convey status to the extent
that it can w/o stepping on the IESG's toes.  E.g.

0822 Standard for the format of ARPA Internet text messages. D.
     Crocker. Aug-13-1982. (Format: TXT=109200 bytes) (Obsoletes RFC0733)
     (Obsoleted by RFC2822) (Updated by RFC1123, RFC1138, RFC1148,
     RFC1327, RFC2156) (Also STD0011) (Status: STANDARD)

says that RFC 822 has been designated as a full Standard (and the IESG has
initiated no Standards Action to change that status), and that it has been
updated by a number of subsequently issued RFCs and eventually has been
obsoleted by RFC 2822.  It also notes that 822 had obsoleted RFC 733.

> if the RFC Editor was willing & a Tools

The root of the problem is that a change in status requires IESG action,
the IETF having given the IESG the authority and responsibility for said
action via BCP 9 (RFC 2026).  Now if the IETF wants to take that authority
away from the IESG (which has not lived up to its responsibility under
BCP 9) and hand it to some other group, that's a possibility.  Failing
some procedural fix to actually update status in a responsible and timely
manner, there's not much that can really be done with the index' content
w.r.t. status.

Now it may well be the case that the three levels of the Standards Track
are insufficient to convey nuances such as a technology having a high degree
of maturity, but the specification (having been rewritten) is at a low
level of maturity.  Addressing that distinction would also seem to
require a change to BCP 9 to differentiate maturity of a technology from
that of a specification.  Until we have a procedure for establishing
consensus-based separate designations for technology/specification
maturity (or delegate decision for one or the other rather than using
IETF consensus) there is again little that can be done with the index
content.