On 9/30/19 1:53 PM, Wes Hardaker wrote:
> Eric Orth <[email protected]> writes:
>
>> I object to the addition of "Receivers MUST NOT change the processing
>> of RCODEs in messages based on extended error codes."
>
> Actually, I agree with you. That text was from suggestion and I put it
> in unaltered. I thought about changing it to a SHOULD NOT.
From RFC 2119:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
Saying "SHOULD NOT" without helping the reading understand the implications is
dangerous and will lead to lack of interoperability. Either this document
specifies the exact places where an EDE can change the processing of the RCODE,
or the current MUST NOT wording is correct.
It is feeling like there is widespread confusion about the purpose of EDEs.
Some folks (apparently including the document authors) want to be be able to
use the presence of an EDE to change the way resolvers act. It would be really
good if there was a list of which EDEs might be used to change specific RFCs so
that the WG can understand this better. In specific, the core DNSSEC RFCs
specify how to handle certain RCODEs in certain circumstances with MUST-level
requirements. Does this document change those requirements?
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
