On Thu, Sep 12, 2019 at 09:51:25AM -0400, Tim Wicinski wrote:
> - Viktor's comments from 11 September will be rolled into the WGLC
> comments, which means I'll be tracking them with the authors.
Much appreciated, thanks!
FWIW, on the hot topic of conflict between RCODE and extended RCODE,
Paul Hoffman's latest comment:
Proposal: add the following sentence to the end of the abstract:
"Extended error information does not change the processing of
RCODEs."
Proposal: add to the end of the Introduction: Applications MUST
NOT change the processing of RCODEs in messages based on extended
error codes.
seems to align with my take on the interaction of EDEs as a (to
coin a phrase) diagnostic refinement rather than "replacement" of
the RCODE.
>From a related nomenclature perspective, I wonder whether there
might be any confusion between the existing high 8 bits of RCODE
in the EDNS OPT pseudo-header (MSB octet of the TTL) and the proposed
new "Extended DNS Error Code". Perhaps "Extended RCODE" and "Extended
DNS Error Code" are sufficiently similar terms to warrant a brief
comment to the effect that the proposed EDEs are diagnostic refinements
of the existing "Extended RCODE", which is distinct from EDEs and
remains the definitive status of the response...
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
