Re: [IANAxfer@apnic] Key elements of the transition of IANA stewardship
On Sep 11, 2014, at 10:40 AM, Richard Hill <rhill@hill-a.ch> wrote:
>> -----Original Message-----
>> From: John Curran [mailto:jcurran@arin.net]
>> ...
>> Why do you presume "formal designation"?
>
> Because there are formal documents: the ICANN Bylaws, the contract with NTIA
> for the IANA functions and, at least for protocol parameters,
The USG/NTIA contract is not have to be the model that used going forward;
remember, NTIA asking the community to develop a plan for transition of the
IANA Stewardship and that presumes the NTIA contract is extinguished in the
process. We need to maintain that structure just as much as we need to keep
punched tape readers on our laptops, simply because that was used in the past...
> the MoU between ICANN and IETF.
The MOU between ICANN and IETF is for provision of IANA services, and is not
a formal designation of "authority" that you seem to be desperately seeking.
>> It says:
>>
>> These spaces have "policy issues" (in addition to technical
>> considerations)
>>
>> Those "policy issues" are outside the scope of the MOU - again,
>> this clearly
>> says that the _policy issues_ for these spaces are outside the
>> MOU scope, it
>> does not say that the administration of these spaces is outside
>> of the scope.
>
> That is a possible interpretation. In order to make things clear, it would
> be better to rephrase it to say explicitly that the administration of those
> spaces is within scope.
The administration of all IETF registries is in scope of the MOU -
" ICANN agrees that during the term of this MOU it shall cause IANA
to comply, for protocols within IETF's scope, with the following
requirements, which ICANN and IETF acknowledge reflect the existing
arrangements under which the IANA is operated:
4.1. The IANA will assign and register Internet protocol parameters
only as directed by the criteria and procedures specified in RFCs,
including Proposed, Draft and full Internet Standards and Best
Current Practice documents, and any other RFC that calls for IANA
assignment. If they are not so specified, or in case of ambiguity,
IANA will continue to assign and register Internet protocol
parameters that have traditionally been registered by IANA, following
past and current practice for such assignments, unless otherwise
directed by the IESG."
The DNS specifications create a DNS root zone registry, and that must
be administered. The IP protocol specifications create IP address
registries, which must be administered.
> But that still leaves open the issue of who, in the end, formally approves
> the policies. As far as I can tell, you are not arguing that the MoU
> between ICANN and IETF says that IETF is the ultimate authority for IP
> addressing policies.
The MOU is for provision of IANA registry services in accordance with the
technical specifications of the IETF. It notes also that two particular
registry spaces (domain names and IP addresses) pose "policy issues" and
_these policy issues_ (not the administration) is outside of the scope of
the MOU.
It makes no statement about "authority" over these policy issues, other than
to make clear the administration of the registries in question (domain names
and IP addresses) shall not be done in such a way that conflicts the IETF's
need to put technical entries into those same registries (e.g. reverse DNS
zones, specialized IP address reservations, etc.) This is necessary because
each of these registries (DNS root zone, IP address spaces) contain entries
from multiple entities.
> So I think that my point is valid: absent the NTIA IANA functions contract,
> the ICANN Board would be the ultimate authority that approves IP addressing
> policies, unless the contrary is specified, for example in a new MoU between
> ICANN and NRO.
I'm sorry... There is no statement noting authority for those policy spaces,
and the ICANN bylaws call for it to _coordinate_ in these areas. Your point
is not derived from anything; it's an assertion absent obviously statements
to the contrary.
>> It then goes on to say: "In the event ICANN adopts a policy that
>> prevents it
>> from complying with the provisions of this Section 4 with respect to the
>> assignments described in (a) - (c) above, ICANN will notify the
>> IETF, which
>> may then exercise its ability to cancel this MOU under Section 2 above."
>>
>> How can ICANN possibly adopt a policy (dealing with "policy issues") which
>> in some way prevents it from complying with IETF guidance for
>> administration
>> of these spaces, UNLESS ICANN IS ADMINISTERING THESE SPACES (just
>> as it does
>> for every other IANA registry per this MOU.)
>
> The clause in question applies only to the narrow areas described in
> (a)-(c), not to IP addressing policies in general.
The point applies to ICANN's administration of these registry spaces
(which are shared, containing entries which are both from the IETF
and which pose "policy issues"), and it notes that the IETF entries
into these registries shall not be impinged.
> All I'm suggesting is that the NRO MoU with ICANN be expanded to be similar
> to the IETF MoU with ICANN.
That may or may not be a good idea; I express no view as it is a matter
for the community and elected governing bodies of the RIRs to ponder. I
only note that RFC 2860 is not a statement of "policy authority" over
either the DNS or IP address spaces, but is an agreement for provision
of IANA registry services to the IETF by ICANN.
You did not answer my question, nor even reference it on your reply. In
order to clarify the matter of these registries, please answer this
question:
If the IETF were to create a new version of the Internet Protocol
(version 42), who would be the "policy authority" for the associated
IANA IPv42 number registry (and why?)
Thank you,
/John