<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">hi Wolf-Urich,<div><br></div><div>i'm absolutely willing to help.</div><div><br></div><div>here's a repeat of my "trouble ahead" post from a while back. i think the one sentence summary is this;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>the current IDN variant plan calls for shifting quite a lot of work (and risk) away from ICANN -- and that is unlikely to work</div><div><br></div><div>mikey</div><div><br></div><div><blockquote type="cite">hi all,<br><br>i took an action out of our recent phone call to bring your attention to the IDN Variant "user experience" report that was issued in March and lightly discussed at a meeting in Beijing. so here's a little email to whet your appetite. this is posted to the public list because i kinda want this cry of alarm to be heard pretty widely.<br><br>here's a link to the full report -- issued in March<br><br><span class="Apple-tab-span" style="white-space: pre; "> </span><a href="https://www.icann.org/en/resources/idn/variant-tlds/active-ux-21mar13-en.pdf">https://www.icann.org/en/resources/idn/variant-tlds/active-ux-21mar13-en.pdf</a><br><br>i've chopped in just the table of contents from Chapter 5 of the report. i *STRONGLY* urge you all to read the detail of that chapter -- as an ISP who's likely to be getting calls about these things, my jaw drops. <br><br>just one example. let's say that your username is an email address at a service provider. let's not pick on Facebook, let's think about somebody smaller like maybe Mikey's Pretty Good ISP where you go for your connectivity plus a few related services like email and maybe some hosting services. so your expectation is that your email address will work in both its ASCII form *and* any number of IDN variant forms?? that's what's being proposed. but but
they're separate strings, you say. validation on the different string will fail, but the expectation is that it shouldn't. there are many more similar issues described in this chapter.<br><br><br>5. Challenges Related to Active Variant TLDs........................................................................ 28 <br><br>5.1. Challenges with the Use of Variants............................................................................. 28<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.1. Different Users cannot find the complete set of variants for a primary label....... 29<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.2. Variants not intuitive............................................................................................. 29<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.3. Variants delegated independently ......................................................................... 29<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.4. Variants defined inconsistently............................................................................. 30<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.5. Variants displayed inconsistently ......................................................................... 30<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.6. Variants cannot be input by the user..................................................................... 30<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.7. Unable to distinguish specific variants ................................................................. 30<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.8. Identifier not bound to all variants........................................................................ 31<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.9. Accessibility and privacy impacted ...................................................................... 31<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.10. Variants not searchable ......................................................................................... 31<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.11. Search rankings unpredictable .............................................................................. 32<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.12. Search optimization affected by variants .............................................................. 32<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.13. Variants not part of URL/URI/IRI ........................................................................ 32<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.1.14. Variants cause session re-establishment ............................................................... 32<br><br>5.2. Challenges in the Registration and Management of Variants....................................... 33<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.1. Management across IDN TLDs inconsistent ........................................................ 33<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.2. Registration for SLDs across TLDs inconsistent.................................................. 34<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.3. Inconsistent association of ASCII domain name and IDN TLDs......................... 34<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.4. Software support inadequate................................................................................. 34<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.5. Registration system not straightforward to localize.............................................. 35<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.6. Registration information inconsistent ................................................................... 35<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.7. Trademark protection tracking complex ............................................................... 35<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.2.8. Trademark protection dispute process complex ................................................... 36<br><br>5.3. Challenges in the Configuration and Diagnostics of Variants...................................... 36<br><br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.1. Software configuration not supported................................................................... 36<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.2. Cannot associate variants for configuration.......................................................... 37<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.3. Compounded certificate management................................................................... 37<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.4. DNSSEC validation inconsistent .......................................................................... 37<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.5. Log and history searching does not match............................................................ 38<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.6. Network traffic statistics incomplete .................................................................... 38<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.7. Caching infrastructure inefficient ......................................................................... 39<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 5.3.8. Diagnostic and troubleshooting tools incompatible.............................................. 39<br><br><br><br>but what REALLY gets me going is Chapter Six where the recommendations are laid out. some of the problems described in Chapter 5 don't seem possible to solve at all, no matter who does the solving. <br><br>and look at all the stuff that **ICANN** is supposed to do to make these things work. to use Dennis Jennings' analogy -- the problems described in Chapter 5 imply that these things just won't work -- sort of like an airplane constructed with the curved part of the wing on the bottom, which just won't fly. why/how is *ICANN* supposed to work this miracle? <br><br><br><br>6. Recommendations ............................................................................................................... 40 <br><br>6.1. Recommendations to ICANN ....................................................................................... 41<br>6.1.1. ICANN must implement a well defined and conservative variant TLD allocation process .............................................................................................................................. 41<br>6.1.2. ICANN must maintain an LGR repository for the root zone and IDN TLDs and make it available to users and programmatically processable............................................... 41<br>6.1.3. ICANN must develop, to the extent possible, minimal, simple and consistent LGR for the root zone..................................................................................................................... 42<br>6.1.4. To help ensure that users have a more predictable and consistent experience registering and using primary and variant labels, ICANN must develop, to the extent possible, a minimal, simple and consistent life cycle for the variant TLD sets (across languages and scripts)............................................................................................................ 43<br>6.1.5. ICANN must define guidelines to evaluate the competence and readiness of the registry to manage variants, to ensure a stable and secure end user experience ................... 44<br>6.1.6. ICANN should require IDN TLD registries with variants to apply the relevant (script) subset of the root zone LGR and state life cycle for variants across second-level domain labels. Deviations should be justified ....................................................................... 45<br>6.1.7. ICANN should create educational materials on the use and impact of variants for different user communities .................................................................................................... 45<br>6.1.8. ICANN must require any accredited registrar that supports IDNs with TLD and/or SLD variants to support variants across its registration platform ......................................... 46<br>6.1.9. ICANN should develop consistent registration data requirements for variants at root and other levels .............................................................................................................. 46<br>6.1.10. ICANN must convene relevant experts involved in domain name disputes to determine any new issues introduced by variants and update existing dispute resolution processes accordingly ............................................................................................................ 47<br>6.1.11. ICANN must define technical requirements and engage with standards organizations, such as the IETF, to determine how IDN variants should be consistently implemented .......................................................................................................................... 47<br><br><br>and here's all the stuff that registries are supposed to do...<br><br><br>6.2. Recommendations to a Registry that Offers IDNs for Scripts that have Variants........ 47<br>6.2.1. Registry should not register any second-level variant labels unless the label registration request has met all approval requirements ......................................................... 47<br>6.2.2. Registry that supports variants must make its updated LGR available to ICANN and the community ................................................................................................................ 48<br>6.2.3. Registry that supports variants should apply the LGR developed for the root across lower-level domains. Deviations from the LGR should be publicly documented and justified .............................................................................................................................. 48<br>6.2.4. Registry that supports variants should implement, to the extent possible, state life cycle for the second-level variants recommended by ICANN .............................................. 49<br>6.2.5. Registry should create educational materials on the use and impacts of variants for different user communities, such as end users, system administrators, etc........................... 49<br>6.2.6. Registry offering variants should require relevant registrars to support IDN variants across their registration platforms............................................................................ 49<br><br><br>and a list for registrars<br><br><br>6.3. Recommendations to a Registrar that Supports the Registration of Variants............... 50<br>6.3.1. Registrar must update its practice to address requirements specific to the registration of IDN variants ................................................................................................... 50<br>6.3.2. Registrar should extend linguistic and technical support of IDN variants for registrants .............................................................................................................................. 50<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 6.3.3. Registrar must support IDN variants across their registration platforms ............. 50<br><span class="Apple-tab-span" style="white-space: pre; "> </span> 6.3.4. Registrar must support registry policies and associated services for collecting and<br>managing registration data of IDN variants .......................................................................... 51<br>6.3.5. Registrar that supports the registration of variants may also update any related services that are impacted by variants ................................................................................... 51<br><br><br>and the "technical community" -- these recommendations largely fall in the "magical thinking" category for me. <br><br><br>6.4. Recommendations to the Technical Community.......................................................... 51<br>6.4.1. Developers of software tools for the technical community should consider, based on user requirements, enhancing their software to support the administration and management of variants......................................................................................................... 51<br>6.4.2. Software intended for Internet end userssuch as web browsers, email clients, and operating systemsshould support variants to the extent necessary to ensure a positive user experience ...................................................................................................................... 52<br>6.4.3. To provide end users with a consistent and predictable experience with variants across software applications, developers should, to the extent possible, publicly share best practices and emerging standards in terminology and functionality ..................................... 52<br><br><br>i really urge you to read these two chapters -- i can't figure out how the stuff they're proposing will solve the puzzles and are being described. the problem is, none of us have been paying attention and this pile of contradictions isn't getting challenged. i think we really need to step into this conversation from the ISPCP point of view and point out that if these things are really seriously broken, we're going to take the brunt of the calls and eventually start considering some really unpalatable and unpopular actions. <br><br>enough for a starting-point rant. i'd love to hear your views/reactions. at a minimum, i think it would be great to have Dennis Jennings and somebody from the IDN team come and have a little debate during our meeting in Durban.<br><br>mikey<br><div><div><div>On Jun 26, 2013, at 6:39 AM, WUKnoben <<a href="mailto:wolf-ulrich.knoben@t-online.de">wolf-ulrich.knoben@t-online.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div style="font-size: 12pt; font-family: Calibri; ">
<div>I think a while ago we tried starting to disuss the implications of active
variant TLDs on ISP related activities.</div>
<div>The item was picked up at the last council meeting. It was requested that
the respective SGs/Consts should provide comments on the analysis prepared by
staff (<a href="http://www.icann.org/en/groups/board/documents/prelim-report-11apr13-en.htm#2.a"><font face="Times New Roman">http://www.icann.org/en/groups/board/documents/prelim-report-11apr13-en.htm#2.a</font></a>)
with focus on the following questions:</div>
<div> </div><div style="margin: 0cm 0cm 0pt 53.45pt; text-indent: -18pt; "><span lang="EN-US" style="FONT-FAMILY: ; mso-fareast-font-family: arial; mso-ansi-language: en-us"><span style="mso-list: ignore"><font face="Arial">a)</font><span style="FONT-FAMILY: ; LINE-HEIGHT: normal"><font face="Times New Roman"><font style="FONT-SIZE: 7pt">
</font></font></span></span></span><span lang="EN-US" style="FONT-FAMILY: ; mso-ansi-language: en-us"><font face="Arial">Which
recommendations if any, are pre-requisites to the delegation of any IDN variant
TLDs (i.e., delegation of IDN Variant TLDs should not proceed until these
recommendations are implemented),</font></span></div><div style="margin: 0cm 0cm 0pt 53.45pt; text-indent: -18pt; "><span lang="EN-US" style="FONT-FAMILY: ; mso-fareast-font-family: arial; mso-ansi-language: en-us"><span style="mso-list: ignore"><font face="Arial">b)</font><span style="FONT-FAMILY: ; LINE-HEIGHT: normal"><font face="Times New Roman"><font style="FONT-SIZE: 7pt">
</font></font></span></span></span><span lang="EN-US" style="FONT-FAMILY: ; mso-ansi-language: en-us"><font face="Arial">Which
recommendations, if any, can be deferred until a later time,
and</font></span></div><div style="margin: 0cm 0cm 0pt 53.45pt; text-indent: -18pt; "><span lang="EN-US" style="FONT-FAMILY: ; mso-fareast-font-family: arial; mso-ansi-language: en-us"><span style="mso-list: ignore"><font face="Arial">c)</font><span style="FONT-FAMILY: ; LINE-HEIGHT: normal"><font face="Times New Roman"><font style="FONT-SIZE: 7pt">
</font></font></span></span></span><span lang="EN-US" style="FONT-FAMILY: ; mso-ansi-language: en-us"><font face="Arial">Which
recommendations, if any, require additional policy work by the ICANN community
and should be referred to the relevant stakeholder group for further policy
work</font></span></div>
<div style="font-size: 12pt; font-family: Calibri; "> </div>
<div style="font-size: 12pt; font-family: Calibri; ">If I recall
correctly then Mikey provided already some comments. Id like to join this
effort and would encourage others to do so but would like to find those basics
from Mikey who Im sure would help??<br><br>Best
regards<br><br>Wolf-Ulrich<br><br></div></div></div></div>
</blockquote></div><br></div></blockquote><div><div apple-content-edited="true">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com">www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)</span>
</div>
<br></div></div></body></html>