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

On Thu, May 6, 2021 at 3:43 PM Tim Wicinski <tjw.ietf@gmail.com> 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 <jabley@hopcount.ca> wrote:
>
>> On 6 May 2021, at 14:48, IAB Executive Administrative Manager <
>> execd@iab.org> 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
>> > architecture-discuss@ietf.org and iab@iab.org.
>>
>> 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
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> 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