Paul Hoffman <paul.hoff...@icann.org> writes:
> On Sep 9, 2019, at 9:05 PM, Wes Hardaker <wjh...@hardakers.net> wrote:
> >
> > Paul Hoffman <paul.hoff...@icann.org> writes:
> >
> > Hi Paul,
> >
> > Thanks for the comments and good suggestions. Responses below inside my
> > todo list of action:
> >
> > 12 Paul Hoffman
> > ===============
> >
> > Greetings again. The changes here generally help the document, but
> > they also highlight some of the deficiencies. A few comments on the
> > current draft:
> >
> >
> > 12.1 NOCHANGE what error codes?
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > - The spec does not say anything about the kinds of responses where it
> > is allowed to send particular extended error codes. For example, if a
> > response has an RCODE of NOERROR, what does it mean for it to also
> > have a EDE? Or if the RCODE is FORMERR, can it have an EDE that
> > relates to DNSSEC validation failure? The exact semantics for the
> > receiver need to be specified.
> >
> > + The EDE was specifically meant to be an "addition" to an existing
> > reply of *any* RCODE, including NOERROR codes. There is no
> > restriction about when you might include one. Similarly, it makes
> > no sense for some codes to be returned for some RCODES, but any good
> > receiver shouldn't segfault either. I don't think we can specify
> > all potential combinations in any meaningful way.
>
> Being silent on this is also bad. Proposed text for the introduction:
>
> This document does not allow or prohibit any particular extended error
> codes and information be matched with any particular RCODEs. Some
> combinations of extended error codes and RCODEs may seem nonsensical
> (such as resolver-specific extended error codes in responses from
> authoritative servers), so systems interpreting the extended error
> codes MUST NOT assume that a combination will make sense.
I think that works. I extended it with one more sentence:
<t>This document does not allow or prohibit any particular
extended error codes and information be matched with any
particular RCODEs. Some combinations of extended error codes and
RCODEs may seem nonsensical (such as resolver-specific extended
error codes in responses from authoritative servers), so systems
interpreting the extended error codes MUST NOT assume that a
combination will make sense. Receives MUST be able to accept
EDE codes and text in all messages, including even those with a
NOERROR RCODE.</t>
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
