Re: DNSEXT WG Last Call: EDNS0.5

[Kevin Darcy <kcd@daimlerchrysler.com>]

I would prefer to see a more general mechanism in which both FEATURE codes and
OPTION codes, for boolean OPTIONs, are included in the same sorted list: it
seems a waste to have to specify such OPTIONs separately from FEATUREs when
they are so similar in form and function.

This would require the codes to be assigned in such a way as to preclude
collisions between the two types of extension, and if it is deemed necessary to
differentiate *unrecognized* FEATUREs from OPTIONs -- for example, if it is
expected that implementations will log the receipt of an unrecognized code
differently depending on whether it's a FEATURE or an OPTION code -- then the
range could perhaps be segmented, e.g. 0-32767 FEATUREs, 32768-65535 OPTIONs,
or _vice_versa_.

Non-boolean OPTIONs (OPTION-LENGTH > 0) would have no place in this scheme and
would continue to be specified separately.


- Kevin

Olafur Gudmundsson wrote:

> This document proposes a more fine grain feature description mechanism
> than EDNS0 allows. Under this schema new features can be advertised in
> an standard way in regular ENDS0 message.
> There is need to be able to introduce new features and remove old ones
> and this protocol extension proposes a way to accomplish that.
>
> This WG last call ends December 17'th 2000.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt
>
> This draft is on standards track, if you disagree with that please state why
> in your response.
>
>          Olafur
>
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.





to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.