Broken standards statuses (was Re: TELNET to HISTORIC Re: FTP)

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

On 8/2/24 12:06, Rob Wilton (rwilton) wrote:

Hi John,

 

For me, I think that the key here is not to get wrapped round the axle of IETF process and to do the right thing for the Internet community and end users.  I.e., the real aim here is that we should be trying to ensure that IETF and the standards process continues to be relevant to the wider technical community.

Your point that the SSH RFC is only PS and TELNET is IS effectively shows how splitting the classification between IS and PS is effectively broken.  The same logic flaw exists with HTTP 1/1 (RFC 9112) that was recently reclassified as IS and HTTP/2 (RFC 9113) that is PS.  Does this mean that the Internet at large should really be deploying the mature internet standard HTTP 1/1 rather than “proposed standard” HTTP/2?  The reality that I see is that most companies believe the work is done when the PS RFC is published and don’t care for the additional work to advance to IS, which also by that time they have probably moved on to developing other protocols or extensions.

 

[...]

IMO several things are broken:

1. The idea of HISTORIC is broken, especially if that's seen as a terminal status for a specification.      We don't use computers in the same way from one decade to the next; the usage scenarios for DecSystem-10s in the early 1980s are very different than that of typical computers today (whether they be PCs, tablets, phones, appliances, or whatever), and the usage scenarios can be expected to keep changing and becoming more diverse.   And of course the network environment also keeps changing and (perhaps unfortunately) network environments keep becoming more diverse.  So a specification that was once applicable for common use cases may not be applicable for future use cases, even if the standard remains robust when evaluated according to its original requirements.  

I think the problem is that we're conflating maturity and applicability into a single keyword.     The notion of HISTORIC is broken because it assumes that there's really only one usage scenario that matters, and also because the network is becoming more diverse.   It's tempting to ask "HISTORIC for what purpose?".    Most specifications that were once robust don't become useless, they just become less generally applicable than they once were.

Lots of old specifications are of limited applicability today but are still robust for some purposes.    RS-232, for example, is still useful in certain scenarios.   There's nothing wrong with even new designs using it as long as the designers are aware of its limitations.  

(I also remember once seeing some plans for a swinging cable bridge over a river, as part of a walking trail at a Tennessee state park.   The plans cited some ancient US Bureau of Mines specification.   But presumably the engineering of that specification was sound, and where else will you find robust specifications for that kind of a bridge?)

So maybe we'd be better off not trying to reclassify specifications as HISTORIC, or using such a classification only in very rare cases. 

2. Even the progression from Proposed to (full) Standard isn't terribly useful, since both vendors and users feel perfectly capable of evaluating those specifications' applicability for themselves.   In general, updating old RFCs for working protocols is not only very consuming of the community's energy, it seems to carry with it as many risks as benefits.   There's nothing wrong with maintaining errata (which of course we do anyway), but we shouldn't assume that such transitions require RFC updates.   I'd recommend that we NOT do major updates of old RFCs without compelling reasons, and maybe don't update them at all.   Instead, let people submit interoperability reports online, and automatically reclassify the old specification as Full Standard once (a) N years have elapsed since original publication; (b) there are sufficient (verified) interoperability reports; and (c) IESG determines that there are no major identified flaws in the specification not fixed by published errata.   Also, let people submit statements about applicability (for and/or against) and maintain those statements in a way similar to the way that errata are maintained.

If we can spend less time going over old specifications with fine-toothed combs, maybe we could start to address major deficiencies in the Internet architecture.

Keith