Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

[Michael StJohns <[e-mail]>]

Hi Bob -

As I noted below, I was only using this particular text as an exemplar 
of the proper handling of SHOULD and on first glance found a section 
where I was pretty sure that .  I was kind of surprised at the phrase 
"syntactically correct DNS zones" because I'm pretty sure its a 
meaningless phrase.  A "zone master file" had syntax to be checked - 
today's database driven zones mostly don't.  But I went with that wording.

And I have no idea if the rephrasing makes sense in terms of the whole 
document - but I believe that the MUST and SHOULD usages in that 
paragraph are poorly constructed.

Later, Mike



On 7/8/2022 8:49 AM, Bob Harold wrote:
>
> On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns 
> <[e-mail]> wrote:
>
>     On 7/7/2022 5:32 AM, Willem Toorop wrote:
>>     Dear dnsop,
>>
>>     This draft describes a mechanism for automatic provisioning of zones
>>     among authoritative name servers by way of distributing a catalog of
>>     those zones encoded in a regular DNS zone.
>>
>>     The version's focus was finalizing for Working Group Last Call.
>>     We made sure that all MUSTs in the document have a companion description
>>     that tells what to do if that MUST condition is not met. Also the
>>     `group` property restrictions have been loosened to accommodate multiple
>>     sets of catalog consumers offering different sets of group properties.
>
>     Not to be a pedant and having not read the document, don't you
>     mean "SHOULD" above rather than "MUST"? MUST's are absolute
>     requirements that should have no wiggle room. SHOULD's are the
>     requirements where you probably need to explain what to do if the
>     condition isn't met.
>
>     One brief example taken from your document (section 4.1):
>
>>     Catalog consumers SHOULD ignore NS record at
>>         apex.  However, at least one is still required so that catalog zones
>>         are syntactically correct DNS zones.  A single NS RR with a NSDNAME
>>         field containing the absolute name "invalid." is RECOMMENDED
>>         [RFC2606][RFC6761].
>
>     Instead: "Catalog consumer MUST ignore the NS record at the apex
>     of the catalog zone.  Catalog zones SHOULD include a single NS RR
>     with a NSDNAME containing the absolute name 'invalid.', but
>     consumers MUST NOT error out if this is not present.  Non-catalog
>     clients will take an error as expected when retrieving the zone.
>     Non-catalog-aware servers may fail to load or serve the catalog
>     zone if this NS RR is absent."  (The "will" and "may" in the last
>     two sentences are lower case as they are explanatory and not
>     requirements.  The last sentence explains the probable result of
>     omitting the NS RR.)
>
>     My $.02.
>
>     Mike
>
>
> I thought the catalog zone was required to be a valid zone.  We 
> certainly should not be requiring changes to the code that verifies a 
> valid zone.  Is an NS record part of the validation in some DNS code 
> bases?  If so, it should be mandatory.  Do the RFC's require an NS record?
>
> -- 
> Bob Harold
>
>
>>     The authors consider this version to be complete to the best of our
>>     ability and we'd like to ask the working group to proceed with this
>>     document for Working Group Last Call.
>>
>>
>>     Op 07-07-2022 om 11:03 [e-mail]:
>>>     A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>     This draft is a work item of the Domain Name System Operations WG of the IETF.
>>>
>>>              Title           : DNS Catalog Zones
>>>              Authors         : Peter van Dijk
>>>                                Libor Peltan
>>>                                Ondrej Sury
>>>                                Willem Toorop
>>>                                Kees Monshouwer
>>>                                Peter Thomassen
>>>                                Aram Sargsyan
>>>        Filename        : draft-ietf-dnsop-dns-catalog-zones-06.txt
>>>        Pages           : 20
>>>        Date            : 2022-07-07
>>>
>>>     Abstract:
>>>         This document describes a method for automatic DNS zone provisioning
>>>         among DNS primary and secondary nameservers by storing and
>>>         transferring the catalog of zones to be provisioned as one or more
>>>         regular DNS zones.
>>>
>>>
>>>     The IETF datatracker status page for this draft is:
>>>     https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/
>>>
>>>     There is also an HTML version available at:
>>>     https://www.ietf.org/archive/id/draft-ietf-dnsop-dns-catalog-zones-06.html
>>>
>>>     A diff from the previous version is available at:
>>>     https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-catalog-zones-06
>>>
>>>
>>>     Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>>