Re: [dnsext] a lightweight process for assigning EDNS option codes

[Phillip Hallam-Baker <[e-mail]>]

If EDNS0 codes were ever exhausted it is a trivial matter to generate more.
Just assign a new extension RR code.

I suspect that it won't be a problem though, I can't see how we could run
out of EDNS codes before RR codes.


2011/8/31 Jim Reid <[e-mail]>

> On 31 Aug 2011, at 04:23, Colm MacCárthaigh wrote:
>
>  How would you feel about proposing more relaxed registry criteria to
>> IANA (by way of an RFC), similar to how the ports registry works?
>>
>
> Sounds like a good idea.
>
>  EDNS0 option codes don't appear to be in much demand, so exhaustion
>> isn't as much of a concern.
>>
>
> A process comparable to the one for RRtype code assignment could take care
> of this. The expert review would provide a sanity check and rate limiter in
> case we started burning through EDNS option codes. What if marketroids were
> to decide these are more valuable for vanity purposes than new gTLDs?
>
> It's a pity RFC6195 didn't ring-fence some of the EDNS OPT code (and
> Extended RCODE?) number space for private use and/or experiments just like
> it did for the RRtype, CLASS and RCODE spaces.
>
> ______________________________**_________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/dnsext<https://www.ietf.org/mailman/listinfo/dnsext>
>



-- 
Website: http://hallambaker.com/