Re: DNSEXT WG Last Call: EDNS0.5

[Kevin Darcy <kcd@daimlerchrysler.com>]

If I may make a suggestion:

The EDNS0.5 draft appears to me to logically encompass 2 inter-related
proposals:

1) A "Feature Code" Proposal: a proposal to implement FEATURE codes, which are
similar in function and context to OPTION codes, but, unlike OPTION codes,
which may be purely discretionary between particular clients or servers, or
only for certain transactions, are "standards track", boolean elements of
protocol behavior, expected to eventually -- assuming they prove themselves
worthy -- be absorbed into protocol VERSIONs.

2) An "Aggregator" Proposal: a proposal to implement an OPTION which
aggregates 2 or more 2-octet values, representing boolean "switches" of some
sort, in a sorted list in its data area. This is primarily a
space-conservation measure (since a standalone data-less OPTION occupies 4
octets), although as a secondary benefit, this aggregator might make
composition and parsing of multiple booleans slightly more efficient.

Obviously, these proposals have considerable synergy, given that FEATUREs, if
implemented widely, could consume significant amounts of packet space if --
_sans_ some sort of aggregation mechanism -- they had to be presented as
separate data-less OPTIONs.

But, I think the two parts can be viewed and evaluated independently. The
Aggregator Proposal, as I have previously opined, could potentially be used
for boolean OPTION codes as well as just FEATURE codes, or mixtures of the two
(providing that collisions were avoided somehow). Therefore, I think it has
positive value -- as a pure space-conservation measure -- regardless of
whether the Feature Code Proposal has positive value or not. Coincidentally, I
think the Feature Code Proposal has positive value as well, because I strongly
believe that DNS needs to evolve and grow in order to keep pace with the
accelerating pace of other Internet protocols. But the acceptance or rejection
of one part of the draft doesn't necessarily imply acceptance or rejection of
the other part. Perhaps the draft should be split?

In response to Andreas' specific point about an aggregator with a single
FEATURE code wasting more space than a data-less OPTION expressing the same
boolean concept, I think this is yet another reason why the ranges for OPTION
codes and FEATURE codes should be co-ordinated with each other -- given
collision-protection, a solo FEATURE code could, if desired, be presented as a
standalone data-less OPTION element, to conserve space.

Speaking of space-conservation, I also think that a client or server which
implements no FEATURE codes beyond the ones implicit in the VERSION it
advertises, should not be obligated to provide an *empty* FEATURE aggregator.
The draft as currently written uses mandatory -- or at least non-discretionary
-- language and seems to imply that FEATURE aggregators are *always* supplied
by clients and servers. But where it conveys no useful information, I think
the aggregator should be omitted in the interests of conserving space. Maybe
the mandatory/non-discretionary language could be changed/clarified.


- Kevin

Harald Alvestrand wrote:

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





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