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

From: IAB Executive Administrative Manager <[email-masked]>
Date: Thu, 06 May 2021 11:48:04 -0700

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-masked] and [email-masked].

Abstract:

   This document describes revisions to operational practices to
   separate function of the "arpa" top-level domain in the DNS from its
   historical operation alongside the DNS root zone.

---

From: Russ Housley <[email-masked]>
Date: Thu, 6 May 2021 14:52:24 -0400

I have read this document, and this seems like a fine way to separate the .arpa servers from the root servers.

Russ

> On May 6, 2021, at 2:48 PM, IAB Executive Administrative Manager <[email-masked]> wrote:
>

---

From: Paul Wouters <[email-masked]>
Date: Thu, 6 May 2021 15:05:16 -0400 (EDT)

On Thu, 6 May 2021, IAB Executive Administrative Manager wrote:

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

This has come up a number of times in the past, and I'm happt to see
this moving forward. The suggested approach seems well thought out.

Paul

---

From: Eliot Lear <[email-masked]>
Date: Thu, 6 May 2021 21:12:23 +0200

+1.  I think it looks good.

One very minor comment (more a question): if I read between the lines, it seems that some thought went into the use of the term “name space” in Section 3.1 regarding there not being a zone cut for ns.arpa (not that it’s anyone’s business, I suppose).  Would it be reasonable to make more plain the logic for that decision?  I could envision at least two reasons, but my own logic could be faulty.

Eliot

> On 6 May 2021, at 20:52, Russ Housley <[email-masked]> wrote:
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: Joe Abley <[email-masked]>
Date: Thu, 6 May 2021 15:25:52 -0400

> [email-masked] and [email-masked].

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

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 6 May 2021 15:42:54 -0400

(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-masked]> wrote:

> 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.
>
> 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.
>
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 6 May 2021 16:01:17 -0400

> (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

>> > <https://datatracker.ietf.org/doc/draft-iab-arpa-authoritative-servers/
>> >
>> >
>> 2. RFC 5855 which the document cites uses a naming scheme for the
>> IP6.ARPA servers of the form <letter>.IP6-SERVERS.ARPA, and

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra