[Cbor] Early allocation for packed CBOR (Re: Reminder: CBOR WG Virtual Meeting on 2024-12-11)

[Carsten Bormann <[e-mail]>]

The meeting tomorrow will have an agenda item on IANA "Early allocation" for packed CBOR:

> * packed: do early allocation now?
>    * Check conditions: [RFC 7120: Early IANA Allocation of Standards Track Code Points Section 2](https://www.rfc-editor.org/rfc/rfc7120#section-2)
>    * Generate request: [RFC 7120: Early IANA Allocation of Standards Track Code Points Section 3.1](https://www.rfc-editor.org/rfc/rfc7120#section-3.1)
> 
> Of course, we can prepare this already here on the mailing list, but we can get a head start on 3.1 item 3 in the meeting.
> 
> Here are the IANA considerations:
> 
> [Packed CBOR](https://www.ietf.org/archive/id/draft-ietf-cbor-packed-13.html#name-iana-considerations)

While there is a draft-iana-7120bis under discussion that can inform us of where things are going, RFC 7120 is the current process.

So let’s go through the items under "2.  Conditions for Early Allocation”

   a.  The code points must come from a space designated as "RFC
       Required," "IETF Review," or "Standards Action."  Additionally,
       requests for early assignment of code points from a
       "Specification Required" registry are allowed if the
       specification will be published as an RFC and if IANA can obtain
       expert approval.

draft-ietf-cbor-packed makes a quite sizable number of allocations.

Of these, the following are in Standards Action ranges as per [1] and [2] and therefore require using the RFC 7120 process if we want to stabilize the numbers now:

Simple values: 0-15
[1]: https://www.rfc-editor.org/rfc/rfc8949.html#name-cbor-simple-values-registry

Tag: 6
[2]: https://www.rfc-editor.org/rfc/rfc8949.html#name-cbor-tags-registry

(Giving the suggested allocation numbers as a terse reference.)

The following tags are in Specification Required ranges:

                    105
                    106
                    113
                    114
               216..223
               224..255
                   1112
                   1113
           27647..28671
           28704..32767

And, finally, these tags are in FCFS but should probably run in sync with the above:

 1811940352..1879048191
 1879052288..2147483647

   b.  The format, semantics, processing, and other rules related to
       handling the protocol entities defined by the code points
       (henceforth called "specifications") must be adequately described
       in an IETF Stream Internet-Draft.

I believe that this is true for draft-ietf-cbor-packed-13; we should discuss this tomorrow.

   c.  The specifications of these code points must be stable; i.e., if
       there is a change, implementations based on the earlier and later
       specifications must be seamlessly interoperable.

I believe we have reached a level of stability that we can ensure that; again, discuss this tomorrow.

   d.  The Working Group chairs and Area Directors (ADs) must determine
       that there is sufficient interest in the community for early
       (pre-RFC) implementation and deployment, or that failure to make
       an early allocation might lead to contention for the code point
       in the field.

This is probably a good subject for discussion tomorrow.

We have a few implementations; I would think that deployment simply waits for the allocations now.

As a DE, I already had to ask an (unrelated) registrant to suggest different numbers because their suggestions conflicted with the above, so I have at least one data point about contention.


Once we have convinced ourselves about the prerequisites, next is the actual process:

3.1.  Request

   The process for requesting and obtaining early allocation of code
   points is as follows:

   1.  The authors (editors) of the document submit a request for early
       allocation to the Working Group chairs, specifying which code
       points require early allocation and to which document they should
       be assigned.

The authors can do that after tomorrow’s discussion.

   2.  The WG chairs determine whether the conditions for early
       allocations described in Section 2 are met, particularly
       conditions (c) and (d).

… as can the WG chairs.

   3.  The WG chairs gauge whether there is consensus within the WG that
       early allocation is appropriate for the given document.

I would expect that the WG chairs will do a short consensus call here; while the document has passed WGLC, the desire to do early allocation has not passed any consensus call.  (The WG chairs have wide license to decide about the form of “gauging” they employ, but a consensus call seems simple.)

   4.  If steps 2) and 3) are satisfied, the WG chairs request approval
       from the Area Director(s).  The Area Director(s) may apply
       judgement to the request, especially if there is a risk of
       registry depletion.

The WG chairs can do that if the consensus gauging ends affirmative.
(Of course, we can inform the responsible AD now already.)

   5.  If the Area Directors approve step 4), the WG chairs request IANA
       to make an early allocation.

More work for the chairs, sorry.

   6.  IANA makes an allocation from the appropriate registry, marking
       it as "Temporary", valid for a period of one year from the date
       of allocation.  The date of first allocation and the date of
       expiry are also recorded in the registry and made visible to the
       public.

IANA will do this.  This also sets up a convenient upper boundary for the amount of time we should need for getting cbor-packed shipped.


We still have 18+ hours to discuss the above here on the list before the interim meeting.
See/hear you all tomorrow!

Grüße, Carsten