[CRISP-TEAM] Clarifying the possibility of deletation to another IANA operator Fwd: [NRO-IANAXFER] Comments on CRISP proposal

[Izumi Okutani]

CRISP Team,


Related to the suggestion made on the IANAXFER list, I recall it has
been discussed in the past CRISP Team calls to add clause of termination
condition and change IANA operator if the current operator(ICANN)
doesn't meet the needs. No objections were observed.

If anyone has concerns about adding the clause on the contract
(possibility of redelegation the IANA operation to another organization
if ICANN doesn't meet certain conditions), please share on the list.

(snip)
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.
(snip)


------

Question to CRISP Team ;
Supposing we agree about to add clause in the contract about possibility
of changing the IANA operator as termination clause, does it make sense
to describe our general direction in the ICG proposal, as suggested?

(i.e, not to describe details of the clause to be put into the contract,
but clarify our general direction in our proposal, to have the
possibility of changing IANA operator incase the current operator
doesn't meet the needs of RIRs and its communities)




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