Re: RFC abbreviations list

[John C Klensin <[e-mail]>]

Toerless,



--On Sunday, July 26, 2020 00:57 +0200 Toerless Eckert
<[e-mail]> wrote:

> Well, i will invite you to the next discuss where an AD wants
> to educate a WG as to the appropriate use of some
> abbreeviation for a new expansion by referring to the RFC
> abbreviation list.

Let me start where Joel left off: the criterion for the list
(and both the list and the criteria predate the IETF) is that
the abbreviation be well-known and immediately obvious to anyone
with a significant Internet technical or operational background
and experience.  Not just IETF participants, not just experts on
a particular topic or in a particular topic area (whether
matching IETF Areas or not).  That involves judgment calls, but
that is one of the reasons we've had (again, since before the
IETF) an RFC Editor who is either skilled in the technology and
its terminology or, in more recent years, an RFC Series Editor
who is skilled in technical publications and who can and will
reach out for advice as needed.

Because the list involves judgment calls, I'm quite confident
that, if any one or us were to go through the list, we would
find some things we would think don't belong there and others
that we would think are missing.  Whether those conclusions
would get IETF consensus if the conclusions were organized and
turn into a question is, IMO, doubtful although I'm quite
confident that debates over particular terms could and would
consume a huge amount of time.  Even if it did get IETF
consensus, that might not be relevant.  Not even readers of RFCs
because, for example, if someone reads relevant RFCs and writes
a book or tutorial that draws on them, many of us have assumed
over the years that the IETF and RFC user communities prefer
that any abbreviations that are used are used the way we use
them and that other abbreviations be carefully defined and
identified as not being widely used in the industry.

The IETF does have a way to affect the list and that is the
development of a standards track or BCP "terminology"
specification.  If one of those suggested a particular
abbreviation for a well-known term, I'd expect the RFC Editor to
take note, but, even then, "taking note" should not imply an
automatic addition to the list.

> I for once don't think it is difficult to get things added.
> Indeed, i have simply added to my drafts an RFC-editor note
> stating which new abbreviations i would like to have added,
> something i think that should bhave been done for other now
> ubiquouts abbreviations as well.

If the decision to add, or not add, an abbreviation is based on
whatever you (or Joel, or myself, or even the IESG) consider
ubiquitous rather than a broader assessment (for which our
beliefs might reasonably be input) then, IMO, something is
broken... and broke fairly recently.

I do disagree with Joel about discarding the list because it
serves another purpose, a purpose not unlike that of many IANA
registries.  To use an example that I hope is obviously silly
enough to avoid offending anyone, suppose you came up with a new
model for talking about control planes in conjunction with the
Internet or technology used for the Internet.  And suppose you
and your colleagues consistently referred to it as "Toerless's
Control Plane".  Regardless of how popular and important it
became, I think it should never be referred to, especially in
the RFC Series, as "TCP".  And I would expect the RFC Editor to
push back on that abbreviation, even if it were defined for use
within the specific defining specification and somehow got past
IETF Last Call and the IESG (or other Stream Manager).  From
that perspective, the list is not only a list of well-known
abbreviations but a list of reserved ones.
 
> Just as a reminder, why this thread came into place: I think
> we're not doing a well structured job on the RFC abbreviations
> list and i was just pointing that out as a bad example for how
> to not do things for someting like a "recommended new
> replacement acronyms" list that probably would ahve to evolve
> from that other folks thred we're just having here on the list.

I trust that the people who make up the RFC Editor function will
carefully consider your suggestion, presumably after a new RSE
is selected and on the job.

best,
   john