PostWG IDNA2008 implementation, transition and deployment document preparation
vint at google.com
Fri Dec 18 12:48:31 CET 2009
tina dam has charge of the ICANN effort to introduce IDNs into
registration at the top level. She has been copied on your remarks as
you see in the CC list above.
On Dec 17, 2009, at 10:59 AM, jean-michel bernier de portzamparc wrote:
> Dear Vint,
> I am sorry if I conflate Cary's role. I am not used to ICANN (I do
> not even use root servers) and try to be as correct and open as I
> can, also to clarify what is everyone's scope and duty to the
> Internet users. I would hate to create confusion. This is why I
> asked if Tina Dam should not answer? I am also suggested to copy
> Bart Bowsinkle and Thomas Narten to get better guidance?
> 2009/12/17 Vint Cerf <vint at google.com>
> 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
> IANA gets inputs from ICANN policy-development and from IETF. We
> hope these are not in conflict.
> My only fear (from Cary's remark) is that what I have accepted to
> undertake in good faith could be in conflict sometime with others. I
> want to be sure it will not be the case. Who is the ICANN policy-
> development Manager or ITEF person who can best advise me ? The
> workon mailing list is currently moderated in order to avoid a wrong
> mission creep, but subscribers comes in. We want to advise people to
> best use IDNA2008 (in the hope it is quickly approved) not to oppose
> However, we already have participants complaining they are prevented
> to do so by ICANN. I try understand how. And how to best support the
> testing they want to initiate.Or to best handle the problem so we
> stay on a pure technical track. I was advised that technically the
> best was to stick to RFCs and to what ICANN and IETF signed, or ask
> for it to be updated. I accepted such an advise as wise.
> Thanks for the help
> 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
>> > is true for ASCII ccTLDs and IDNgTLDs (existing ones or projected
>> > 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
>> 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
>> 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
>> 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
>> "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
>> 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.
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update