ICANN Variant Issues Project initial definitions document

[J-F C. Morfin]

Dear Andrew and colleagues,

1. As far as the IETF technology is concerned, ICANN is the 
facilitator of the "ICANN community" (cf. ICANN IDV Variant Issues 
Project Initial Definition Project - end of the leading Note to 
readers) just as in any other users' communities. IDNA2008 has 
actually documented that users' communities had an important role to 
play in the IDNS deployment. As such, a proper IETF place to debate 
the users' layers support issues is the iucg at ietf.org non-WG mailing list.
<https://www.ietf.org/mailman/listinfo/iucg>https://www.ietf.org/mailman/listinfo/iucg


2. The IDNA Charter states: "The constraints of the original IDN WG 
still apply to IDNABIS, namely to avoid disturbing the current use 
and operation of the domain name system." and "This work is intended 
to specify an improved means to produce and use stable and 
unambiguous IDN identifiers."

Since ICANN is specifically referring to IDNA2008, if ICANN's or any 
other users communities' propositions could disturb the current use 
and operation of the domain name system, and the production and use 
of stable and unambiguous IDN identifiers, it would mean that the 
IDNA2008 document set was not complete enough and would require an 
additional document (not a revision).

Since the Charter states: "This working group will be providing 
extended public review of the output of a design team that has been 
working on improvement of the IDNA specifications", it would mean 
that the design team's work was not completed and should, therefore, 
be resumed.


3. At the current stage, the design team's work  does not look fully 
completed and the IDNA2008 has added fuel to call for and assist in 
that completion.

     - we saw it with Patrik Falström over the last version of Unicode.
     - we see it with the IAB road map and John Klensin's RFC and 
works (and others' concerns)
     - we see it though Paul Hoffman and John Klensin's I_D, within 
which the ICANN VIP work should be included.
     - my own commitment to the ML-DNS to encapsulate the DNS as the 
stable core of a more versatile use together with RFC 3890-3895 
[underlying the Internet architectural principle of subsidiarity, at 
the same level as the principle of constant change (RFC 1958) and of 
the principle of simplicity (RFC 3439)], has opened up another way to 
consider the digital plex with the Internet as one of its cores. BTW 
I apologize for my delayed follow-up, which is due to personal 
constraints. However, the work is indeed underway: since it takes 
full advantage of the Internet and the DNS architectural stability to 
build around them it is much larger than what I thought I could only 
document and then help developing. I need to experiment first, and, 
therefore, develop a prototype, before I can document the whole thing.
     - we can also see it now through the ICANN VIP endeavor.

This being considered, the "design team" should be resumed and 
enlarged to one or a few experts from all the concerned lead users' 
communities. The iucg at ietf.org or the idna-update at alvestrand.no or 
any other private list would do. The charter would be to expend the 
IDNA2008 "after-sales" support to users' communities, perhaps on a 
permanent basis through a non-WG mailing list?

I would also like to note that after two years of experience, I plan 
to review the <http://iucg.org/>http://iucg.org site in order to 
better address the expectations of the IETF users' community and 
welcome the ICANN, IUse, continental, @large, etc. communities that 
use to provide occasional input (often on a private basis) that I 
address through the site rather than a constant flow of comments, 
since there is not yet an IETF users' Internet use oriented debate 
(as the VIP work exemplifies it). This work should be carried out this summer.


4. Concerning the VIP specific concern, I disapprove the use of 
variants in any DNS root file. This is not only because it can become 
tricky but maily because IDNA2008 is a success because there is no 
mapping on the network side. Variants are mapping inside the DNS, 
while IDNA2008 kept the DNS untouched. However, this does not prevent 
me to consider variants in the IDNS virtual root matrix, and to 
address them at the ML-DNS. The Multi-Layer DNS is precisely where 
user domain names (UDNs) are massaged to become IDNs acceptable to 
the untouched DNS core.

jfc

At 02:33 19/07/2011, Andrew Sullivan wrote:
>Dear colleagues,
>
>Apologies if you see this note elsewhere.  The ICANN Variant Issues
>Project has previously drawn attention to its activities on this list.
>I wanted to draw people's attention to some definitions that were
>offered to the teams as part of their work.  They're available from
>https://community.icann.org/download/attachments/16842765/initial_definitions_2011-07-15-clean.pdf?version=1&modificationDate=1310760720000.
>
>The project is publishing these definitions in an effort to ensure
>they get as wide review as possible.  If you wish to make comments, it
>would be ideal if you were to do so on the vip mailing list
>(https://mm.icann.org/mailman/listinfo/vip).  If that doesn't suit
>your fancy, feel free to send your comments to me and I'll see that
>they get passed along.  Please do not use the idna-update mailing list
>for discussion, because I suspect this is off-charter.
>
>I should note, as a matter of full disclosure, that ICANN has me
>consulting on the vip work.
>
>Best regards,
>
>Andrew
>
>--
>Andrew Sullivan
>ajs at anvilwalrusden.com
>_______________________________________________
>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/20110719/66a5caff/attachment.html>