(no hats) 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
