Re: [Ianaplan] Summary/refinement of scenarios discussed so far (was Constructive redirect -- focusing discussions)

[John Curran <[e-mail]>]

On Sep 26, 2014, at 4:28 AM, Eliot Lear <[e-mail]> wrote:
> On 9/26/14, 2:39 AM, John Curran wrote:
>> If the IETF feels that it is contracting for IANA registry services 
>> for all of the IETF parameters spaces (including IPv4, IPv6, and ASNs), 
>> that would be important to know.  IF the output of the IANAplan process 
>> doesn't assume such, that would also worth documenting clearly. Sharing
>> such assumptions will hopefully make the resulting proposals easier for
>> the ICG to successfully collate into a single plan.
> 
> I believe that the flow is like this:
> Assignment of registries by the IAB/IETF to RIRs, ICANN, etc.
> RIRs and ICANN may choose how those registries are operated.
> The IETF retains policy policy for all other registries.  We do not retain policy authority for unicast ip addresses or DNS names with the exception that approaches taken by the RIRs and ICANN must be technically consistent with the Internet architecture, which will evolve (I hope).  The IETF and IAB retain responsibility for that.
> Given what I've written, what do you believe is necessary?
> 

Eliot -
 
   If what you have written can be made readily apparent (either via an updated RFC 2860,
   RFC 6220, or draft-iab-iana-framework++), that should suffice at a high-level for improving
   understanding of the various roles.

   Note that these identifier spaces span multiple registries (for example, the IPv6 space 
   has reservations based on technical architecture of the protocol, as well as space that 
   is "IETF Reserved", Global Unicast space, and delegations from Global Unicast to RIRs 
   per RFC 1881 and RIR Global IPv6 Allocation policy which has been provided to IANA)
   Publication of the entire "IPv6 address space" currently spans the full range of possible
   IPv6 identifier space, and is actually reflected in multiple IANA registries - 
      <http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml>
      <http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml>
      <http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml>
      <http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml>
   All of these are IPv6 identifier space, and there are times when they have to be treated
   as a single space (e.g. the coordination for reverse DNS support per RFC 5855.)

   When you indicate that "RIRs and ICANN choose how those registries are operated",
   do you mean with respect to the entire identifier space? (with appropriate liaison back
   with the IETF for technical reservations, etc.), or do you mean simply the delegated
   portion of the identifier space? (which is implies that the IETF contracts for the overall
   identifier space publication and that IANA operator coordinates with any RIR/ICANN
   delegated registry operator(s) as needed.)   I believe that either approach to delegated 
   registries can be made to work, but the choice is obviously impactful to the statement
   of work for the IANA operator(s) and any and therefore the SLA's, escalation procedures 
   and parties involved in the accountability mechanisms.  For example, if it is the entire 
   identifier space for which the RIRs/ICANN arranges for the IANA publication (with 
   appropriate liaison back to IETF for reserved entries), then one might expect that such
   an delegated IANA registry operator to have some accountability to the IETF in addition 
   to the party which contracted it, since it is publishing more that simply the delegated 
   portion of the identifier space...

Thanks!
/John

Disclaimer: my views alone.