--On Monday, January 6, 2025 10:22 +0000 "Rob Wilton (rwilton)" <rwilton=40cisco.com@xxxxxxxxxxxxxx> wrote: > A digression, but I don't think that "proposed standard" and > "standard" are really well understood, given that the IETF has > published 1000's of proposed standards, but IIRC, less then 100 > have reached the elevated status of being actual "Internet > Standards". One perverse interpretation of this could be that > the IETF has fundamentally failed in its mission of publishing > mature standards … but given that I think that the IETF has > actually been very successful, the much more plausible explanation > is that reaching "Internet Standard" basically doesn't matter > to anyone who is consuming (i.e., reading or implementing) RFCs. I think we are saying the same things about that, but your explanation of the problem is better. > Some may argue that we should spend lots of time upgrading many of > the Proposed Standard documents to Internet Standard documents, but > why? It would just be busy work since everyone implementing these > regards "proposed standard" as being sufficient and effectively > the same as "standard" anyway. Instead, the sensible thing is > to call a spade a spade and drop the "Proposed Standard" > category altogether and just publish "Internet Standards", but > with an updated RFC 2026 definition. > > But my wider point is that in many cases, the consumers of RFCs are > not intended to be the IETF audience, but the broader internet > community. For me, a good solution here would be one that ticks 3 > boxes: > > (i) it is relatively easy to implement without too > much work, > > (ii) it can be done in an iterative fashion, and > > (iii) it is easy for the end consumer to understand > (which I think is the most important one). > > I don't think that creating new magic words that none of the > wider community understand is going to help. What we need is the > extra metadata associated with an RFC (such as its current status, > and whether there are any errata to be applied, to be present in a > clearly visible banner whenever someone tries to access the > document). > > Ultimately, what is easier for the end consumer to understand? A > category marker like "Historic" or "IETFStatusCategory1" or > a block of meta-data text, something like "Before considering > this protocol, please be aware that as for January 2025, this > protocol is no longer being developed or maintained by the IETF. > The protocol may still be secure, or it could have serious > vulnerabilities." I'm sure that others on this list could come > up with much better prose, but hopefully that makes my point. To > give a more concrete example, this banner could be like the "This > document is an Internet-Draft (I-D). Anyone may submit an I-D to > the IETF. This I-D is not endorsed by the IETF and has no formal > standing in the IETF standards > process<https://datatracker.ietf.org/doc/rfc2026/>." banner that > gets shown on unadopted individual drafts. We would show a similar > banner when attempting to access an old RFC. I _think_ there are only two differences between the "IETFStatusCategory1" idea and your metadata proposal. (1) The label was intended simply as a pointer to the metadata. Spelling things out is equally good or better except that, in talking with each other, people usually prefer (or invent) short terms to replace sentences. The banner to which you refer is actually an excellent example -- the banner is there, but if someone asks someone else what sort of document it is or what its status is, the response is "Internet-Draft" or "I-D", not a recitation of the sentence (even without the URL). (2) "whenever someone tries to access the document" is actually complicated. Unless we want to change several other things with, at least IMO, far more important implications than this discussion, we still allow, and even encourage) mirrors and archives of the RFC collection and private copies of RFCs (not that we could prevent them). While various recent changes seem to be eroding the principle, we advertise RFCs as static documents, not ones whose language about status might change between accesses. Those are the reasons why a few of us have encouraged doing what might seem to be the opposite of your proposal but that differs only in an important detail: eliminate all status and category information from RFCs (or at least Standards Track ones) and replace it with a sentence that says that, which the document is static, that information is not and that <URL> should be checked for the most up-to-date information. That URL would be per-document and would point to exactly the metadata you are suggesting, perhaps with a supplemental short label and/or, when needed, an explanation of any properties of the document that make it a special case such as "updated by" or "replaced by" information. > Hence, I'm proposing that we define a few different categories > (give them a separate label, or just put them under historic) and > then we create half a dozen versions of the different boilerplate, > and allow it is to be extended, or maybe even modified, to allow > additional context information to be given). I think we are in complete agreement there. best, john > From: John C Klensin <john-ietf@xxxxxxx> > Date: Monday, 6 January 2025 at 05:46 > To: touch@xxxxxxxxxxxxxx <touch@xxxxxxxxxxxxxx> > Cc: George Michaelson <ggm@xxxxxxxxxxxx>, IETF Discussion Mailing > List <ietf@xxxxxxxx> Subject: Re: "Historic" is wrong > > > --On Sunday, January 5, 2025 19:41 -0800 touch@xxxxxxxxxxxxxx wrote: > >> Hi, John, >> >>> On Jan 5, 2025, at 7:29 PM, John C Klensin <john-ietf@xxxxxxx> >>> wrote: >>> >>> Again, this is just proving my point so, once again and then I >>> will stop. _Any_ words we pick that have well-known external >>> meanings and connotations will be problematic. I think I agree >>> with Brian about a new set of magic words, but am suggesting they >>> really need to be IETF-unique (a close approximation to "magic" >>> in this context). >>> >>> Recommendation for consideration with the understanding that I >>> don't have any attachment to the words before the digit (and it is >>> clearly too long a string): >>> IETFStatusCategory1 >>> IETFStatusCategory2 >>> IETFStatusCategory3 >>> IETFStatusCategory4 >> >> But then we need to define the terms and inevitably will find >> ourselves back to the same problem. > > Up to a point, yes. But we at least then don't need to try to > overcome years of history and knowledge about what words mean > everywhere else. > >> I do like terms that try to avoid ambiguity, so nuances like >> "deprecated" vs "superseded" are not helpful, IMO. > > Agreed. And I like your two-dimensional idea too. > >> The ones I provided I believe are relatively unambiguous: >> protocols: >> experimental >> proposed standard >> standard >> legacy >> not recommended (could be "hazardous") > > I think that works but see below and note that, even among these, > "proposed standard" today is a relatively mature document with the > expectation in many cases of one or more tested implementations, > while, back in the early 1990s, a document could get into that > category when it was not much more than a design proposal as long as > there were no known outstanding design issues, was well-understood, > etc., with no requirement and usually no expectation of > implementations of implementation or operational experience (see RFC > 1310 Section 3.2.1). So even that set of terms may be relatively > unambiguous, but only relatively so. > > One also needs to account for Informational and BCP documents, which > can also descend into "legacy", "not recommended", or "path not > chosen" (which is really neither of those two), or, at least in > principle in the former case, ascend into Proposed Standard or BCP. > >> documents: >> (no label) implies current >> "revised by" indicates a better document is >> available >> >> Documents are revised when needed, but there is NO reason to say >> that the spec for NFSv3 is "revised by" the spec for NFSv4. We >> revise documents as we did for RFC793 and RFC2401, but NOT (IMO) >> when we create a new protocol per se. The spec for NFSv3 is not >> "revised" by the spec for NFSv4; the *protocol* is. > > That case is clear but consider two others (about which I'm > obviously sensitive) and tell me where they fit: > > (i) RFC 1425 adds a command and significant logic to RFC 821. RFC > 821 had no provision for that sort of change. In 1993, RFC 1425 was > not listed as updating 821; today it probably would be. However it > clearly revises 821 somewhat even though it does not in any way > replace it. At the time implementations of 1425 started to > appear, we hoped that no one would implement 821 alone because 1425 > provided new and important features, but 1425 was no a "better > document" than 821 because it merely added functionality in a > forward-compatible way. To further complicate this example, RFC > 974 updated 821 by changing the mail routing architecture but is > not listed as having updated/revised it and, AFAIK, the use of the > mail routing mechanism described in 974 did not become the required > replacement for that described in 821 until RFC 1123 (which is not > listed as updating either of them). Tell us how your proposed > system would deal with that can of worms and others like it, at > least without case by case reanalysis of every older protocol. > > (ii) Moving on, we have RFC 5321 which succeeded (sic) RFC 2821, > which revised and replaced, not only 821 and 1869 (the replacement > for 1425 once removed) but RFC 974. Now 5321 is clearly a "better > document than" 2821, but its relationship to the earlier specs is a > bit unclear. FWIW, there has been an extended discussion on > another list initiated by someone who has insisted that it is > perfectly reasonable to implement RFC 821 today because, while it > is listed as being obsoleted by 2821, is still an Internet Standard > (as part of STD0010). The other two parts of STD0010 are RFC 1869 > (see above), also listed as an Internet Standard, and RFC 974 which > someone managed to get classified as Historic. > > At a very minimum, the above suggests to me that we have made rather > a mess that mere juggling with terminology is not going to fix > unless we have enough terminology categories to deal with some > rather odds cases or combinations of them. > > best, > john >
