[DNSOP] Re: Murray Kucherawy's No Objection on draft-ietf-dnsop-zoneversion-08: (with COMMENT)

["Wessels, Duane" <[e-mail]>]

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 <[e-mail]> 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