Subject: [dnsext] Question about content in EDNS0bis-03

From: Edward Lewis <[email-masked]>
Date: Thu, 1 Apr 2010 12:25:02 -0400

Referring to:
http://tools.ietf.org/html/draft-ietf-dnsext-rfc2671bis-edns0-03

# 6.2.  OPT Record Format
#
...
#   Any OPTION-CODE values not understood by a responder or requestor
#   MUST be ignored.  Specifications of such options might wish to
#   include some kind of signaled acknowledgement.  For example, an
#   option specification might say that if a responder sees option XYZ,
#   it MUST include option XYZ in its response.

What does "MUST be ignored" entail?  Is the option repeated in the 
response "silently" copied into the reply or is it omitted from the 
response?  This question has arisen from an internal discussion.

The second sentence is what is making interpretation difficult.  If 
ignoring means to drop the option from the response, then the mere 
presence of the option in the response would be "some kind of 
signaled acknowledgement."  But then there's the mention of "might 
wish to include" one, which implies that there would always be the 
option in the response.

In the third sentence, what does "sees" mean - does it mean 
"understands"?  The dilemma here is if the implementation is to 
adhere to the example rule, the implementation had to be aware of the 
option's definition, therefore be cognizant of the option (despite 
perhaps not implementing it).

Is it thought that unrecognized (by the responder) EDNS0 options are 
not parsed, not read, and omitted in responses it emits?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

New pithy statement under construction...

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 1 Apr 2010 20:36:29 +0200 (MESZ)

Edward, you wrote:

> ...
>
> Is it thought that unrecognized (by the responder) EDNS0 options
> are not parsed, not read, and omitted in responses it emits?

That was the idea from the previous draft version.

Then, I had triggered discussion on
"Building structured extensibility into EDNS0(bis)" in
  <http://ops.IETF.ORG/lists/namedroppers/namedroppers.2009/msg02932.html>

Please review my proposal for functional 'M' and 'E' bits nibbled
off the 16-bit EDNS OPTION-CODE, and the ensuing discussion on
the thread on namedroppers started with that message.

To quickly recall: 'E' bit was intended to signal a request for
"blind echoing" of an EDNS option in the response if the responder
does not "support" the option code; E=0 (as for all option codes
assigned so far) would have indicated: ignore (skip over the option if
unknown); 'M' was intended to signal: respond with error if such
option is seen at a responder that does not "support" it.

The outcome was that structured extensibility was not liked by
posters, mostly due to fears on possible problems with the
established code base -- although feedback from implementers
seemed to confirm that. e.g. EDNS versioning should be correctly
implemented since years.

IIRC, the discussion was not brought to a point where it would have
been possible to declare broad consensus pro/con, and the draft
authors therefore apparently simply have added a bit more text to
the previous text without adding functionality or new requirements.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+