DNS Catalog Zones
draft-ietf-dnsop-dns-catalog-zones-09
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Murray Kucherawy
(was Discuss)
Yes
Comment
(2023-02-14)
Sent
Thanks for the IANA work (and thus for handling my DISCUSS ballot). For posterity: I support Paul Wouters' DISCUSS position. General: Could I trouble you for an example of a complete sample catalog zone, perhaps in BIND format, in an appendix? I can see each individual concept illustrated, but it would be helpful to see them assembled someplace. Section 3: "Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation" seems peculiar. Wouldn't you do that anyway? Section 4.1: Given the text in Section 3 (specifically that a catalog zone follows the same rules as any other zone), is this section needed? The third paragraph could be its own differently-named section, but the rest seems redundant. Section 4.2: The SHOULD at the end leaves implementers with a choice. Why might an implementer choose to do something other than what it says? Or should this really be a MUST? Section 4.3: It doesn't say anywhere (unless I missed it) that the RRTYPEs of properties are unspecified, and depend on the property. It might be good to make that explicit, because I kept searching for it. Section 4.4.1: Regarding the last paragraph, is there any advice to pass on to operators about how exactly one can tell when the COO is complete? Section 7: Why are the protections of zone transfers and updates only SHOULDs?
Paul Wouters
(was Discuss)
Yes
Comment
(2023-02-07)
Sent for earlier
Thanks for addressing my concerns. I'll leave two non-blocking comments here to consider. Why must a catalog server / zone only support one version at most? Eg if version "3" comes out that would add some things, but is backwards compatible with version "2", wouldn't it be useful to be able to have an RRset of two RRs, showing it supports both version 2 and 3? Why is there a constraint to only allow at most 1 version per catalog zone ? I find the valid use of the name "invalid" to be pretty horrible. An engineer looking at a catalog might quickly believe the invalid is a bug where it should have shown a real domain. Why not _catalog.arpa or something ?
Warren Kumari
Yes
Comment
(2023-01-04 for -08)
Sent
[ Trying something new here -- adding commentary in my existing Yes ballot ] I'd like to thank the authors for responding to the ADs with DISCUSS positions - it looks like the replies and pull request address most of the comments. I'd also like to thank David Blacka for the useful DNSDIR review - https://datatracker.ietf.org/doc/review-ietf-dnsop-dns-catalog-zones-08-dnsdir-lc-blacka-2022-12-27/
Éric Vyncke
Yes
Comment
(2023-01-02 for -08)
Sent
# É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
Erik Kline
No Objection
Comment
(2022-12-22 for -08)
Sent
# Internet AD comments for draft-ietf-dnsop-dns-catalog-zones-08 CC @ekline ## Nits ### S4.3 * "Member-specific properties are described in Section 4.3" -> "Member-specific properties are described in Section 4.4" ### S4.4.2.1 * S4.3.1 has quotation marks around the contents of the TXT record, whereas this section does not. Recommend standardizing on one format, and probably the one with surrounding quotation marks, i.e.: group.<unique-1>.zones.$CATZ 0 IN TXT "nodnssec" group.<unique-2>.zones.$CATZ 0 IN TXT "operator-x-sign-with-nsec3" group.<unique-2>.zones.$CATZ 0 IN TXT "operator-y-nsec3" Although, perhaps I've misunderstood something and this is not relevant.
Roman Danyliw
No Objection
Comment
(2022-12-30 for -08)
Sent
Thank you to Catherine Meadows for the SECDIR review. I support Murray Kucherawy DISCUSS position. ** Section 3. Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation. Can “meaningless” be more formally described? Are there specific RR which shouldn’t be in the catalog? ** Section 3. Editorial. The content of catalog zones may not be accessible from any recursive nameserver. Can the intent of this be clarified? Is it saying that the “contents of the catalog zone may _not necessarily_ be accessible from _all or some_ recursive nameservers”? or the “contents of the catalog zone _should not be/must not be_ accessible from any recursive nameserver”?
Zaheduzzaman Sarker
No Objection
Comment
(2023-01-03 for -08)
Not sent
Thanks for working on these specification. My read did not identified any TSV related issues. However, a SHOULD for authentication for catalog update seem rather weak. I am expecting security ADs will have a closer look at it. I regret on not getting explanations for more than 5 authors in this specification.
Alvaro Retana Former IESG member
No Objection
No Objection
(2023-01-03 for -08)
Not sent
[I support Murray's DISCUSS.]
Andrew Alston Former IESG member
No Objection
No Objection
(2023-01-05 for -08)
Not sent
I to support Murray's discuss.
Lars Eggert Former IESG member
No Objection
No Objection
(2022-12-22 for -08)
Sent
# GEN AD review of draft-ietf-dnsop-dns-catalog-zones-08 CC @larseggert Thanks to Russ Housley for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/V-jMkADwNBpUN-H4TyNcC_RdTwg). ## Comments ### Section 3, paragraph 2 ``` Catalog consumers MUST ignore any RR in the catalog zone which is meaningless to or otherwise not supported by the implementation. ``` Russ Housley raised this in his Gen-ART review: What is meant by "meaningless" here? ### Too many authors The document has seven authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Grammar/style #### "Table of Contents", paragraph 1 ``` tent of a DNS zone is synchronized amongst its primary and secondary nameserv ^^^^^^^ ``` Do not mix variants of the same word ("amongst" and "among") within a single text. #### Section 4.1, paragraph 3 ``` ord in the collection. <unique-N> has an unique value in the collection. When ^^ ``` Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". #### Section 5.1, paragraph 7 ``` dure described in Section 4.4.1. Otherwise a migration of a member zone from ^^^^^^^^^ ``` A comma may be missing after the conjunctive/linking adverb "Otherwise". #### Section 5.2, paragraph 2 ``` yet (because of a lost packet or down time or otherwise), but did already se ^^^^^^^^^ ``` This word is normally spelled as one. Did you mean "downtime"? #### Section 6, paragraph 1 ``` to enumerate the contents of a multi-valued property (such as the list of m ^^^^^^^^^^^^ ``` This word is normally spelled as one. ## 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. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
Robert Wilton Former IESG member
No Objection
No Objection
(2023-01-05 for -08)
Sent
Hi, Thanks for this document. I'm not an expert on DNS, and hence found it slightly harder to read. Minor level comments: (1) p 2, sec 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here. Is there a reference to generic DNS terminology that could be imported here. This may aid readers less familiar with DNS. Nit level comments: (2) p 12, sec 6. Implementation and operational Notes For example if the catalog is generated by some script and this script for whatever reason generates an empty catalog, millions of member zones may get deleted from their secondaries within seconds and all the affected domains may be offline in a blink. Minor bit, but I would expect the phrase to be "in a blink of an eye". Regards, Rob