[DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Mon, 02 January 2023 13:59 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B71C1522A2; Mon, 2 Jan 2023 05:59:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-dns-catalog-zones@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, tjw.ietf@gmail.com, tjw.ietf@gmail.com, davidb@verisign.com
X-Test-IDTracker: no
X-IETF-IDTracker: 9.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <167266797506.64098.15645222023006324245@ietfa.amsl.com>
Date: Mon, 02 Jan 2023 05:59:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bSFjHhw60NauH9TEXd6FncyJzmg>
Subject: [DNSOP] Éric Vyncke's Yes on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Jan 2023 13:59:35 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-dns-catalog-zones-08: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-catalog-zones/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dns-catalog-zones-08
CC @evyncke

Thank you for the work put into this document. I really like the ideas behind
this IETF draft (OTOH, DNS is now used as a control/transport protocol pretty
much BGP nowadays...). But, I second Murray's DISCUSS point about IANA (and his
ask to get an example because the whole document is not really easy to read for
a non expert).

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Tim Wicinski for the shepherd's write-up including the WG
consensus *but* lacking the justification of the intended status :-(

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

### Lack of revised I-D after IETF Last Call

David Black did a Last Call review for the DNS directorate on the 27th of
December 2022:
https://mailarchive.ietf.org/arch/msg/dnsdir/7v58S0wA1G5KfiwTrrEdYAqT73w/

Probably due to some personal time during that week, no replies/text changes
are done yet. Are the authors intending to reply to David ?

### Section 1

Should IXFR / AXFR be cited with a reference ? Even if they are part of the RFC
Editor set of known abbreviations.

### Section 4.1

Isn't the SOA serial already specified as being increased as soon as the zone
content is changed ? If so, why repeating the MUST here ?

### Section 4.2

Even if the TTL value is to be ignored by secondary servers, is there a
recommended value to be used in the catalog zone ?

### Section 4.3.1

Suggest removing "For this memo, ".

### Section 4

Should there be a clear indication about which label to use for each property?
I.e., `the "coo" label is used for the change of ownership property`.

Should there be a IANA registry for all those special labels / property ? Or
would it be an overkill ?

### Section 4.4.1

Just 2 personal comments, no need to reply... But,

* re-using the same node label among zones may be complex, I would have
specified all zone properties are reset after a migration to start from a clean
state * I am unsure whether the last paragraph procedure is reliable and easy
to do.

### Section 4.4.2.1

s/between the producer and the consumer of the catalog/between the producer and
the consumer(s) of the catalog/ ?

### Section 6

Mostly at a DISCUSS level, but about the 1st paragraph, the 2 sentences are
contradictory (as "invalid." is not under control of the catalog producer):

* `a catalog producer MUST NOT use names that are not under the control of the
catalog producer` * `It is RECOMMENDED ...or to use a name under a suitable
name such as "invalid."`

## NITS

### I.e.

s/i.e./i.e.,/

### Section 3

s/Its records/Its resource records/ ? and introduce the RR abbreviation ?

s/for such zones/for regular zones/ ?

### Section 6

s/when catalog zones or another automatic configuration mechanism is not in
place/when catalog zones or another automatic configuration mechanism are not
in place/ ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments