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

From: Sean Leonard <[email-masked]>
Date: Wed, 14 Aug 2019 09:07:57 -0700

Was thread with Subject: "[Cbor] CBOR tag range IANA allocation policy"

Three notes to WG:

#1: Specification Required includes Expert Review. Section 4.6 of RFC 
8126. The only way to get Specification Required *without* Expert Review 
under the RFC 8126 framework is basically to have First Come First 
Served with a mandatory field in the registration template for the 
specification. In contrast, RFC 7049 provides a registration template 
where the specification reference is optional.

#2: CBOR implementations need to be able to handle 64-bit tags, although 
they do not need to perform any mathematical operations on them.

#3: The term "generically useful" is from Thiago's 
<mid:15044986.HgQyyibD5o@tjmaciei-mobl1>.

~~~~~

9.2.  Tags Registry

    IANA has created the "Concise Binary Object Representation (CBOR)
    Tags" registry at [IANA.cbor-tags].  The tags that were defined in
    [RFC7049] are described in detail in Section 3.4, but other tags have
    already been defined.

    New entries in the range 0 to 23 are assigned by Standards Action.
    New entries in the range 24 to 255 are assigned by RFC Required.
    New entries in the range 256 to 4095 are assigned by Specification 
Required,
    with an additional consideration that tags in this range
    be considered "generically useful".
    New entries in the range 4096 to 32767 are assigned by Expert Review.
    New entries in the range 32768 to 18446744073709551615 are
    assigned by First Come First Served.

Designers developing or experimenting with tags privately are encouraged 
to use the range 9223372036854775808-18446744073709551615 by picking a 
random tag or block of tags in that range. However, there is no formal 
reservation of that range for any particular purpose, and a tag MAY be 
assigned there at any time consistent with the above policy.

The template for registration requests is:

    o  Data item
    o  Semantics (short form)
    o  (Optional) References to published specifications that describe
        the syntax or semantics of the data item. The references do not
        need to mention CBOR or this tag registration.

    In addition, First Come First Served requests should include:

    o  Point of contact

    o (Optional) Description of semantics (URI) - The
       URI can point to something like an Internet-Draft or a web page.

*END*

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Aug 2019 18:22:45 +0200

>    New entries in the range 24 to 255 are assigned by RFC Required.

Based on previous WG discussions, I think that was a slightly higher hurdle than we wanted here.
Specification required + designated expert considerations that only provide this space for high-value allocations (which needs to be defined better than I just did).

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Wed, 14 Aug 2019 09:52:55 -0700

> Specification required + designated expert considerations that only provide this space for high-value allocations (which needs to be defined better than I just did).

True in that Thiago's referenced post said 32-255 range.

However, not quite true in that Thiago's prior post 
<mid:10096467.9kdZcmANtY@tjmaciei-mobl1> says:

"Could we get 32-255 to be slightly stricter but not to the level of 
standards
action? I was thinking of publication of a draft to this WG and allow 
for a 2-
week comment period. This could both spur ideas from other passive watchers
and ensure high quality of the ones that do get published."

"do get published" = draft turns into an RFC. But it can be independent 
stream. That is congruent with RFC Required.

The other problem is that we are already half exhausted out of the 
32-255 range. It's going to go entirely pretty soon.

I believe that 32-255 should have a higher level of review than 
256-<some fraction less than 65535>. We need to de-stigmatize the 
256-65535 range. It is perfectly acceptable for widely deployed 
protocols--even for IETF Standards-track protocols. But I think right 
now everybody is trying to go for 32-255 and it's just not sustainable.

Oh, also Carsten's post 
<mid:[email-masked]> said "I like that" 
for RFC Required to 255. :-)

In <mid:[email-masked]> Jim proposed 
Specification Required with a consideration: "Reviewers should be 
reluctant to assign code points in the 24-255 range to specifications 
that are not RFC documents."

However, with regard to the present tag 42 problem, Jim proposed that we 
encourage early IANA allocation. The point is that early IANA allocation 
+ RFC Required will alleviate the problem, and will also permit higher 
analysis + early allocation in the 256-65535 range.

So I think there was not consensus on the mailing list at the time but 
the trend was going towards segregating the spaces into progressively 
higher levels of review.

Sean

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Aug 2019 19:02:23 +0200

On Aug 14, 2019, at 18:52, Sean Leonard <[email-masked]> 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).  We still have ~180.  If this were linear, that would work for another 20 years.  It’s not, so we want to slightly put down the foot, and probably even more so when we have less than 100 left.  We certainly don’t want to spend more than about 10 per year, or one a month.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 14 Aug 2019 19:15:13 +0200

On Aug 14, 2019, at 18:52, Sean Leonard <[email-masked]> wrote:
> 
> Oh, also Carsten's post <mid:[email-masked]> said "I like that" for RFC Required to 255. :-)

That hasn’t changed.  I was just trying to relay the sense of the room when we discussed this in f2f WG meetings.

Grüße, Carsten

---

From: Sean Leonard <[email-masked]>
Date: Wed, 14 Aug 2019 10:29:32 -0700

On 8/14/2019 10:02 AM, Carsten Bormann wrote:
> 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