Re: The IETF, Standards process, and the impact on the RFC series document production

[Nico Williams <[e-mail]>]

On Fri, Oct 04, 2019 at 01:55:15PM -0400, Michael StJohns wrote:
> On 10/4/2019 12:48 PM, Nico Williams wrote:
> > The ITU-T has a much better document naming scheme, and they too have an
> > immutability property.  Thus ASN.1 is the x.680 document series (x.680,
> > x.681, x.682) and the encoding rules for ASN.1 are the x.690 series,
> > and each document gets a "version number" in the form of publication
> > year and month, and old versions remain accessible and unchanged.
> 
> *laugh*  But then you end up with weirdnesses like X.500 vs X.509.  I *know*
> why the certificate stuff started out in Directory oh so many years ago, but
> in hindsight maybe not where it should be today?

You could always assign a new series identifier when an old one stops
bein relevant to a larger family.

And, frankly, though I detest x.400 and x.500 as much as anyone, the
series naming is just fine.  I couldn't care less that ITU-T's PKI
series is x.509 which means it's related to ITU-T's x.500 directory
series.  (x.509 and PKIX being related to x.500 is why we have the
monstrosity of x.500 naming in PKIX, but we're moving past that, and
we've done a lot of PKIX work here instead of there.)

The point is that series naming is very helpful in reducing the number
of things I have to recall in order to find a relevant specification.
Organizing knowledge is, in fact, helpful.

If I'm looking for some ASN.1 encoding rules spec, I just start by
looking for x.690 and go from there.  Try that with RFCs -- you'll need
a search engine, and the RFC-Editor's search engine is damned near
useless, while the I-D tracker is ever so slightly better, but still,
nothing like free-text search.

Now, maybe we just need to improve those search engines, or outsource
the whole thing to general purpose search engines.  But because these
documents are the sort that can be organized with relatively little
effort, doing so seems like no-brainer.

An argument that organizing RFCs this way would be more expensive that
one might think would be an interesting argument.  An argument that it
would be less useful than one might think would also be interesting.

That related series might diverge in time is not really an interesting
argument, IMO.

> Or you end up with something like DNS running out of series numbers
> and others requiring a series for a single document.   ITU tends to be

I wouldn't give lonely RFCs a series number, nor did it follow from what
I wrote that I would.

> MUCH more formal about which documents and standards they will even
> start working on (e.g. a "work plan") before they ever start
> allocating numbers.  They also *require* a document to reviewed each
> period of time and updated - that would be a substantial change to our

Not relevant to the series concept.

> model.   Then you have things like TLS 1.0, 1.1, 1.2 and 1.3 that
> share a negotiating strategy and have similar protocols, but might be
> hard to characterize as the same protocol in the ISO model meaning.

The point is to organize the specs in a meaningful way.  For users and
implementors, organizing TLS 1.0 through 1.3 as a single versioned
series is perfectly reasonable.

If at some point we end up wanting a new series for just TLS 1.53, then
we could do that too.

> If you go into the other direction, you get things like IEEE 802.11 which
> depends on 802.1 and has a bunch of sub standards ( *pun intended*) such as
> 802.11ac and that collection seems to change each time I go looking.

Thus versioning.  There has to be some degree of immutability.  But also
some degree of familiarity where it's useful.

> In any event I think it's TANSTAAFL - you pick one approach, you close off
> others and each has its own flaws.

Not so.  You could have a document appear in any of zero, one, or N > 1
series -- whatever's appropriate.

> I'm not opposed to having the conversation, but we need to pick something
> that works for how we do things, or we need to change how we do standards. 
> And that's a conversation I'm not sure we're quite yet ready to have.

If you laugh at, and discount an idea without considering it in any
seriousness, then you're right: you're not ready to have that
discussion.

Nico
--