[discuss] Interesting article

[Peter Dengate Thrush]

On 16/01/2014, at 10:52 AM, Brian E Carpenter wrote:

> On 15/01/2014 04:05, Dominique Lacroix wrote:
>> Sorry Jorge, but we must be clear for all the people who try to understand:
>> 
>> Icann IS IN CHARGE of Iana, and for several years!
>> See: http://www.ntia.doc.gov/page/iana-functions-purchase-order
> 
> That is a partial story. Actually the NTIA contract is
> redundant. The IETF MoU is the instrument by which the
> technical community delegated the IANA function to ICANN.

Hello Brian
While I think it accurate and helpful to include the IETF MoU as part of the authority ICANN has for doing this portion of IANA work, I think its wrong to elevate its importance to the degree you do, and similarly to consequentially denigrate the importance of the IANA name and number functions ICANN performs.

Here are the terms of work of that MoU (http://www.icann.org/en/about/agreements/ietf/ietf-icann-mou-01mar00-en.htm):
4. Agreed technical work items. 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.

If in doubt or in case of a technical dispute, IANA will seek and follow technical guidance exclusively from the IESG. Where appropriate the IESG will appoint an expert to advise IANA.

The IANA will work with the IETF to develop any missing criteria and procedures over time, which the IANA will adopt when so instructed by the IESG.

4.2. In the event of technical dispute between the IANA and the IESG, both will seek guidance from the IAB whose decision shall be final.

4.3. Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU.

Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4. (For purposes of this MOU, the term "assignments" includes allocations.) 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.

4.4. The IANA shall make available to the public, on-line and free of charge, information about each current assignment, including contact details for the assignee. Assignments published in RFCs by the RFC Editor and available publicly will be deemed to meet the requirements of this Section 4.4.

4.5. The IANA shall provide on-line facilities for the public to request Internet protocol parameter assignments and shall either execute such assignments, or deny them for non-conformance with applicable technical requirements, in a timely manner. There shall be no charge for assignments without the consent of the IAB. Requests shall only be denied on legitimate technical grounds.

For protocols within the IETF scope (i.e., registries created by IETF action), appeals against such denials may be made to the IESG and subsequently to the IAB as provided in 4.2 above.

4.6. The IANA shall have non-voting liaison seats on appropriate IETF committees as determined by the IETF, and may participate in all IETF discussions concerning technical requirements for protocol parameter assignment through such liaisons.

4.7. The IANA shall review all documents in IETF Last Call to identify any issues of concern to the IANA, and shall raise these issues with the IESG.


While the parameter protocols covered by this are no doubt important to the IETF and others, they rarely come to the attention of players outside the technical community, and are not the cause of any of the angst that the control the US has over approving ccTLD changes in the root, or the policy issues over new gTLDs have caused other national governments.

> From a multi-stakeholder or technical viewpoint, nothing
> would change if the NTIA contract was cancelled today.
> 


I don't understand your point here at all.
If the NTIA contract with ICANN to perform the IANA functions were to be cancelled, presumably another entity would have to be appointed. If that were to be the USG itself, that would have enormous political repercussions, and would undo 15 years of work by the USG in supporting the establishment and growth of an independent ICANN.

Can you expand on your thinking a little?

regards


Peter


>> Without Iana contract, Icann would not be a political issue.
> 
> Without the _NTIA_ contract, I agree.
> 
> On 16/01/2014 04:05, Peter Dengate Thrush wrote:
> ...
>> The PSC final recommendation was that ICANN look at the international not for profit status available under Swiss law.
> 
> Which was of course one of the more attractive options
> rejected in 1998. If I could have three wishes, the first
> two would be unconditional cancellation of the NTIA
> contract and relocation of ICANN's seat to Geneva.
> 
>    Brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140117/355b0a31/attachment.html>