PostWG IDNA2008 implementation, transition and deployment document preparation

jean-michel bernier de portzamparc jmabdp at gmail.com
Thu Dec 17 15:52:22 CET 2009


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
)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091217/88b01d69/attachment.htm 


More information about the Idna-update mailing list