Re: [arch-d] [DNSOP] Call for Comment: <draft-iab-arpa-authoritative-servers-00> (Nameservers for the Address and Routing Parameter Area ("arpa") Domain)

[Joe Abley <[e-mail]>]

On 6 May 2021, at 14:48, IAB Executive Administrative Manager <[e-mail]> 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
> [e-mail] and [e-mail].

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