Re: DNSEXT WG Last Call: EDNS0.5

[Kevin Darcy <kcd@daimlerchrysler.com>]

Harald Alvestrand wrote:

> At 22:02 29/11/2000 -0500, Kevin Darcy wrote:
> >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.
>
> do we have examples of boolean OPTIONs?

None that are drafted/RFC'ed, that I'm aware of. I have some ideas about a "don't
send me extraneous RR's" option (as I brought up several months ago -- see "To Be
Cached, ..."), but nothing concrete yet. It seems likely, though, that boolean
OPTIONs will be proposed in the future. If the codes for OPTIONs and FEATUREs need
to be co-ordinated, this is the time to do it. Otherwise, it may be difficult to
retrofit once we have collisions all over the place.

Note that sometimes there may be an affinity between a FEATURE and a boolean
OPTION. The FEATURE may establish a default -- "do X" or "don't do X" -- and the
corresponding boolean OPTION may establish a mutually-agreeable, per-transaction
override of that default behavior -- "let's do X just this once" or "let's not do
X right now". As FEATUREs get proposed, then, we may start to see boolean OPTIONs
proposed in parallel. I'm not saying this is inevitable, only likely.

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

I don't think mixing boolean OPTIONs with FEATUREs would get in the way of
subsuming FEATURE lists into VERSIONs, especially if the OPTION codes and
FEATURE codes are assigned from distinct numeric ranges. Since the list is sorted
numerically, any reasonable algorithm can easily detect the demarcation between
the two types of extension, i.e. can easily tell that it is done parsing FEATUREs
or OPTIONs, depending on which direction it chooses to work through the list. The
FEATURE processing is thus easily segregable from the boolean OPTION processing.
The only thing it would hinder is if an implementation might want to do, say, a
non-linear (e.g. log) search for a specific FEATURE in a large, unparsed list. How
likely is that? My impression is that FEATURE lists would always be parsed into
internal data structures which would be consulted for any FEATURE-specific
decisions -- repeatedly searching the raw FEATURE list seems rather crude and
inefficient.

Admittedly, my suggestion ultimately only saves 4 bytes in the OPT RR (an
alternative would be to spec a "boolean options list" composite OPTION which would
exactly mirror EDNS0.5's FEATURE list, requiring an extra 2 bytes for the
OPTION-CODE and another 2 bytes for the OPTION-LENGTH), and possibly some parsing
resources, depending on implementation. In the grand scheme of things, 4 bytes is
not a whole lot. But every little bit helps, and I'm not sure that there would be
any significant downside (except of course the standards-process downsides of
having to a) reword the draft, and, potentially, b) to deal with IANA on the issue
of segmenting the range; I could perhaps assist with the rewording, but I'm
unfamiliar with IANA processes and procedures).


- Kevin




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