- vip - lists.icann.org

Re: [vip] Educational session on existing variant practices
by Andrzej Bartosiewicz July 25, 2011

July 25, 2011

Sure. I will cover that... -- Dr. Andrzej Bartosiewicz, CEO & President, Yonita Inc. phone (US): +1 650 2493707 phone (Poland): +48 518 235209 Jothan Frakes <jothan(a)gmail.com> wrote: >Nice work, Andrzej- > >You might want to expose the tæst1234.pl (xn--tst1234-mxa.pl) and >taest1234.pl homograph potential in this which is something that has >occurred since. > >https://bugzilla.mozilla.org/show_bug.cgi?id=618051#c12 > >-Jothan > >Jothan Frakes >+1.206-355-0230 tel >+1.206-201-6881 fax > > > >On Sun, Jul 24, 2011 at 1:43 PM, Andrzej Bartosiewicz ><andrzej(a)yonita.com> wrote: >> Dear Steve, >> >> Here are my draft slides for webinar: >> http://yonita.com/ICANN-IDN-Variants-Bartosiewicz.pdf >> http://yonita.com/ICANN-IDN-Variants-Bartosiewicz.pptx >> >> Best, >> Andrzej >> >> >> On 7/15/2011 7:53 PM, Steve Sheng wrote: >> >> Dear all, the IDN variant project team appreciates your contribution. Based >> on the request, we will organize a webinar. >> >> Here is a draft agenda: >> >> 1. An overview of existing TLD programs related to variants by ICANN staff >> [15 minutes] >> >> 2. Experience of variant handling in ccTLDs [50 minutes] >> >> Five presentations, 7 mins each + 15 mins Q&A >> >> Fahd Batayneh, Iftikhar H. Shah, Behnam Esfahbod, Andrzej Bartosiewicz, >> Vladimir Shadrunov >> >> 4: Overview of DNS mechanisms and status from IETF standards. [7 mins] >> >> 5: Outline of RFC discussions about variant handling. [15 mins] >> >> 6. 3 min wrap up. >> >> Before we close the queue, are there any others willing to share their >> experiences? >> >> We will also proceed to arrange a time that speakers can make and announce >> the dates shortly. Given the global nature of our audience, we may have to >> run two exact webinars. >> >> Warm regards, >> IDN Variant Project Team >>

2 1

Thanks
by jfcallo＠ciencitec.com July 25, 2011

July 25, 2011

Thanks for suscription. Jose F. Callo Romero CEO - ciencitec.com

1 0

Re: [vip] [ncsg-policy] Proposed NCUC Comments on the WHOIS Review Team Discussion Paper
by JFC Morfin July 23, 2011

July 23, 2011

At 12:17 22/07/2011, Timothe Litt wrote: >Like driving, a network presence, including a domain name, is a >privilege and not an absolute right. Who decided that? Milton has addressed that point. However, Milton reintroduces the point when he states: " Instead we put limits on who can access this database (the police, LEAs) and the uses to which the data can be put." Who is "we". There is a single authority: the zone manager, there is only one law: the national law of the zone manager. There is only one rule to respect: the most stringent sovereign privacy rule, worldwide - otherwise there is not world of right. Now, let me clarify. There is no right or privilege in Internet use, there are facts. Rights and privileges may only concern Internet usages and people's Internet related behaviours and be enforced by governance regalian entities. The Internet is a technical consensus It works the way its programs are written. Programs are written to work. To obtain it, developers consider RFCs in the OSI layers 1 to 7; and listen to the users (the "market") otherwise. This is why the Internet constitution is in the code, not in the ICANN community. ICANN is the leader of one of the communities populating the Internet community, which is actually a community of communities. In the sole naming area, the Internet community has : - one single rule which is the DNS that provide information enough (mail, nameserver, registry, zone manager) to be maintained. - at least seven sub-communities that technology MUST support: 1. ICANN full-rate gTLDs, the vip(a)icann.org mailing list should discuss the technical requirements. 2. ICANN JAS-rated. There is no indication yet about their possible technical difference with the above. 3. open source gTLDs. 4. government created gTLD, e.g. China. 5. ISO 3166/MA decided ccTLDs. 6. industrial community (GSMA, Google, etc.) to support their own root. Who knows about .gsm? 7. non-Internet limited emergent IUse community and IUI (Intelligent Use Interface) related worked-on technologies. IDNA2008 exemplified how RFCs fully support it. ICANN has documented this situation. That was through its 2001 ICP-3, <http://www.icann.org/en/icp/icp-3.htm>http://www.icann.org/en/icp/icp-3.htm that states: "In an ever-evolving Internet, ultimately there may be better architectures for getting the job done where the need for a single, authoritative root will not be an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged". In 2011, in approving the gTLDs system, ICANN has acknowledged that what was not the case in 2001 is in fact the case today. The single, authoritative root is not a limited file anymore that is disseminated by the root server system. ICANN tends to present it as an open file while IUI sees it as a virtual matrix with millions of dimensions. IUI responds to the WSIS demand for a people centered society and inherits from a community experience that was acquired along the ICP-3 rules ("dot-root" project): everyone runs and creates his/her own needed part of a root that is not limited to names of the sole Internet. This results from a third principle in the Internet architecture (RFC 1958: permanent change; RFC 3439: simplicity) the principle of subsidiarity that IDNA2008 exemplifies. IDNA2008 was a positive surprise. The IDNA2008 positive surprise was that subsidiarity is built-in the Internet architecture from the very begining. There is not a single bit to change. However, what has not been done yet is to document the transition to get rid of the unnecessary added-complexity that has accumulated over the decades and to welcome the permitted innovation. This is the challenge: to simultaneously support and test opposed transitions like ICANN and IUse (and what is in between) without confusing either of them. This is why both of them have engaged in an analysis and documentation efforts and should try to cooperate (e.g. http://idna2010) This is why we need a consensual cooperation. However, this cooperation is to be engaged in a technically and politically confused context due to the complementary charters of IETF and of the UNICODE Consortium, and to the discrepancies between the GAC and the WSIS objectives. 1. Clarification was obtained last year from IESG and IAB through my appeal over the IESG misrepresentation of the importance of IDNA2008. I could summarize it as: the IUI is an interface between the Internet (and alternate network technologies) and the external world. IETF is competent and interested in what belongs to or impacts the Internet but does not want to engage outside of the Internet area. 2. A clarification should be found with UNICODE through the "stringprep" replacement. IDNA2003 used "stringprep" to interface UNICODE to punycode entries. Stringprep is used by other IETF protocols but turns obsolete, since IDNA2008 does not use it anymore, freeing IDNA from Unicode versioning. The IETF (WG/PRECIS) tries to work out a solution. For good reasons that have endangered the IDNA2008 consensus, IUsers have a different vision of Unicode deliverables, and would like to consider starting at a deeper point of simplicity. IDNA2008 has protected IDNA from Unicode versioning. IUsers would like the IUI to protect them from Unicode and to void the need for stringprep in considering a no-phishing network protocol oriented scripting based on the visual aspects of the characters symbols in an unique common fount. This would remove the Unicode consortium from the network multilingualization loop and ease the naming adminance (long-term netkeeping, as opposed to medium-term governance and short-term operance). Two systems are actually of no real technical and operational use in well organized and secure DNS operations: - the root server system that answers 96% of erroneous requests and data everyone already has. - the WHOIS is system that violates the privacy law of most of the countries having one - and is a source for spaming, spoofing, etc. In addition, one system will become local and needs to get reviewed now ICANN has started selling $ 185.000 + expenses what everyone can deploy for free and get used by billions (reasonably within less than five years due to existing RFCs, word of the mouth, testing, new products and services being supported) or Google can deploy in minutes. That system is the ICANN whole technico-legal system itself. This means that the priority is to correctly insert that ICANN system into the foreseeable future development of the world digital ecosystem (WDE). This is to protect stable operations and usage by its customers. This cannot be done by rules or agreements (you cannot negotiate with billions of individuals). It can only be done through: - a stable, secure, simple, innovative technology these individuals will want to use for free as a "Plus" to the Internet they are used to utilize everyday. For many reasons IAB started to document IDNinApplication and xNAMES in the DNS as we consider them today are inadequate. However, a reponse MUST be found. - and support services they will competitively adopt. I doubt the WHOIS is going to be a major part of such services: because it does not propose anything to the advantage of the registrant. Ths WHOIS only was a Jon Postel's tool to manage "his" network with people moving around every academic year. A dinosaur. What actually IDNA2008 says is: here the way for DNS oriented concerns to interface the Internet DNS. The rest is to be entirely reviewed accordingly. Best jfc

1 0

Internationalization glossary
by jefsey July 22, 2011

July 22, 2011

For information I formated Paul Hoffman's and John Klensin Draft and the ICANN VIP initial terminology document in a similar wiki format to help a work towards a joint glossary where we could add ML-DNS, IUI and multilingualisation terms. We need this since IETF, ICANN and IUse communities steers on different tacks and we will need the IUI to support at least the three of them. http://iucg.org/wiki/Wiki_RFC_3536bis http://iucg.org/wiki/ICANN_Variant_Issues_Project_-_Definitions jfc

2 1

Re: [vip] Educational session on existing variant practices
by Andrzej Bartosiewicz July 4, 2011

July 4, 2011

Once again: great initiative Vlad! I hope we will have couple of days to prepare presentations before webinar. -- Dr. Andrzej Bartosiewicz, CEO & President, Yonita Inc. phone (US): +1 650 2493707 phone (Poland): +48 518235209 Vladimir Shadrunov <vlad.london.uk(a)gmail.com> wrote: >Seems the idea has some support and we have a few people who are willing to >share their knowledge and experience. Here's the list of those who responded >on 1, 2 and 3. > >1. Existing ICANN TLD programs (Fast Track, Applicant Guidebook) > >Oksana Prykhodko, *Fahd Batayneh*, iftakhar shah > >2. IDN ccTLD registries - variants on the top level > >*Fahd Batayneh, *iftakhar shah > >3. TLD registries - variants on the second level, > >*Fahd Batayneh*, Vladimir Shadrunov , Behnam Esfahbod, Andrzej Bartosiewicz > > >If someone active in the IETF community would be willing to give a >presentation on how existing DNS standards and related RFC handle string >similarity that would also be great. Additionally some feedback from the IP >lawyers would be appreciated as to whether the variant problem exists in the >IP realm. > > >May I defer it to the chair or to the moderator of this list to respond >regarding how a group-wide webinar can be implemented. > >Thanks, >Vladimir Shadrunov > >On 3 July 2011 15:20, Andrzej Bartosiewicz <andrzej(a)yonita.com> wrote: > >> ** >> On 6/30/2011 4:45 PM, Vladimir Shadrunov wrote: >> >> 3. TLD registries - variants on the second level >> >> >> Happy to share my experience with variants on TLD level. >> >> Best, >> Andrzej >> >> -- >> *Dr. Andrzej Bartosiewicz* >> phone (US): +1 650 2493707 >> phone (Poland): +48 518 235209 >>

1 0

Suggested meta-questions to think about
by Patrik Fältström June 30, 2011

June 30, 2011

Hi, I am sending this as an interested individual, and not as SSAC Chair... I have a few times this weekend already tried to explain my view on "variants", and after doing that in a chat, I felt it start to (for me) make sense, so I wanted to share with you. We have, I think, a problem divided in two different questions. And unfortunately many people think of the solution only the form of "answers to the second question". Let me try to explain. First, whether something is a variant or not (note: word is undefined), is actually a grayscale from "yes" to "no". There are various shades of gray there. For example: A.1. Two characters in Unicode really are to be treated as being equivalent. I presume one could say that the Hangul SC/TC issues fall in that category. A.2. Two different spellings of the same word in the same script and same language, like color/colour. A.3. Same word in the same language in two different scripts (bulgarian) A.4. Same word in two different languages And then there are many A.1.1, A.1.2, A.2.1 etc, and I did even hear today people say "two variants are two different accepted spellings of the same word that _sound_ the same". I do not even know where to put that. But one thing I because of that think should be done, and could be done, by people is to list all different "variants" they can come up with... The one draw the line, what is and what is not? Is the line drawn at A.1.1232 or A.2.56? Ok, given we have some agreement on what is a variant and not, we have to discuss what implications it has. I here also see a number of different questions to be answered. For example: B.1. Should an application with more TLDs than one be counted as one application if the TLDs in the application are variants of each other? And if so, should there be only one fee per application? B.2. Should two different variants be able to be managed by two different registries or not, and if not, what should happen with the variants? One primary and others like the bundling tactics in some TLDs (i.e. choice between "yes delegation" or "just block for other to register")? And then there might be a technical question in there... C.1. Given two domain names are variants of each other, is there something that can be done in the DNS from a technical point of view to express that, or can we only do delegations? The really tricky question is of course to really draw the line between variants and not variants. I think the line from a technical point of view, AND the implications on the second questions, should be for the new TLD approval process be as conservative as possible. Default answer: If someone want two domain names, just send in two applications. Exception: As you desperately need both and not only one of the domain names, you will get both treated as one application. Then ICANN ask IETF formally "can you please let us know if it is possible to have some kind of solution for _technically_ link two TLDs with each other, in a safe and stable way". Via a letter to IAB. Until and if IETF give such a solution, ICANN only have the following two alternatives for the ones that do get two variants approved: 1. Get both delegated 2. Get one delegated and the other blocked Then MAYBE there will be a third option: 3. Get both with some alias solution But these are things which are implications given a definition on what "variants" are, and that discussion is in the future -- although I am pretty sure some parties really would like to have certain solutions to the problem... Patrik

15 35

Suggested meta-questions to think about
by Dr.Sarmad Hussain June 24, 2011

June 24, 2011

Dear All, I posted this to Arabic-vip list, but as the discussion is getting language specific on the general list, this may also be useful here. Apologies for cross-posting for those who have already received it. regards, Sarmad ---------- Forwarded message ---------- From: Dr.Sarmad Hussain <sarmad(a)cantab.net> Date: Tue, Jun 21, 2011 at 10:01 AM Subject: Re: [vip] Suggested meta-questions to think about To: arabic-vip(a)icann.org Taking Patrik's enumeration forward, here is a tentative list for Arabic, for further discussion: A1.1.1 Unicode code points having same shape in at least one of the four forms (beginning, middle, final and isolated) A1.1.2 composed and decomposed forms not covered through Unicode which are exactly same A1.2.1 Unicode code points have shape similar enough that user will get confused and accept them equal (causing security threat, e.g. phishing) A1.2.1.1 similar shapes A1.2.1.2 similar marks A1.2.2 composed and decomposed forms same enough to cause user confusion (causing security threat, e.g. phishing) A1.3.1 conflating level 2 marks (less significance, higher optionality) (e.g. fatha) A1.3.2 conflating level 1 marks (higher significance, lower optionality) (e.g. hamza above/below) A1.3.3 conflating level 0(?) marks (highest significance, no optionality) (e.g. double-fatha) (could this be A 2.1?) Interestingly, it can be argued that A1.3.x is a label level variance instead of character level variance, which is an interesting concept, but is not quite similar to A.2 suggested below but somewhere in between A.1 and A.2, as Arabic writing system (Abjad) works differently in some ways that Alphabetical systems like Latin. AX 1.1 There is also label level variance in a few cases, where technically ZWNJ is licensed by protocol (and should be licensed in spirit) but the changed shape is so slightly different that it is not perceptible and may cause security threats (e.g. phishing). I would draw the line before A.2 for variants. regards, Sarmad 2011/6/19 Patrik Fältström <patrik(a)frobbit.se> > Hi, I am sending this as an interested individual, and not as SSAC Chair... > > I have a few times this weekend already tried to explain my view on > "variants", and after doing that in a chat, I felt it start to (for me) make > sense, so I wanted to share with you. > > We have, I think, a problem divided in two different questions. And > unfortunately many people think of the solution only the form of "answers to > the second question". Let me try to explain. > > First, whether something is a variant or not (note: word is undefined), is > actually a grayscale from "yes" to "no". There are various shades of gray > there. For example: > > A.1. Two characters in Unicode really are to be treated as being > equivalent. I presume one could say that the Hangul SC/TC issues fall in > that category. > A.2. Two different spellings of the same word in the same script and same > language, like color/colour. > A.3. Same word in the same language in two different scripts (bulgarian) > A.4. Same word in two different languages > > And then there are many A.1.1, A.1.2, A.2.1 etc, and I did even hear today > people say "two variants are two different accepted spellings of the same > word that _sound_ the same". I do not even know where to put that. > > But one thing I because of that think should be done, and could be done, by > people is to list all different "variants" they can come up with... > > The one draw the line, what is and what is not? Is the line drawn at > A.1.1232 or A.2.56? > > Ok, given we have some agreement on what is a variant and not, we have to > discuss what implications it has. I here also see a number of different > questions to be answered. For example: > > B.1. Should an application with more TLDs than one be counted as one > application if the TLDs in the application are variants of each other? And > if so, should there be only one fee per application? > B.2. Should two different variants be able to be managed by two different > registries or not, and if not, what should happen with the variants? One > primary and others like the bundling tactics in some TLDs (i.e. choice > between "yes delegation" or "just block for other to register")? > > And then there might be a technical question in there... > C.1. Given two domain names are variants of each other, is there something > that can be done in the DNS from a technical point of view to express that, > or can we only do delegations? > > The really tricky question is of course to really draw the line between > variants and not variants. I think the line from a technical point of view, > AND the implications on the second questions, should be for the new TLD > approval process be as conservative as possible. > > Default answer: If someone want two domain names, just send in two > applications. > > Exception: As you desperately need both and not only one of the domain > names, you will get both treated as one application. > > Then ICANN ask IETF formally "can you please let us know if it is possible > to have some kind of solution for _technically_ link two TLDs with each > other, in a safe and stable way". Via a letter to IAB. > > Until and if IETF give such a solution, ICANN only have the following two > alternatives for the ones that do get two variants approved: > > 1. Get both delegated > > 2. Get one delegated and the other blocked > > Then MAYBE there will be a third option: > > 3. Get both with some alias solution > > But these are things which are implications given a definition on what > "variants" are, and that discussion is in the future -- although I am pretty > sure some parties really would like to have certain solutions to the > problem... > > Patrik > > >

1 0

Re: [vip] VIP working sessions in Singapore
by Vladimir Shadrunov June 18, 2011

June 18, 2011

Thanks a lot to the organisers and participants of the VIP meetings today. It was nice to see you all and it was really a mind stimulating experience being at the beginning of a massive process such as IDN Variants :-) May I ask those who presented on Adobe Connect today to circulate their presentations on this list. I saw a number of useful links that I wasn't able to capture on the fly. Thanks and wish you all a fruitful ICANN meeting! Best regards, Vladimir Shadrunov

1 0

IDN Variant TLD Case Study Update
by Francisco Arias June 10, 2011

June 10, 2011

Dear all, Team members composition for all case studies has been announced: http://www.icann.org/en/announcements/announcement-3-09jun11-en.htm Regards, __ Francisco P.S. This (vip(a)icann.org) is the list where all the case studies members are subscribed. This list is open for subscription to anyone.

1 0

test
by Dennis Jennings June 4, 2011

June 4, 2011

Test -- ------------------------------------------------------------------------ Dr. Dennis Jennings, Managing Director, Knous Limited www.knous.ie <http://www.knous.ie/> _Dennis.Jennings(a)knous.ie_ <mailto:Dennis.Jennings@ICANN.org> Registered in Ireland No. 477218 Mobile: +353 87 220 8225 VAT No.IE 9726842D Home Office: +353 1 269 5475** Please note new number Directors: Skype: DennisJennings D.M. Jennings (Managing), D. Fitzmaurice ------------------------------------------------------------------------

1 0