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

Michael StJohns <> Thu, 07 July 2022 22:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B66ACC15AB54 for <>; Thu, 7 Jul 2022 15:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.778
X-Spam-Status: No, score=-3.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qnow0SaFs866 for <>; Thu, 7 Jul 2022 15:21:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id E05AAC14792E for <>; Thu, 7 Jul 2022 15:21:29 -0700 (PDT)
Received: by with SMTP id l14so24900974qtx.2 for <>; Thu, 07 Jul 2022 15:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=T1L3ijnmk2pYRI2X4NeOaWewFbCjxY0qzCEmRicyfV0=; b=pdfTwtDlWhluuft/w1OXI1mvNcwMCHKxfOA9br89hD11yjwZ/yqkOBOPKH4RnJNDfP BW9A3tqKAnTgCtVH7jlBhDBB80R4tvVL4Jnf86TXo5bW59dn4yrRnTybhRn595jUtBeR Mj0qfk4vyOxr2Fz+cTYb1cnEd0mYO+/hipm5KJKrWA7Qlr08iBu1D2KCuIDkgv3WBRTk NHtNI8xIcvutOTJdzOCM9SIJ3LuwqMlPAik8OY+Xu5fXwNOwQJpa8bMZlbd9qaOK6Mvx huExgPCdngsPdP2pRcYkVCtmO138enPtunjRYjhMVjRo46K54H9mUvT6zcppPrI4CsH/ EvYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=T1L3ijnmk2pYRI2X4NeOaWewFbCjxY0qzCEmRicyfV0=; b=SI4G7xn3ob/j1ZJAWcQp512SdqRnsSNJC7Pq75SbLWeOVTHXYs11OoiLLKeaBOnBYc njWijLNNRYvc8IkOCSQMCUoVIvViu+QHxQW6Yhzbzlrpdz9YR7uKzA2SysbjPC+XBeZQ a6lbvjT1aCaIH6xdjZEL2O5nCjDYhh87P6Z6tmNk6cDotivjV8A1xqo+GrH6b5KBO2FF T9UBdMJ19TmHXItCTKZ6lI4ehV9lgvOxNv6TJa81Dwj/MkNqUjXdrT89ePOehEdPxMU0 D56UrrQxX+jQJSTAbr99rJBySaL4sh9aLrXltXBPy80Qzrrihe6IpyrHHKIKIOJ/5450 ahnQ==
X-Gm-Message-State: AJIora+fN2u8JH7Fy3xvlZO78f0gKgs7nollVgplO/aPMweCUcRJz2z9 6tp7stSeDJN/s15eBqMdEmQi4FURlwgrwEfy
X-Google-Smtp-Source: AGRyM1tbUkHLr8u3oZ/iIF5KGodgWGrO3JXliVz8dvc8rayGDzpClCeTWbyhpjzzSW/OzfiPA9xUyA==
X-Received: by 2002:ac8:5cd3:0:b0:316:f772:f0b8 with SMTP id s19-20020ac85cd3000000b00316f772f0b8mr427693qta.162.1657232487785; Thu, 07 Jul 2022 15:21:27 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id d3-20020a05620a240300b006af45243e15sm29503017qkn.114.2022. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Jul 2022 15:21:25 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------h9jhhr11pQvlHuHhsq88CZZH"
Message-ID: <>
Date: Thu, 07 Jul 2022 18:21:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
References: <> <>
From: Michael StJohns <>
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jul 2022 22:21:31 -0000

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.


> 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
>> 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:
>> There is also an HTML version available at:
>> A diff from the previous version is available at:
>> Internet-Drafts are also available by rsync at
>> _______________________________________________
>> DNSOP mailing list
> _______________________________________________
> DNSOP mailing list