Re: RFC abbreviations list

[Carsten Bormann <[e-mail]>]

What I was trying to say was that the bar:

> that
> the abbreviation be well-known and immediately obvious to anyone
> with a significant Internet technical or operational background
> and experience.  

… for getting starred is too high.  RSASSA-PSS is also an example how the “starred” list doesn’t really work that well (the RFC title doesn’t expand it although it is not starred), as are many other cases.

So the putative criteria is wrong, (partially as a result of that, and partially because the whole concept doesn’t quite work) the list is applied inconsistently, and it seems that there is no uniformity in the result.

Looks like something that needs work.

Maybe not urgently, but it is one of those pieces of technical debt that come up each time an RFC is published, the main damage being that their titles are often mangled beyond recognition, which makes them harder, not easier, to understand.

Giving some regular attention (*) to that list could ease the pain, which is what I was trying to point out.  
In the end we’ll also need a better policy to handle the expansion issue.

Maybe all stuff to do for the RSE-ng, but stuff to do it is.

Grüße, Carsten

(*) Randomly poking:

6CIO       - 6LoWPAN Capability Indication (6CIO) 
6CO        - 6LoWPAN Context Option (6CO)

(Both should say “Option”)

ARMv4     *- Advanced RISC Machine version 4 

(This surely shouldn’t be starred under the criteria above, but then it also doesn’t make sense to expand it.  It is used in a single RFC, 6366, in an example.  This is a mid-1990s technology...)

Because the > 2500 lines are in no way sourced or even dated, it does not lend itself to divvying up the work to clean this up.  Maybe some mining in the RFCs can help do that, e.g. assigning IETF areas to the abbrevs.  But we need to understand how this list is being used, how the list could be improved to help these use cases, and what the appropriate criteria might be for them.