PostWG IDNA2008 implementation, transition and deployment document preparation

[Vint Cerf]

IANA follows directions from IETF on the management of technical  
parameters and tables.

ICANN has policy development mechanisms for the TLD's. IANA also  
manages a set of tables specific to language and TLD at the request of  
the ICANN Board.

Cary is serving ICANN in a policy development role.

You are conflating Cary's role as the manager of .MUSEUM and his role  
at ICANN's invitation to serve as part of a policy-development  
apparatus.

IANA gets inputs from ICANN policy-development and from IETF. We hope  
these are not in conflict.

vint


On Dec 17, 2009, at 9:52 AM, jean-michel bernier de portzamparc wrote:

> 2009/12/17 Cary Karp <ck at nic.museum>
> > I have however a question: .MUSEUM is an ASCII extension
> > which has no right to contribute to FAST TRACK. I also understand  
> this
> > is true for ASCII ccTLDs and IDNgTLDs (existing ones or projected  
> ones).
> > This is surprising to me as the basis for transition rules can  
> only be
> > in conformance with RFC 5226?
>
> Despite the question mark at the end of this, I'm afraid that I can't
> tell what the question is.
>
> Sorry, the implied question was "ist it, is it not?"
>
> .MUSEUM has not participated in the Fast Track process in any manner
> whatsoever.
>
> This is what I find surprising since (a) you are part of the team  
> defining its guidelines, (b) I do not understand what .MUSEUM is no  
> part of it (is there not a Chinese, a Greek, or a Russian name for  
> "Museum"), why do we discuss the eszett if it cannot be part of  
> FASTTRACK (c) this seems in opposition with the RFC 5226 first come,  
> first serve rule?
>
> I cannot see any heading in RFC 5226 under which the ICANN IDN
> Guidelines fall. They are not protocols nor otherwise maintained as an
> RFC, and the IANA does not participate in their development.
>
> Then we have a misunderstanding to clarify concerning ICANN.
>
> As Internet Users we understand ICANN as the IANA Manager for names  
> and numbers (RFC 2860: "The IANA technical team is now part of  
> ICANN"). Contracts between ICANN Inc. and TLD Managers may have  
> indirect impacts on people, but not on the Internet as defined in  
> RFC 3935, i.e. the technology documented by the IETF that also apply  
> to private networks.
>
> We therefore consider RFC 5226 (and before RFC 2424) as the  
> architectural rule which relates IETF technology users and IANA and  
> its names and number governance in the default presentation and  
> Class IN: "In order for IANA to manage a given namespace prudently,  
> it needs guidelines describing the conditions under which new values  
> can be assigned or when modifications to existing values can be  
> made.  If IANA is expected to play a role in the management of a  
> namespace, IANA must be given clear and concise instructions  
> describing that role.  This document discusses issues that should be  
> considered in formulating a policy for assigning values to a  
> namespace and provides guidelines for authors on the specific text  
> that must be included in documents that place demands on IANA."
>
> IDNA2008 places demand on IANA and constrains the use of the  
> namespace that IANA has the primary mission to document and ICANN is  
> establish to administrate in class IN. In this we understand we  
> fully comply with ICANN published and reclaimed policy in its ICP-3  
> document.
>
> I certainly understand that " It is recognized that ICANN may,  
> through the IANA, provide similar services to other organisations  
> with respect to protocols not within IETF's scope (i.e. registries  
> not created by IETF or IRTF action); nothing in this MOU limits  
> ICANN's ability to do so.". However, I understand that IDNA2008 is  
> acknowledged by ICANN as part of the IETF scope.
>
> RFC 2860 acknowledges that :
>
> "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.)."
>
> It seems that Tina should enlight us on the issue, so we understand  
> well how every concerned one stands in regards of IDNA2008  
> implempentation, transition and deployment on a network wide basis.
>
> Thank you for your help in clarifying this.
>
> Portzamparc.
>
> PS. I understand that this belongs to the WG/IDNABIS scope, but does  
> not affect the text of the protocol vehicle. If not, we should  
> organise another mailing list to discuss it, or use one of ours  
> (ICANN or workon at idna2010.org)
>
>
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091217/435bbe12/attachment-0001.htm