On Mon, Sep 30, 2019 at 8:55 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On 9/30/19 7:09 PM, Wes Hardaker wrote: > > Paul Hoffman <paul.hoff...@icann.org> writes: > > > >> 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. > > > > Did you read the new replacement sentence? > > > > Applications MUST continue to follow requirements from applicable > > specs on how to process RCODEs no matter what EDE values is also > > received. > > > > Is that sufficient? > > Yes, thank you. > > --Paul Hoffman > Just a note. The original draft had a 'retry' code that was intended to change how the client reacted. That has been removed, but there are still some that would like to 'act on' the EDE. One reason given for not doing that is that is can be spoofed or changed by attackers, so it cannot be trusted. I was hoping that this could improve some cases where the client is not acting in an optimal way, but I can understand why that would be discouraged. Should we warn implementers of the issues, but still not forbid acting on them? -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
