Re: [Ianaplan] General purpose number registries & policy engagement

[John Curran <[e-mail]>]

On Oct 20, 2014, at 12:18 PM, Andrei Robachevsky <[e-mail]> wrote:
> ...
> John, I am not sure what points do the RFCs you mentioned support? Both
> of them are incomplete wrt specifying what falls under the IETF
> authority (e.g. multicast).

Andrei -

I thought that RFC 7249 was fairly clear on this aspect; do you think
it needs to changed or updated? - 

From [RFC 7249]
"
   Three IANA registries are associated with the Internet Numbers
   Registry System: "Autonomous System (AS) Numbers", "IANA IPv4 Address
   Space Registry", and "IPv6 Global Unicast Address Assignments".
   However, in each case, there are special-purpose values, and those
   special-purpose values are outside the Internet Numbers Registry
   System.
...
   The allocation and registration functions for all non-reserved AS
   numbers are handled by the Internet Numbers Registry System in
   accordance with policies developed by the Regional Internet
   Registries (RIRs) in accordance with their processes.
   Some special-purpose AS numbers have been reserved.  Section 3 of
   this document establishes an IANA registry for special-purpose AS
   Numbers that have already been reserved.  
...
   The allocation and registration functions for all non-reserved,
   globally unique unicast IPv4 addresses are handled by the Internet
   Numbers Registry System in accordance with policies developed by the
   RIRs in accordance with their processes.
   Reservations of special-purpose IPv4 addresses can be found in the
   IANA registry [IANA-IPv4-Reg].
...
   The vast bulk of the IPv6 address space (approximately 7/8ths of the
   whole address space) is reserved by the IETF [RFC4291], with the
   expectation that further assignment of globally unique unicast
   address space will be made from this reserved space in accordance
   with future needs.
   The allocation and registration functions for all non-reserved
   globally unique unicast IPv6 addresses are handled by the Internet
   Numbers Registry System in accordance with policies developed by the
   RIRs in accordance with their processes.
   Reservations of special-purpose IPv6 addresses can be found in the
   IANA registry [IANA-IPv6-Reg]. 
"

> A question of "delegation" is not really
> discussed there, too. I thought it might be a better approach to carve
> out what is in the IETF realm and for which the IETF takes responsibility.

See above regarding "carving out what is in the IETF realm".. there 
is text that references the relevant special purpose IANA registries.

Delegation within the IANA identifier system is covered at length in the IANA 
framework document - <https://tools.ietf.org/html/draft-iab-iana-framework-02>
This is still a draft document and probably needs to get more discussion
and review so that publication in the near future can be accomplished.

> IMO, if delineation of areas of responsibility in respect to the number
> registries is clear in the final combined proposal, these questions do
> not have to be answered here (and there). So whatever statement we
> include in our response it is important that it is matched by a
> corresponding statement in the CRISP Team proposal.

I'm uncertain if that is the case; more specifically, it is possible 
that the authority for given portion of any identifier space to be 
perfectly clear, and still not know if there is a requirement that, 
for various technical/operational reasons, that is desirable any given 
identifier space to be published by one party, i.e. that there is one 
IANA operator handling the entire IPv4 or IPv6 space, even if getting
entries from multiple authorities.

Even if the responsibility to contract/arrange for IANA services is 
clearly documented to held by the IETF, RIRs, and ICANN respectively, 
it would be good for the IETF to be very clear what it has for 
expectations (if any) as to whether those parties must or should 
contract to the same party for IANA operations.  If the answer is 
that this is not required, then we need to understand what is the 
coordination & oversight processes that make such possible, i.e. does 
the IETF accept such responsibility to make sure that IANA services
work fine or does it fall to the delegated registry authority to make 
sure their IANA contractor works with the IETF's IANA contractor to
accomplish such?

FYI,
/John

Disclaimer: my views alone.