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

Willem Toorop <> Sun, 10 July 2022 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06B7BC159487 for <>; Sun, 10 Jul 2022 01:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.982
X-Spam-Status: No, score=-3.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 1tsyivPAY8K6 for <>; Sun, 10 Jul 2022 01:56:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::629]) (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 B1E79C157B3E for <>; Sun, 10 Jul 2022 01:56:34 -0700 (PDT)
Received: by with SMTP id j22so4256754ejs.2 for <>; Sun, 10 Jul 2022 01:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=message-id:date:mime-version:user-agent:from:to:references :content-language:subject:in-reply-to:content-transfer-encoding; bh=361KCbMpE2ORKpxg9UUeejZ47YXsbva1aQDoFzgAYsg=; b=UHqD0jkOc0DbWJUd6fcqfQtI4InLl4p6wx90EqMiDdO6nzbPGuC0CXEYtLQRtNtyag U9V7s+24rIm8hk/TbPJpiW0eL+lBBwQZHK1u002e5UCN0/d92sQRxlC0hbcxQPe0xsCO YFaNzMy4UkICIJU54mvGkghAwEhSjWd3uTdwkprRlm2lfFZEhEj5E9G8wCXcEWr0fTST mAZk4OnB+wrypqwEPCc5fUBjJGWmSL0AyVNnvucsm73ZkUrzf2Afh4SzrlnFeg+ixKqb igKCsmRdubl8Gig1p1rm3adeUOafkdYPNLUeh4If4WZE8pr+ULOGGC74mXjO0babKhUt l1Ow==
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:from:to :references:content-language:subject:in-reply-to :content-transfer-encoding; bh=361KCbMpE2ORKpxg9UUeejZ47YXsbva1aQDoFzgAYsg=; b=klSZ3jABzbilA4LieDr6hJglh9PcInfbJA8ZatZ4QwFxFgjqHM+7yqN29n4HZOQziE PmRuneGeMzT582owKf2SLvzHxsRR2k3Kxhq07c2fb9EI0BtYzmI11adEvUTmrzsVmHv/ HyLSeeeQaEdQSpdMY6RR+AjFMFG8o8wuF1U4/cKGtzVfLsPuO0KnqWtJd6NB+D4gjZXD gB4Nok2GQ6EYFCwK+yUcVh9x4U7QBGKdq3rvw7WgYlBlXSTdEQ/qg/HZY2b9aPPEkZ+O dwWZvY4MXSzxf+i+35U1OM2OayhrWKD56SoQS53ca0l3Qvp5A/6tNaogIxEglCXzo9RV 5fKw==
X-Gm-Message-State: AJIora8f321WHY5O2RK0LEXSrgj6khM3jdIjRLivbZO4QOAzXH8LOovT lkJU5LipQ5PyP8rsGh2n1AtRZ8KsNweCPw==
X-Google-Smtp-Source: AGRyM1uXtV1finU+VWP50SDbEoqZJWnFzp2R9i3zwBygst1X9eFCrhhjHWURRPu6vzXLhozfavaOmw==
X-Received: by 2002:a17:907:ea8:b0:72b:4b29:64b with SMTP id ho40-20020a1709070ea800b0072b4b29064bmr1501989ejc.616.1657443392186; Sun, 10 Jul 2022 01:56:32 -0700 (PDT)
Received: from ?IPV6:2a10:3781:2851:0:911c:2d09:f563:bf2b? ([2a10:3781:2851:0:911c:2d09:f563:bf2b]) by with ESMTPSA id i21-20020a17090671d500b006feb875503fsm1397207ejk.78.2022. for <> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Jul 2022 01:56:31 -0700 (PDT)
Message-ID: <>
Date: Sun, 10 Jul 2022 10:56:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
From: Willem Toorop <>
References: <> <> <>
Content-Language: en-US
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
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: Sun, 10 Jul 2022 08:56:40 -0000

Op 08-07-2022 om 00:21 schreef Michael StJohns:
> 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.

Michael I agree! I do see that we've been too sloppy in some cases in
the sense that we allow the consumer to have a choice to be strict or
lenient with SHOULDs. These SHOULDs should indeed be replaced with MUSTs
telling whether the consumer MUST be strict (and disregard the whole
catalog zone) or MUST be lenient and tolerate certain conditions to
support future extensions to the protocol. If those cases we may replace
the MUST on the producing side with a SHOULD too then yes for coherency.

I will try to go over the document once more to "correct" those cases.

Thanks for pointing this out!

> 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
>> 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
>>> 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
> _______________________________________________
> DNSOP mailing list