Subject: [newtrk] Question about Obsoleted vs. Historic

From: <[email-masked]>
Date: Mon, 11 Jul 2005 09:54:14 +0300

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?

John

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 11 Jul 2005 10:13:54 +0200

On 11-jul-2005, at 8:54, [email-masked] wrote:

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

...or BCP:

3152 Delegation of IP6.ARPA. R. Bush. August 2001. (Format: TXT=5727
      bytes) (Obsoleted by RFC3596) (Updates RFC2874, RFC2772, RFC2766,
      RFC2553, RFC1886) (Also BCP0049) (Status: BEST CURRENT PRACTICE)
.
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, 11 Jul 2005 12:02:45 +0200

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

Eliot

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

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 11 Jul 2005 06:16:41 -0500

> What is the reason for continuing to list something obsolete as a 

Ummm, because most people don't notice standards maturity levels?

But the idea of an "obsolete Best CURRENT Practice" makes MY head 
hurt...

Spencer 

.

---

From: Bruce Lilly <[email-masked]>
Date: Mon, 11 Jul 2005 07:56:10 -0400

> What is the reason for continuing to list something obsolete as a Draft Standard?

Lack of action by the IESG.  The RFC Editor maintains the rfc-index, and
as far as I can tell does a good job of handling the updates/obsoletes/
updated by/obsoleted by information.  Moving an RFC from the Standards
Track to Historic, however, requires a Standards Action which has to
be approved by the IESG per BCP 9, either as part of the review process
(section 6.2) which the IESG ignores, or per section 6.4.  In practice
moving a document to Historic only seems to happen as a result of a rather
complicated process where somebody writes yet another RFC suggesting a
reclassification of some RFC as Historic, which if approved leads to
the Standards Action (see draft-lear-newtrk-decruft-experiment-00.txt).

Other cases include full Standards which have been obsoleted, such as
STD 10 and STD 11.
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jul 2005 15:23:31 +0200

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

.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Jul 2005 08:21:19 -0700

>What is the reason for continuing to list something obsolete as a Draft Standard?

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.
				regards,
					Ted
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jul 2005 17:35:44 +0200

Bruce Lilly wrote:
> Lack of action by the IESG.  

No, lack of action by the community to request moving documents to Historic.

And confusion in the standards process as to whether a new PS or DS truly
replaces an old STD, but that's something we've already beaten to death in newtrk.

    Brian

.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 11 Jul 2005 11:51:49 -0400

> No, lack of action by the community to request moving documents to

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.

Henning
.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 11 Jul 2005 21:09:29 -0400

On Monday, July 11, 2005 09:54:14 AM +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:
>
> 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.
>

I think there is a bit of confusion here.

"Obsoleted by RFCxxxx" does _not_ mean that the technology or protocol
described in the present document is obsolete.  It does not even mean that
the specification contained in the document is obsolete.  What it means is
that RFCxxxx contains a newer version of the same specification, which
stands on its own.  By contrast, "Updated by RFCxxxx" means that RFCxxxx
extends or updates the specificiation, possibly even resulting in a new
version, but also requires reading the present document -- it does not
stand on its own.

Described another way, if one document "updates" another, it is the moral
equivalent of a patch.  If a document "obsoletes" another, then it is like
a complete copy of the new file (and often is exactly that).

These notations are intended to help find older and newer versions of a
specification, extensions, base documents, etc.  They are entirely about
document history, and are orthogonal to the progression of a specification
through the standards process.  For example, it is entirely reasonable and
even common to have "RFCxxxx obsoletes RFCyyyy", where RFCxxxx is at
Proposed and RFCyyyy is at Draft or is even a full standard.

Now in the particular case at hand, it is entirely possible and even likely
that the intent is for RFC3912 (also at Draft) to eventually progress to
full standard in the place of RFC954.  It can be reasonably argued that in
such a case, the publication status of RFC954 should be changed, and even
that it should have been changed by RFC3912.  It's just (apparently) not
what has always been done.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA
.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html