Subject: DNSEXT WG Last Call: EDNS0.5

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 29 Nov 2000 14:29:15 -0500

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 29 Nov 2000 22:02:08 -0500

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Nov 2000 15:34:47 +0100

>they are so similar in form and function.

do we have examples of boolean OPTIONs?

I would hesitate to jam them into the same mechanism if there is a chance 
that we might want to turn them off/on per query - the FEATURE mechanism 
was quite deliberately designed so that it was "relatively harmless" to 
signal a FEATURE you did not have any use for. This is a requirement in 
order to be able to subsume FEATURE lists into VERSIONs.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]