Re: DNSEXT WG Last Call: EDNS0.5

[gson@nominum.com (Andreas Gustafsson)]

> 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.

I object to advancing the draft.  I do not think there is a genuine
need for this kind of feature indication mechanism, for a number of
reasons:

First of all, it seems to be the consensus of the DNSEXT working group
that the number of new DNS protocol features should be kept to an
absolute minimum.

Even if new features are introduced, it is not clear that a significant 
number of them will benefit from a mechanism to explicitly "determine
which extension features the other party understands".  Determining
the feature set of a server before using it requires an additional
round-trip, which causes considerable additional delays in a protocol
like the DNS which involves many simple transactions with a large
number of distinct servers.  Therefore, new extensions should be
designed to avoid such feature negotiation if at all possible.

For those cases where an explicit indication of support for a new
features is useful, there are existing mechanisms that can do the job
without introducing additional complexity in the form of mandatory
support for the FEATURE option.  The support for a feature can be
indicated by sending a feature-specific OPT RR, which may have an
empty data field if no information other than the mere presence of the
feature needs to be transmitted; with two or fewer features, this
takes no more space than using the FEATURE option.  Alternatively,
each feature may be allocated a flag from the 16-bit "Z" field of the
OPT RR header.
-- 
Andreas Gustafsson, gson@nominum.com


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