May 2013 - ispcp - lists.icann.org

Meting Invitation/ ISPCP Call / 10 September 2012 at 1400 UTC
by Gisella Gruber Aug. 11, 2013

Aug. 11, 2013

Dear All, Please note that the next ISPCP call is scheduled on Monday 10 September 2012 at 1400 UTC. To check your local time: http://tinyurl.com/8b9yr7a Please find the dial-in details below: Participant Passcode: Participant: 3429 # Dial-in numbers: http://www.adigo.com/icann/ Thank you. Kind regards, Gisella ----------------- Gisella Gruber GNSO Secretariat Staff Internet Corporation for Assigned Names and Numbers (ICANN) Email: gisella.gruber(a)icann.org<mailto:gisella.gruber@icann.org> Tel: +44 7545 334 360 Skype ID: gisella.gw

7 24

ISPCP comments on the FY14 Budget
by Mike O'Connor May 30, 2013

May 30, 2013

The ISPCP welcomes the opportunity to comment on the FY14 Draft Operating Plan and Budget. Our comments (approved by the constituency via email on 30-May, 2013) are attached. Best regards, Mike O'Connor -- Rapporteur

1 0

Trouble Ahead: IDN Variants
by Mike O'Connor May 29, 2013

May 29, 2013

hi all, i took out of our recent phone call was 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. here's a link to the full report -- issued in March https://www.icann.org/en/resources/idn/variant-tlds/active-ux-21mar13-en.pdf 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. 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. 5. Challenges Related to Active Variant TLDs........................................................................ 28 5.1. Challenges with the Use of Variants............................................................................. 28 • 5.1.1. Different Users cannot find the complete set of variants for a primary label....... 29 • 5.1.2. Variants not intuitive............................................................................................. 29 • 5.1.3. Variants delegated independently ......................................................................... 29 • 5.1.4. Variants defined inconsistently............................................................................. 30 • 5.1.5. Variants displayed inconsistently ......................................................................... 30 • 5.1.6. Variants cannot be input by the user..................................................................... 30 • 5.1.7. Unable to distinguish specific variants ................................................................. 30 • 5.1.8. Identifier not bound to all variants........................................................................ 31 • 5.1.9. Accessibility and privacy impacted ...................................................................... 31 • 5.1.10. Variants not searchable ......................................................................................... 31 • 5.1.11. Search rankings unpredictable .............................................................................. 32 • 5.1.12. Search optimization affected by variants .............................................................. 32 • 5.1.13. Variants not part of URL/URI/IRI ........................................................................ 32 • 5.1.14. Variants cause session re-establishment ............................................................... 32 5.2. Challenges in the Registration and Management of Variants....................................... 33 • 5.2.1. Management across IDN TLDs inconsistent ........................................................ 33 • 5.2.2. Registration for SLDs across TLDs inconsistent.................................................. 34 • 5.2.3. Inconsistent association of ASCII domain name and IDN TLDs......................... 34 • 5.2.4. Software support inadequate................................................................................. 34 • 5.2.5. Registration system not straightforward to localize.............................................. 35 • 5.2.6. Registration information inconsistent ................................................................... 35 • 5.2.7. Trademark protection tracking complex ............................................................... 35 • 5.2.8. Trademark protection dispute process complex ................................................... 36 5.3. Challenges in the Configuration and Diagnostics of Variants...................................... 36 • 5.3.1. Software configuration not supported................................................................... 36 • 5.3.2. Cannot associate variants for configuration.......................................................... 37 • 5.3.3. Compounded certificate management................................................................... 37 • 5.3.4. DNSSEC validation inconsistent .......................................................................... 37 • 5.3.5. Log and history searching does not match............................................................ 38 • 5.3.6. Network traffic statistics incomplete .................................................................... 38 • 5.3.7. Caching infrastructure inefficient ......................................................................... 39 • 5.3.8. Diagnostic and troubleshooting tools incompatible.............................................. 39 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. 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? 6. Recommendations ............................................................................................................... 40 6.1. Recommendations to ICANN ....................................................................................... 41 6.1.1. ICANN must implement a well defined and conservative variant TLD allocation process .............................................................................................................................. 41 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 6.1.3. ICANN must develop, to the extent possible, minimal, simple and consistent LGR for the root zone..................................................................................................................... 42 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 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 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 6.1.7. ICANN should create educational materials on the use and impact of variants for different user communities .................................................................................................... 45 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 6.1.9. ICANN should develop consistent registration data requirements for variants at root and other levels .............................................................................................................. 46 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 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 and here's all the stuff that registries are supposed to do... 6.2. Recommendations to a Registry that Offers IDNs for Scripts that have Variants........ 47 6.2.1. Registry should not register any second-level variant labels unless the label registration request has met all approval requirements ......................................................... 47 6.2.2. Registry that supports variants must make its updated LGR available to ICANN and the community ................................................................................................................ 48 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 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 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 6.2.6. Registry offering variants should require relevant registrars to support IDN variants across their registration platforms............................................................................ 49 and a list for registrars 6.3. Recommendations to a Registrar that Supports the Registration of Variants............... 50 6.3.1. Registrar must update its practice to address requirements specific to the registration of IDN variants ................................................................................................... 50 6.3.2. Registrar should extend linguistic and technical support of IDN variants for registrants .............................................................................................................................. 50 • 6.3.3. Registrar must support IDN variants across their registration platforms ............. 50 • 6.3.4. Registrar must support registry policies and associated services for collecting and managing registration data of IDN variants .......................................................................... 51 6.3.5. Registrar that supports the registration of variants may also update any related services that are impacted by variants ................................................................................... 51 and the "technical community" -- these recommendations largely fall in the "magical thinking" category for me. 6.4. Recommendations to the Technical Community.......................................................... 51 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 6.4.2. Software intended for Internet end users—such as web browsers, email clients, and operating systems—should support variants to the extent necessary to ensure a positive user experience ...................................................................................................................... 52 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 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. 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. mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

Motion on uniformity of reporting
by WUKnoben May 16, 2013

May 16, 2013

Motion passed unanimously today at the GNSO council meeting Best regards Wolf-Ulrich

2 1

FW: [liaison6c] Call for Volunteers: Drafting Team to Develop Charter for GNSO Working Group on Policy & Implementation
by Tony Holmes May 14, 2013

May 14, 2013

Volunteer(s) from the ISPCP would be appreciated. We really should engage on this. Thanks Tony From: owner-liaison6c(a)gnso.icann.org [mailto:owner-liaison6c@gnso.icann.org] On Behalf Of Glen de Saint Géry Sent: 13 May 2013 23:31 To: liaison6c Subject: [liaison6c] Call for Volunteers: Drafting Team to Develop Charter for GNSO Working Group on Policy & Implementation http://gnso.icann.org/en/announcements/announcement-09may13-en.htm 9 May 2013 In Brief The Generic Names Supporting Organization (GNSO) Council seeks volunteers to serve on a Drafting Team that will be tasked to develop a charter for a Working Group to address issues that have been raised in the context of the recent discussions on policy & implementation that affect the GNSO (see <http://gnso.icann.org/en/correspondence/policy-implementation-framework-08j an13-en.pdf> Staff Discussion Paper and <http://beijing46.icann.org/node/37133> session in Beijing). The Drafting Team is expected to submit the proposed Charter to the GNSO Council for approval. What This Team Will Do The Drafting Team is expected to develop a Charter on the basis of the <http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-08apr11-en.pdf> GNSO Working Group Guidelines taking into account the Staff Discussion Paper as well as the discussions that took place in Beijing. At a minimum, the GNSO Council expects that the subsequent Working Group would provide recommendations on the following: 1. A set of principles that would underpin any GNSO policy / implementation related discussions 2. Recommendations on a process for providing GNSO "Policy Guidance" 3. A framework for implementation related discussions related to GNSO Policy Recommendations and 4. Further guidance on how GNSO Implementation Review Teams are expected to function and operate. How This Team Will Work ICANN Working Groups use transparent, open processes. The meetings of this DT will be recorded, and the recordings will be available to the public. The mailing list for the Drafting Team will be archived publicly. Drafting Team members are expected to submit Statements of Interest (SOI). The group will collaborate using a public workspace. The Drafting Team is expected to follow the <http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-08apr11-en.pdf> GNSO Working Group Guidelines. How to Join The GNSO Council invites interested parties to provide names of expected participants who can then be added to the DT mailing list. The DT will be open to anyone interested to join. Community members who wish to be invited to join the group should contact the <mailto:gnso.secretariat@icann.org?subject=Application%20to%20Join%20Policy% 20%26%20Implementation%20DT> GNSO secretariat ( <mailto:gnso.secretariat@icann.org> gnso.secretariat(a)icann.org) Background Mainly as a result of discussions stemming from implementation related issues of the new gTLD program, there is increased focus on which topics call for policy and which call for implementation work, including which processes should be used, at what time and how diverging opinions should be acted upon. In order to facilitate these discussions, ICANN Staff developed a draft framework for community discussion that identifies a number of steps and criteria that might facilitate dealing with similar questions in the future. The paper identifies a number of questions that the community may want to consider further in this context, as well as a couple of suggested improvements that could be considered in the short term. While developing a bright-line rule as to what is policy or implementation may not be possible, the hope is that by developing clear processes and identifying clear roles and responsibilities for the different stakeholders, it will become easier to deal with these issues going forward and allow for broad participation and involvement. Following several discussions by the GNSO Council on this topic, the GNSO Council has now decided to form a drafting team to draft a Charter for a Working Group which will be tasked to provide concrete recommendations on how to address some of these issues from a GNSO perspective. Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

3 3

PERSONAL Comment on the FY14 Buget from Mikey O'Connor
by Mike O'Connor May 13, 2013

May 13, 2013

hi all, i just submitted this PERSONAL comment on the budget to ICANN, in order to give the Budget folks time to think about them prior to a budget-review call which is coming up later this week. we, the ISPCP may want to make a comment as well, once we've heard what the budget staff have to say. i've highlighted some broad strategic issues, in addition to some nitpicking -- including what i think is a $4million arithmetic error in their projections. mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

1 0

DOODLE - next ISPCP call
by Gisella Gruber May 13, 2013

May 13, 2013

Dear All, I hope this email finds you all well after the Beijing meeting. Please complete the attached Doodle poll to schedule the next ISPCP call. http://www.doodle.com/hkm7ahw6fxaa44v3 Thank you! Kind regards, Gisella

1 0

ICANN Engagement Center
by WUKnoben May 10, 2013

May 10, 2013

Osvaldo, congratulations to Uruguay for this important step. Best regards Wolf-Ulrich

2 1

RV: [gnso-igo-ingo] Topic #3 - IGO-INGO Equivalent Standing for Objections
by Novoa, Osvaldo May 9, 2013

May 9, 2013

All, We seem to be getting to the end of this matter, but I need your opinion on the questions posted by Berry Cobb. In general there was no support to waive the fees of the TMCH fro the IGO and INGO. With respect to these specific questions: 1.- I don't have the background on the GAC and ALAC standing for filing objections, though I understand the reason for GAC's. I would support waiving the fees for the qualifying IGOs and INGOs. 2.- The same 3.- I don't understand the question, maybe due to some translation issue. It seems to mean that the IGO or INGO that has an objection would have to go through the GAC. If this is the case, it would be a GAC issue and I don't think the GSO or its members would have anything to say about it. Hoping to hear from you, Best regards, Osvaldo ________________________________ De: owner-gnso-igo-ingo(a)icann.org [mailto:owner-gnso-igo-ingo@icann.org] En nombre de Berry Cobb Enviado el: Viernes, 03 de Mayo de 2013 14:36 Para: gnso-igo-ingo(a)icann.org Asunto: [gnso-igo-ingo] Topic #3 - IGO-INGO Equivalent Standing for Objections Hi All, Judging by the responses and the Chair's assessment thus far, it appears that there is not much support for Fee Waivers at the various levels of the protection mechanisms discussed, with the exception at the top-level for future applications of gTLDs. We ask that the WG stakeholders respond to the following questions in the context that an organization's identifiers would not be placed on a reserved names list or listed in the Applicant Guidebook as ineligible for registration: 1. Is there support for IGO, IOC, and RCRC to have equivalent standing similar to the GAC and ALAC for filing objections against top-level applications for gTLDs? (Note that there is no charge of a filing fee for that GAC and ALAC) 2. If there is no support for equivalent standing, is there support for a fee reduction for filing objections to new gTLD applications by IGO, IOC, and RCRC? 3. If there is no support for either concept, what are your thoughts about the organizations seeking protection to collaborate with the GAC for gTLD applications where an objection is being considered? We will discuss this topic at our 8 May 2013 conference call. Thank you for your input. B Berry Cobb Internet Corporation for Assigned Names & Numbers (ICANN) 720.839.5735 mail(a)berrycobb.com<mailto:mail@berrycobb.com> @berrycobb ________________________________ El presente correo y cualquier posible archivo adjunto est? dirigido ?nicamente al destinatario del mensaje y contiene informaci?n que puede ser confidencial. Si Ud. no es el destinatario correcto por favor notifique al remitente respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los posibles archivos adjuntos al mismo de su sistema. Est? prohibida cualquier utilizaci?n, difusi?n o copia de este e-mail por cualquier persona o entidad que no sean las espec?ficas destinatarias del mensaje. ANTEL no acepta ninguna responsabilidad con respecto a cualquier comunicaci?n que haya sido emitida incumpliendo nuestra Pol?tica de Seguridad de la Informaci?n This e-mail and any attachment is confidential and is intended solely for the addressee(s). If you are not intended recipient please inform the sender immediately, answering this e-mail and delete it as well as the attached files. Any use, circulation or copy of this e-mail by any person or entity that is not the specific addressee(s) is prohibited. ANTEL is not responsible for any communication emitted without respecting our Information Security Policy.

3 2