Hi Murray, I don’t believe your comments have been addressed yet. My apologies for the delay.
> On Jun 19, 2024, at 10:13 PM, Murray Kucherawy via Datatracker > <nore...@ietf.org> wrote: > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to John Levine for his ARTART review. > > I support John's, Paul's, and Eric's DISCUSS positions. > > Why the SHOULD NOT in Section 3.1? If a client decides to include that option > when talking to a non-authoritative server, what can happen? Or put another > way, why leave the client an out here? Is there a legitimate reason to allow > this? It’s a good question. I can only think of a couple of reasons to support SHOULD NOT. I would be happy with MUST NOT if there is preference for that. One reason is that I expect the most common use of this option will be for debugging with DNS clients such ‘dig’. The way that dig is commonly used, it doesn’t know if a name server is authoritative or not — the user makes that choice and dig just does what it's told. Another reason is that a recursive server might be configured to serve some zones authoritatively. But this could be addressed with new language such as “MUST NOT send the option to name servers that are not authoritative for the QNAME”. > > I have a similar question about each of the SHOULDs in Section 3.2. Why are > we > offering a choice here? Why might I decide to deviate in each case? > I think these short paragraphs in 3.2 that you refer to were intended as a reminder to the reader / implementor to not forget about the (perhaps) less common types of responses, and to still include the zone version in them. I will take a stab at wording these reminders differently to avoid requirements keywords. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
