EDNS standard clarification

[Michael Sawyer <Michael.Sawyer@nominum.com>]

Brian Wellington and myself are working on a personal draft which proposes
two new EDNS option codes, and have encountered an issue with RFC2671
which we believe needs addressing.

RFC2671 appears to be totally silent on the issue of how an EDNS-aware
server should handle the situation where it gets a query with an EDNS OPT
record containing one or more option codes which it doesn't know how to
handle.  Section 5.3 of 2671 doesn't appear to apply in this case, since I
read that as talking about servers which don't speak EDNS at all, not ones
which speak EDNS but not all of the options which it is sent.

My first impression of what should be done (which is what Bind9 does, and
appears to be what most people I've spoken to feel is correct) is to
ignore the unrecognized option records.  As the standard is written now,
it is unclear whether servers should behave this way, reply with FORMERR,
NOTIMPL, or take some other course of action.

Is it the opinion of the rest of the working group that the correct
behavior is to ignore the unknown options, leaving it up to the authors of
the option standards to define what behavior is required if the server
needs to indicate that it did understand and accept the passed option?

						Mike





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