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

From: Bob Braden <[email-masked]>
Date: Mon, 11 Jul 2005 10:53:57 -0700

At 09:54 AM 7/11/2005 +0300, [email-masked] wrote:
>Hi,
>
>I was wondering if someone could help me out on this one.  I was doing a bit
>of analysis on the current RFC list, and noticed that some Draft Standard
>documents are obsoleted.  For example:
>
>  954 NICNAME/WHOIS. K. Harrenstien, M.K. Stahl, E.J. Feinler.
>       Oct-01-1985. (Format: TXT=7397 bytes) (Obsoletes RFC0812) (Obsoleted
>       by RFC3912) (Status: DRAFT STANDARD)
>
>This really made me scratch my head. One would imagine if a protocol is 
>obsoleted
>by another, it would not be listed as a Draft Standard any longer.
>
>What is the reason for continuing to list something obsolete as a Draft 
>Standard?

Because Jon Postel always did it that way?  Seriously, the idea is that the 
document
was a Draft Standard when it was published.  You can obsolete it, but you 
cannot
change its publication status.  Should its status change to Historic when it is
obsoleted? Maybe, although we have never done it that way (and we do have 20+
years of history).

         (Note that in fact the RFC Editor added "publication status" to 
its index
         database last year; the new field is included in rfc-index.xml.  This
         shows the status upon publication, in cases where the status is
         changed later.)

There are quite a few twisty little passages lurking here, and they mostly 
stem from
a basic semantic confusion between a document (RFC) number and the protocol
that is specified in that document (or maybe not).  The RFC number is in fact a
document number, but we have chosen to overload it as a protocol designator.
We say "RFC 793" or "TCP" more or less interchangeably, but 793 is really
only a document.

In my view, a result of the ISD proposal in newtrk should be to cleanly 
remove this
semantic overloading of RFC numbers. An ISD would define a protocol 
independent of
a document identifier (RFC number).  I believe that we should move with all
deliberate speed to engineer an ISD-based system for IETF standards, rather 
than
to make small patches to RFC designations.

Bob Braden

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

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: <[email-masked]>
Date: Tue, 12 Jul 2005 06:38:48 +0300

Hi John K,

> >> 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...
> > 
> > I agree with that.
> > 
> > And, my head still hurts thinking about why we'd leave
> > something as a  "Proposed Standard" when its been obsoleted.
> > Seems more like an "Obsolete Standard" ... but perhaps I am
> > just nit-picking.
> 
> If, as a community, we cared, we could easily have both the
> tracking information and the status by introducing the
> little-known term "former", as in "Obsolete, former Draft
> Standard".
> 
> Of course, how many procedural hoops we'd have to jump through
> to get there is another issue.

That seems like the most reasonable approach, to me - putting the
'former' tag, not having to jump through procedural hoops ...

John L.

.

---

From: <[email-masked]>
Date: Tue, 12 Jul 2005 07:58:47 +0300

Brian,

> >>What is the reason for continuing to list something 
> obsolete as a Draft Standard?
> > 
> > 
> > Lack of action by the IESG.  
> 
> No, lack of action by the community to request moving 
> documents to Historic.

Section 6.2 of 2026 does say the following:

   When a standards-track specification has not reached the Internet
   Standard level but has remained at the same maturity level for
   twenty-four (24) months, and every twelve (12) months thereafter
   until the status is changed, the IESG shall review the viability of
   the standardization effort responsible for that specification and the
   usefulness of the technology. Following each such review, the IESG
   shall approve termination or continuation of the development effort,
   at the same time the IESG shall decide to maintain the specification
   at the same maturity level or to move it to Historic status. 

My guess is that anything marked as obsolete will be stuck at its
current maturity level in perpetuity, making it a good candidate to
go to Historic. 2026 seems to state that the IESG will handle this.
However, Eliot's Crust removal draft could come to play here.

John

.

---

From: <[email-masked]>
Date: Tue, 12 Jul 2005 08:01:16 +0300

Henning,

> > No, lack of action by the community to request moving documents to 
> > Historic.
> 
> There seem to be a number of these housekeeping tasks that have almost 
> no benefit to the individual, have increasing costs and ever longer-term 
> commitments and thus, not surprisingly, don't get done on a regular 
> basis. Promotion and demotion of standards are prime examples, reviewing 
> is another.
> 
> Besides appealing to community spirit, other organizations deal with 
> that by deputizing individuals that get recognized for doing this type 
> of work in general, in one way or the other. This can take the "New 
> York's Strongest" (Dept. of Sanitation) or the "XYZ 
> secretary" approach.
> 
> In many cases, people do unpleasant or boring or no-immediate-reward 
> tasks in hope of getting promoted later - this is why I suggested WG 
> secretaries earlier and maybe why having elected IESG secretaries or the 
> IETF Dept. of Public Works ("just leave your old standards at the curb") 
> might be needed.

Have you seen draft-ietf-newtrk-cruft-00?  It proposes something along
these lines.

John

.

---

From: <[email-masked]>
Date: Tue, 12 Jul 2005 08:03:57 +0300

Ted,

> I've assumed that it was to tell you it was at Draft Standard when the document
> that replaced it was issued.  That way you can tell whether the new doc is
> a recycle-in-grade, an update to get something to the next step, or a downgrade.
> The real meat of the data here, though, is that you should look at 3912 if
> you want the current spec.  Any other data about an obsolete spec is for
> historical interest only.  If I'm right, that could be made clearer (by saying
> "Status when active:" or some such), but that doesn't really change meat of the
> information.

I'd strongly suggest some tag to indicate that its no longer active. In many cases,
a Standard is marked Obsolete because it has been updated for some reason; often
times because of some critical bug or other issues.  I don't think the IETF
wants to recommend an obsolete standard as something folks should go and implement.

John

.

---

From: <[email-masked]>
Date: Tue, 12 Jul 2005 08:22:36 +0300

Bob,

A question for you:

> document was a Draft Standard when it was published.  You can obsolete 
> it, but you cannot change its publication status.  Should its status change to 
> Historic when it is obsoleted? Maybe, although we have never done it that way 
> (and we do have 20+ years of history).

First off, 2026 says:

4.2.4  Historic

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete is
   assigned to the "Historic" level. 

So, it would appear, to me, that anything that has been obsoleted is, in fact,
Historic.  But perhaps I am nit-picking.

My question is - what do we mean by an Obsoleted Proposed Standard?  Does this
have any relevance?  What I am still confused about is that, for a particular
technology, what does the IETF 'recommend' or would want to see implemented
for a particular standard?  Obviously, Historic carries the connotation that
the IETF doesn't suggest to be implemented.  Does the IETF think that Standards
that have been Obsoleted SHOULD be implemented or SHOULD NOT be implemented?
If I wanted to do something and had 2 protocols to choose from, one that was
Proposed Standard and one that was Obsolete but Full Standard, which one 
would the IETF like that I implement?  

Perhaps I am asking to much from the RFC Index (http://www.ietf.org/iesg/1rfc_index.txt)
but one would think that we could provide a meaningful way to convey what
we think of our own technology?

>          (Note that in fact the RFC Editor added "publication status" to its index
> There are quite a few twisty little passages lurking here, and they mostly stem from
> In my view, a result of the ISD proposal in newtrk should be to cleanly remove this
> semantic overloading of RFC numbers. An ISD would define a protocol independent of
> deliberate speed to engineer an ISD-based system for IETF standards, rather  than

Well, you can guess my position on this as well.

thanks,
John

.

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 13 Jul 2005 08:20:53 -0400

On Wed July 13 2005 01:43, [email-masked] wrote:

> > 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.
> 
> There's 'accurate' and there's 'meaningful' - I'll give you the point that
> it may be accurate, but I am not ready to buy that its meaningful.

John, what specifically do you believe is a problem that is within the
jurisdiction of the RFC-Editor (N.B. Status is set by a Standards
Action, which is IESG's job, and has categories specified in BCP 9)?

> There could be some tweaking, IMO.  I don't believe we've specified what
> format the RFC Index must take, Bob Braden seemed to say that the current
> form is historical in nature.

Yes, and the index is useful for many things, such as for generating
references to RFCs for Internet-Drafts.  Changing the format may impede
such things, and there may be any number of tools which use the
rfc-index format (which already has a number of distinctly different
sections, e.g. look at the publication date formats).  Regarding
references, although the RFC-Editor has an "rfc-ref" file (
ftp://ftp.isi.edu/in-notes/rfc-ref.txt ), were I to wish to refer to
RFC 4130 (the most recent one in rfc-ref), I would generate a
reference from the rfc-index rather than use the data in rfc-ref,
i.e. it would look like:

   [R1.RFC4130] Moberg, D. and R. Drummond, "MIME-Based Secure
                Peer-to-Peer Business Data Interchange Using HTTP,
                Applicability Statement 2 (AS2)", RFC 4130, July 2005.

That is generated from the rfc-index by an awk script (
http://users.erols.com/blilly/formatting/rfcref )
and does not resemble in the least the line from rfc-ref:

RFC4130 |           | Gurwitz, "", RFC 4130, September 1982.

Before making further changes to the format, the benefit of such a
change should be carefully weighed against the costs, which includes
rewriting such tools as various IETFers may have for doing things
like generating references, analyzing dependencies, etc.  By the way,
the script that generates references also analyzes dependencies and
will cause a diagnostic to be issued if reference is made to an RFC
which has been updated or obsoleted, e.g. reference to STD 11:

WARNING: -:2: STD 11 -> RFC 822 is obsoleted by RFC 2822
WARNING: -:2: STD 11 -> RFC 822 is updated by RFC 1123, RFC 1138, RFC 1148, RFC 1327, RFC 2156

   [R1.STD11] Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

> > 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.
> 
> If we are that stuck as an organization, I guess we are well into declining
> relevance.  I think its important that we, as organization, take care of the
> technology and documents we produce - otherwise, what is the point?  
> If we cannot meaningfully convey the status of our documents, why bother?

We (are supposed to) do things by consensus; the current procedure
does not provide for separate designations for the technology and
for the specification, so short of somebody writing an Internet-Draft
proposing some specifics and running it up the flagpole via a request
to publish and the ensuing Last Call, how do you propose to change
that (consistent with established IETF principles)?
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html