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 <m...@nthpermutation.com> 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 schreefinternet-dra...@ietf.org:
    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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to