Re: "Historic" is wrong

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

 

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.” banner that gets shown on unadopted individual drafts.  We would show a similar banner when attempting to access an old RFC.

 

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

 

Kind regards,
Rob

 

 

 

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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux