On Thu, May 6, 2021 at 3:43 PM Tim Wicinski <[email protected]> wrote:
> (no hats) > <aol>Me too!</aol> I've previously reviewed this (somewhere!), and my views remain the same: 1: looks good to me and 2: this is legely an internal to IANA matter. Nice of 'em to ask, but whatever... W > > I'm glad this is moving forward. Joe's point about 5855 is valid on the > naming, and the zone cuts. > > It's never mentioned the zone is signed, though I'm sure everyone here > reading it expects it. > > Nit: At the top, instead of "Updates: RFC3172" it should be "Updates: > 3172". > > tim > > > On Thu, May 6, 2021 at 3:26 PM Joe Abley <[email protected]> wrote: > >> On 6 May 2021, at 14:48, IAB Executive Administrative Manager < >> [email protected]> wrote: >> >> > This is an announcement of an IETF-wide Call for Comment on >> > draft-iab-arpa-authoritative-servers-00. >> > >> > The document is being considered for publication as an Informational >> RFC >> > within the IAB stream, and is available for inspection at: >> > <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/ >> > >> > >> > The Call for Comment will last until 2021-06-03. Please send comments to >> > [email protected] and [email protected]. >> >> I have read this document. It is good to see this work proceeding. It has >> been in the fridge for a long time and it's good to get it on the stove. >> >> I have a few minor suggestions that the authors might like to consider. >> >> 1. In various places the text refers variously to phrases like "root >> operations" and "root server operations". I think the terminology could use >> some consistency; there are differences between the management of the root >> zone as a data object, its provisioning through the IANA functions operator >> and the Root Zone Maintainer and serving it on nameservers operated by Root >> Server Operators. If the document has things to say about this, even at a >> high level, I don't think there is harm in being clear. The authors are >> more aware of these differences than most other people and I don't think >> they need my editorial suggestions in this regard, but if it seems like it >> would be helpful to be more explicit by way of illustration I'd be happy to. >> >> 2. RFC 5855 which the document cites uses a naming scheme for the >> IP6.ARPA servers of the form <letter>.IP6-SERVERS.ARPA, and >> <letter>.IN-ADDR-SERVERS.ARPA for the IN-ADDR.ARPA servers. It seems to me >> that it would do no harm to choose a scheme for ARPA of the form >> <letter>.ARPA-SERVERS.ARPA for the ARPA zone; response size differences are >> minimal thanks to label compression and I think the scheme is more >> consistent (also with the names of the root servers). It also helps, I >> think, to give the impression that these servers are intended for a single >> purpose and are not general-purpose nameservers intended also to host other >> zones in the future (which I think would be a mistake). >> >> 3. This document describes a naming scheme under NS.ARPA (but see 2, >> above) without specifying whether it should be provisioned within the ARPA >> zone, or in a separate zone as was specified in RFC 5855. If the practice >> established in RFC 5855 (and in the root zone before it) was continued, >> this would be a separate zone hosted on the same servers as ARPA. If this >> ambiguity is deliberate (if it's desirable to leave this up to the whim of >> the IANA functions operator) then it would be good to document why. I think >> there are operational advantages to having zone cuts in the namespace, e.g. >> to preserve the possibility of hosting the child zones elsewhere, perhaps >> because it becomes operationally useful to sign them differently, speaking >> of which: >> >> 4. There's no mention of whether NS.ARPA (again, see 2, above), if it is >> provisioned as a separate zone, should be signed. Given the ambiguity in >> (3) I think this is a gap that could usefully be filled. I think it should >> be signed. >> >> 5. The term "in-bailiwick" feels awkward to me in the context of section >> 3.1, since to me it's a term associated with response construction and what >> is being discussed in that paragraph is namespace. However, since every TLD >> requires glue in the root zone I think the whole of the last paragraph >> could be safely removed. It's sufficient that ARPA be delegated according >> to normal practices for handling TLDs, and I don't think it makes sense to >> give the appearance of including special requirements for ARPA in this >> document, even if today they match everything else. >> >> Hope this is helpful, and once again I'm glad to see this work is moving >> forward. >> >> >> Joe >> _______________________________________________ >> DNSOP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
