Re: [Cbor] CBOR tag range IANA allocation policy

Okay so it sounds like there are more than crickets on the topic, so we can discuss it…

My intuition is as follows:

0-23 = standards action = no change
24-255 = RFC Required
256-65535 OR 256-32767 = specification required
65536+ OR 32767+ = FCFS = no change

This was my intuition based on tags being proposed, and the relative value of smaller tag numbers. However, I would want to make it more rigorous than just a feeling.

RFC 8126 “Guidelines for Writing an IANA Considerations Section in RFCs” defines the levels of review. RFC Required is one notch higher than Specification Required. Hence it is the smallest incremental bump. It would provide no difference in outcome to *most* stuff in 32-255 at present, but I checked and there are about 10 allocations in 24-255 (including about 5 in the low range, 24-29) that would have been excluded because the specs are not RFCs. The space 32-255 is already nearly half exhausted.

Specification required should be in place for the 1+2 byte range, since, well, we want public specs. In my mind, it is hard to justify restricting anything in the 1+4 byte space (32 bits) since they have equal performance characteristics.

There has been a good amount of discussion about constrained CBOR platforms that do not natively do 64-bit integers. However, is it fair to say that even the most resource-constrained devices these days are 32-bit capable without a lot of hassle?

Splitting the baby in half at the 16th bit allows half of the space to have more review, while the upper half can still be FCFS and get the same performance. “32,768 numbers is enough for everybody!” — or is it?

I wonder if we should bump 256-4095 or so to a higher level of review than specification required. It still leaves 28,000 values that have the same performance characteristics.

Sean

> On Jul 25, 2019, at 5:25 PM, Ira McDonald <blueroofmusic@gmail.com> wrote:
> 
> Hi,
> 
> (possibly putting foot in mouth)
> 
> I think it's a bad practice to lower a previous IANA requirement for any number
> range in a registry (especially from specification required to one instance of
> Internet-Draft and two weeks of silent approval).
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>
> PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> On Thu, Jul 25, 2019 at 5:19 PM Thiago Macieira <thiago.macieira@intel.com <mailto:thiago.macieira@intel.com>> wrote:
> On Thursday, 25 July 2019 13:38:41 PDT Sean Leonard wrote:
> > Hi WG, what is the current stance on changing the IANA Considerations for
> > tag registration?
> > 
> > I find the RFC 7049 tag registration scheme (0-31 = standards action, 32-255
> > = specification required, 256+ = FCFS) to be acceptable.
> > 
> > However, I think that maybe we want to encourage more tag registration,
> > while also having a bigger space for more review and publication. I read
> > the minutes and am not sure if there is a current stance or a group sense
> > on the matter, at least within the past 12 months.
> 
> 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.
> 
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com/>
>   Software Architect - Intel System Software Products
> 
> 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org <mailto:CBOR@ietf.org>
> https://www.ietf.org/mailman/listinfo/cbor <https://www.ietf.org/mailman/listinfo/cbor>
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor