Toerless, --On Sunday, July 26, 2020 00:57 +0200 Toerless Eckert <tte@xxxxxxxxx> 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
