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

[Bob Harold <[e-mail]>]

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 schreef [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
>
>
>