Re: DNSEXT WG Last Call: EDNS0.5

[Harald Alvestrand <Harald@Alvestrand.no>]

At 16:05 12/12/2000 -0800, Andreas Gustafsson wrote:
> > 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:

I (obviously) disagree.

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

No argument from me here.

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

My reply: We introduced this mechanism when we introduced EDNS.
The problem with EDNS was that its mechanism is very coarse grained, so 
that we cannot do (for instance) negotiated tests with the next Binary 
Label-type extension without going through the heavyweight procedure of 
assigning a new EDNS number.
The draft is not about introducing feature negotiation - we already did 
that. The draft is about refining the mechanism so that we can get testing 
and pre-new-version deployment done without it hurting too much.

BTW, the draft does not require an extra round trip for the case where the 
option is supported, any more than EDNS0 does.

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

This point is worth thinking about.
I think that having one mechanism that everyone knows about is better than 
defining one mechanism per extension, and that the administrative procedure 
of collapsing a set of features into a version number gives us a chance to 
get our packet space back once the experimentation phase is over.
But OTOH, the FEATURE mechanism is not useful for signalling per-call 
request differences; extensions might need their own OPTions too, in which 
case we do waste space.

Other thoughts?

--
Harald Tveit Alvestrand, alvestrand@cisco.com
+47 41 44 29 94
Personal email: Harald@Alvestrand.no



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