RE: [newtrk] Re: Question about Obsoleted vs. Historic
On Tue July 12 2005 02:02, [EMAIL PROTECTED] wrote: > 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. 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 > Team member was willing (& at least a few people thought it was useful) > perhaps > we (together) could mock-up an improved RFC Index. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [newtrk] Re: Question about Obsoleted vs. Historic
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Bob, A question for you: > >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). 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 > 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. Well, you can guess my position on this as well. thanks, John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
On Monday, July 11, 2005 09:54:14 AM +0300 [EMAIL PROTECTED] 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? I think there is a bit of confusion here. "Obsoleted by RFC" 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 RFC contains a newer version of the same specification, which stands on its own. By contrast, "Updated by RFC" means that RFC 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 "RFC obsoletes RFC", where RFC is at Proposed and RFC 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 PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
On 11-jul-2005, at 12:22, [EMAIL PROTECTED] wrote:
The way I understand it, an RFC is only historic(al) if the
technology it
defines is no longer in use.
Well, as Iljitsch mail pointed out, some things (3152 Delegation of
IP6.ARPA)
are moved to Historic when the IETF wants people to stop using
them ...'
For the record:
RFC 3152 basically just says "we now use ip6.arpa rather than ip6.int
for IPv6 reverse DNS" and points to RFC 2874.
RFC 2874 wants us to use bit labels for the reverse DNS (which is
very cool but unfortunately isn't backward compatible and requires
not just a new resource record but a partial rewrite of the software
used in pretty much all DNS servers). RFC 2874 is "experimental" but
that's just pretense, as there aren't currently, nor have there ever
been any bitlabel delegations under ip6.arpa, as far as my research
has been able to uncover.
(RFC 1886 specified the "nibble" format with ip6.int, which looks
like d.e.a.d.b.e.a.f.1.0.0.2.ip6.int.)
So RFC 3152 was never "practice", the alleged practice isn't
"current", and I'll refrain from commenting on "best".
RFC 3596 ("draft standard") finally cleans the whole mess up for the
most part by saying in so many words that people should use the
nibble method with ip6.arpa for the IPv6 reverse DNS, but
unfortunately it claims that RFC 3152 was mainly about s/ip6.int/
ip6.arpa/g, ignoring the whole bitlabel/nibble thing.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
At 09:54 AM 7/11/2005 +0300, [EMAIL PROTECTED] 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
At 9:54 AM +0300 7/11/05, [EMAIL PROTECTED] 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? > >John 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
--On Monday, 11 July, 2005 13:12 +0300 [EMAIL PROTECTED] wrote: > Eliot, > >> 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. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [newtrk] Re: Question about Obsoleted vs. Historic
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... Eliot [EMAIL PROTECTED] 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? John ___ Ietf mailing list Ietf@ietf.org 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
John, > > The way I understand it, an RFC is only historic(al) if the > technology > > it defines is no longer in use. > > Well, as Iljitsch mail pointed out, some things (3152 > Delegation of IP6.ARPA) are moved to Historic when the IETF > wants people to stop using them ...' I think his email read "(Obsoleted by RFC3596)" not historic, which I confirmed at the rfc-editor site. I have read several RFC's that requested historic status for other rfc's and the primary reason given every time was that the technology was no longer in use. See RFC 1360 section 4.1.6. for a definition of historic. > > An obsolete RFC means the technology is still being used, but some > > part of the specification (obsolete RFC) has been updated. An > > obsolete RFC can still be a standard as the RFC that > obsoletes it may > > not change the protocol at all. One example of this is RFC > 3912 which > > is the RFC that obsoletes your example (RFC 954) - read > 3192's abstract for more detail. > > > > This is of course only my understanding. > > If only part has been updated, then the RFC doing the update > should say 'Updates RFC xyz', I think ... But that's what it means to be obsolete - that you've been updated. It doesn't mean broken or wrong, it means older version - so the RFC's are already doing what you suggest because "obsoleted by RFC 808" is the same as "updated by RFC 808". Nick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Nick, > The way I understand it, an RFC is only historic(al) if the technology it > defines is no longer in use. Well, as Iljitsch mail pointed out, some things (3152 Delegation of IP6.ARPA) are moved to Historic when the IETF wants people to stop using them ...' > An obsolete RFC means the technology is still being used, but some part of > the specification (obsolete RFC) has been updated. An obsolete RFC can > still be a standard as the RFC that obsoletes it may not change the protocol > at all. One example of this is RFC 3912 which is the RFC that obsoletes > your example (RFC 954) - read 3192's abstract for more detail. > > This is of course only my understanding. If only part has been updated, then the RFC doing the update should say 'Updates RFC xyz', I think ... John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
Eliot, > 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. John > Eliot > > [EMAIL PROTECTED] 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? > > > > John > > > > ___ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
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 PROTECTED] 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? > > John > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about Obsoleted vs. Historic
John, The way I understand it, an RFC is only historic(al) if the technology it defines is no longer in use. An obsolete RFC means the technology is still being used, but some part of the specification (obsolete RFC) has been updated. An obsolete RFC can still be a standard as the RFC that obsoletes it may not change the protocol at all. One example of this is RFC 3912 which is the RFC that obsoletes your example (RFC 954) - read 3192's abstract for more detail. This is of course only my understanding. Best regards, Nick Staff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, July 10, 2005 11:54 PM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: Question about Obsoleted vs. Historic 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
On 11-jul-2005, at 8:54, [EMAIL PROTECTED] 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) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about Obsoleted vs. Historic
I would assume historical reference. On 7/10/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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? > > John > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
