Subject: Re: [core] Range issue in core-parameters registry

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Oct 2015 13:49:03 -0400

Folks, it's been a long time since this discussion stalled.  IANA
needs a resolution.  Does anything need to be changed here?  If so,
what.  Please put this on the front burner and resolve it ASAP.

Thanks,
Barry, being a pushy AD...

On Mon, Jul 27, 2015 at 10:55 PM, Carsten Bormann <[email-masked]> wrote:
> Zach Shelby wrote:
>> Carsten,
>>
>> Yes, the 0..255 range should be used sparingly, preferably for widely used RFCs and CoRE specifications. No problem here.
>>
>> The problem is what to do with other requests? Since we have not done a great unification of media types, we are now getting requests for those on a one-by-one basis as they come into use on CoAP. The natural place to assign these would be 256-9999, the jump from 255 to 10000 is pretty extreme. I would prefer to use the experimental range for things that really are experimental, and assign requests based on solid specifications to 256-9999.
>
> There is no difference in quality between an assigned value of 256 and
> an assigned value of 10123 -- both need two bytes in the packet.
>
>>
>> Maybe time to give up on the great unification experiment? We need to do it very soon, or end up with a bunch of duplicates.
>
> To me it seems we should accelerate the unification.
> The most expedient approach would be to simply assign the values from
>
>         https://svn.tools.ietf.org/svn/wg/core/mediatypes.txt
>
> for each combination of an existing media type and the identity content
> coding that is being requested.  (Note how this file grows over time by
> (pseudo-)randomly assigning numbers to new media types, while keeping
> the assignments of old media types stable.)  We probably need to write
> up how this happens in order to satisfy the "reserved for future use in
> IETF specifications (IETF Review or IESG Approval)" requirement of RFC
> 7252.  For a while, we can continue generating these numbers in the WG,
> but ultimately it should be IANA that is generating the numbers
> alongside a media type registration.
>
> Grüße, Carsten
>
>>
>> Zach
>>
>> On Jul 23, 2015, at 3:29 PM, Carsten Bormann <[email-masked]> wrote:
>>
>>> The range 256-9999 has been put away for the great unification of media
>>> type and content format registries, something we haven't quite gotten to
>>> (it will involve some discussion of updating existing registries etc.).
>>>
>>> TL;DR: Everything is as it should be.
>>>
>>> That said, the instructions for the expert about 0..255 are not very
>>> specific.  The idea is of course not to use up that space in a jiffy, so
>>> some pushback is expected from the expert; the preference for allocating
>>> these golden 1-byte numbers should go to IETF review specifications.
>>>
>>> Grüße, Carsten
>>>
>>>
>>> Michelle Cotton wrote:
>>>> Hello!
>>>>
>>>> After consultations with Barry Leiba and the expert for the
>>>> core-parameters registry (Zach Shelby) we believe that the range
>>>> descriptions in the following registry may be backwards:
>>>>
>>>> http://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats
>>>>
>>>> The registration procedures as defined in RFC 7252 are as follows:
>>>>
>>>> 0-255            Expert Review
>>>> 256-9999      IETF Review or IESG Approval
>>>>
>>>> It has been suggested that possibly an errata is needed to reverse the
>>>> ranges so the Expert Review range is much larger.
>>>> Any issues with this plan?  Thoughts?  Comments?
>>>>
>>>> I have copied the designated expert for this registry as well.
>>>>
>>>> Thank you,
>>>>
>>>> Michelle Cotton
>>>> Protocol Parameters Engagement Manager
>>>> IANA Department
>>>> ICANN
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/core
>>> _______________________________________________
>>> core mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/core
>>
>> Zach Shelby
>> Vice President, Marketing
>> ARM Internet of Things BU
>> www.arm.com
>> US: +1 (408) 203-9434
>> Finland: +358 407796297
>> Skype: zdshelby
>> LinkedIn: fi.linkedin.com/in/zachshelby/
>>
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
>>
>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
>> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782
>>
>>
>>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 9 Oct 2015 16:35:52 +0200

Well, my resolution would be:

— continue to operate as defined in RFC 7252 (i.e., allocate 10000..64999 in FCFS);
— start work on writing up the experiment for using 1000 to 9999 for existing, parameterless media types;
— where we actually have IETF review but don’t want to use up the “good” numbers 0..255, we can use 256..999.

Apart from that,

— continue to use the experimental range 65000-65535 for actual experiments, such as the T2TRG plugREST.

Grüße, Carsten

On 6 October 2015 at 19:49:12, Barry Leiba ([email-masked]) wrote:

Thanks,