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

[Joe Hildebrand <[e-mail]>]

I may or may not be at the meeting tomorrow since I'm sick.  Since I'm sick, please excuse my lack of tact with this message.

Does anyone else think that this is a LOT of tags to allocate for one thing?  Was there no other design that could achieve the goals?

— 
Joe Hildebrand

> On Dec 10, 2024, at 1:19 PM, Carsten Bormann <[e-mail]> wrote:
> 
> 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
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]