[DNSOP] Code Point Assignment Suggestion - was Re: [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Without going into the original discussion (whether or not to reserve some
sub-range of code points for some purpose or another), I'd like to suggest
a method to use that conserves values better.
This would apply to any very limited resource (such as code points) within
a linear range.
It would basically only work when there are two consumers of the resource.

The method is:
Assign values from the bottom up, for one consumer of the resource.
Assign values from the top down, for the other consumer of the resource.

This has the benefit of allowing the "set point" for the allocation
boundary to be moved without requiring renumbering.

It also has the benefit of potentially using all of the resource without
any unnecessary waste owing to inefficient allocation strategies.

This is much more of an issue where the range is 8 bits in size (such as
DNSSEC algorithms), which is why I raise it in this context.

This is probably moot at this point, and probably doesn't need any
discussion.
However, if there is a desire to have the ability to distinguish such
allocations (e.g. standard track vs informational track, or similar), this
method could be used for algorithm code points.

Brian

On Sun, Dec 27, 2020 at 10:40 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:

> (Speaking without my chairs hat here)
>
> How about instead of loosening the requirement, we take the top 64 values,
> allocate them as either Experimental or FCFS, and it is explicitly noted
> NOT REQUIRED (or NO ONE WILL IMPLEMENT THESE FOR YOU).
>
> That would leave the registry with the strict requirements and allow items
> to get code points.
>
> Too simple an answer?
>
> tim
>
>
> On Fri, Dec 25, 2020 at 10:53 PM Olafur Gudmundsson <ogud@ogud.com> wrote:
>
>>
>>
>> On Dec 25, 2020, at 3:27 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
>>
>> On Dec 24, 2020, at 10:28 AM, Daniel Migault <mglt.ietf@gmail.com> wrote:
>>
>>
>> Hi,
>>
>> As the DNS is a global shared resource and its reliability is based on
>> **all** pieces of software adhering a common standard, I am inclined to
>> believe that new cryptographic algorithms introduced with anything less
>> restrictive than "IETF Review" - such as "Specification Required" and "RFC
>> Required" - does not sufficiently prevent altering the interoperability of
>> the DNS.
>>
>>
>> Why do you feel that DNSSEC has requirements stronger than other IETF
>> security prot0cols such as TLS, IPsec, S/MIME, and so on?
>>
>>
>> DNS is a fire-and-forget protocol, all the ones you mention include a
>> handshake that can be used to agree on algorithms. Such facility does not
>> exist in DNS.
>>
>> I oppose any relaxation of thresholds to add algorithms to DNSSEC, as
>> there is no need.
>>
>>   Ólafur
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>