[CRISP-TEAM] Decription about 'in-addr.arpa' and 'ip6.arpa' DNS trees" Fwd: [NRO-IANAXFER] Comments on CRISP proposal

[Izumi Okutani]

CRISP Team,


I would like to ask for volunteer to take a look and addres this comment
on 'in-addr.arpa' and 'ip6.arpa' DNS trees" for Section 1 (P.1 & 2).

Think doesn't seem like a difficult point to address in my opinion.

Andrei or Alan
Would either of you be able to help, since you have been working on this
part? (drafting the revised text and response to NRO IAXAFER)

I'm aware you've already volunteered in other work so let me know if
this is too much.


(snip)
First, as a nit, on page 1, under "description of the service", it
mentions "delegation of the 'in-addr.arpa' and 'ip6.arpa' DNS trees".
Perhaps this means "delegation from"?  IANA doesn't delegate those two
names to any of the RIRs, but delegates spaces within them.  (I
suspect this is just an editorial nit, but it confused me on first
reading.)  There's a similar issue under "what registries", on p2, and
it's only really made clear in the "overlaps" section (also on p2).  I
am prepared to imagine that I'm the only person who was led astray by
this, and it's not a real big deal, but it might be nice to clarify.
(snip)


Izumi


-------- Forwarded Message --------
Subject: [NRO-IANAXFER] Comments on CRISP proposal
Date: Mon, 29 Dec 2014 15:47:30 -0500
From: Andrew Sullivan <ajs at anvilwalrusden.com>
To: ianaxfer at nro.net

Dear colleagues,

I have read the file
<https://www.nro.net/wp-content/uploads/CRISP-IANA-PROPOSAL-Draft-24122014-clean.pdf>.
I have some comments to make under personal title (i.e. I make these
remarks without respect to any membership or relationship I might have
to any corporate or other body).

I want to thank the CRISP team for some very good work.  The proposal
seems to me to be overall sensible and achievable.  If the proposal
were made final as is (modulo the missing bits), I think that would
provide a good base from which to begin.  I do have two small
suggestions for alterations, however.

First, as a nit, on page 1, under "description of the service", it
mentions "delegation of the 'in-addr.arpa' and 'ip6.arpa' DNS trees".
Perhaps this means "delegation from"?  IANA doesn't delegate those two
names to any of the RIRs, but delegates spaces within them.  (I
suspect this is just an editorial nit, but it confused me on first
reading.)  There's a similar issue under "what registries", on p2, and
it's only really made clear in the "overlaps" section (also on p2).  I
am prepared to imagine that I'm the only person who was led astray by
this, and it's not a real big deal, but it might be nice to clarify.

Second, I don't know whether this matters, but the text does not seem
to discuss the possibility of the NRO finding itself in the position
of needing to change IANA operators, and yet being unable to get other
IANA users to do the same thing.  That scenario, however, is implied
by the NRO undertaking a contract with ICANN presumably just for the
functions the NRO needs done.  I don't think this is a big deal, but
it might be worth saying something about how termination is expected
to be handled.  If this is implied in the retention of the existing
framework, perhaps an additional sentence making this slightly plainer
would be helpful.

Again, on the whole I think this proposal is very much the right way
to go.  I regard the above issues as small and not as showstoppers.
My thanks to the group that put it together.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs at anvilwalrusden.com

_______________________________________________
ianaxfer mailing list
ianaxfer at nro.net
https://www.nro.net/mailman/listinfo/ianaxfer