Re: [Cbor] Draft text for pull request for tag range IANA allocation policy

[Sean Leonard <[e-mail]>]

On 8/14/2019 10:02 AM, Carsten Bormann wrote:
> On Aug 14, 2019, at 18:52, Sean Leonard <[e-mail]> wrote:
>> The other problem is that we are already half exhausted out of the 32-255 range. It's going to go entirely pretty soon.
> The 1+1 range is 24..255, i.e., 232 entries.  ~50 of that are in use after 5.5 years (including the ones in the initial assignment wave).

Perhaps but we did use up a whole block of 24 all at once with 
array-tags. If we do that more often, it's going to go very fast. If we 
put our foot down and say that won't happen, it will take much much 
longer. I think it will be somewhere in the middle where blocks of 2-16 
are allocated at once.

For the sake of argument let's say that Specification Required with 
"reluctance when it is not an RFC document" is the way the WG decides to 
go, for values to 255. What is the level of review for 255-4095? What 
about 4096-32767?

~~

We have another problem in that a lot of the Specification Required 
registrations in the current registry don't actually comply with 
Specification Required in RFC 8126. RFC 8126 says:

"the values and their meanings must be documented in a permanent and 
readily available public specification, in sufficient detail so that 
interoperability between independent implementations is possible. ... 
with the additional requirement of a formal public specification ... 
evaluate whether it is sufficiently stable and permanent, and 
sufficiently clear and technically sound to allow interoperable 
implementations ... The intention behind "permanent and readily 
available" is that a document can reasonably be expected to be findable 
and retrievable long after IANA assignment of the requested value.  
Publication of an RFC is an ideal means of achieving this requirement, 
but Specification Required is intended to also cover the case of a 
document published outside of the RFC path..."

Actually a lot of the registrations have been to GitHub links. GitHub is 
not sufficiently stable and permanent, nor is it "expected to be 
findable and retrievable long after IANA assignment of the requested 
value...", nor is it really "published" in the RFC 8126 sense. The data 
may be around for right now but anybody can delete their Git 
repositories, or worse, assert their Right to be Forgotten under EU GDPR 
or California's CCPA (2020).

The point of Specification Required is that it's the work product of 
another publishing group, or is part of published and relatively stable 
software, such that many eyes have been on it. I consider the 
documentation for Philip Hazel's PCRE, or documentation for widely 
distributed software (Microsoft technical documents, Linux kernel 
distributions, SSH man files) to meet this standard. But not just a 
GitHub link.

Regards, Sean