- ispcp - lists.icann.org

Protection of IGO INGO identifiers in all gTLDs
by Novoa, Osvaldo June 12, 2013

June 12, 2013

Hi all, I am enclosing the preliminary report from the PDP Working Group. The intention is to publish it as soon as possible and right now we are discussing the final amendments. Best regards, Osvaldo ________________________________ 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.

1 0

RV: [council] Discussion Item: Changes to ICANN Bylaws
by Novoa, Osvaldo June 10, 2013

June 10, 2013

Dear All, I personally support Jeff Neuman's proposal. Is there support for it in our community? Best regards, Osvaldo ________________________________ De: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] En nombre de Volker Greimann Enviado el: Lunes, 10 de Junio de 2013 08:27 Para: Neuman, Jeff CC: 'GNSO Council (council(a)gnso.icann.org)' Asunto: Re: [council] Discussion Item: Changes to ICANN Bylaws I would also support such a motion. The suggested language keeps the door for alternative processes open while shutting the door for a complete bypass without accountability. Best, Volker All, In the rationale used in the BGC's recommendation against the NCSG's Reconsideration Request, the BGC argues that: "There is no defined policy process within ICANN that requires Board or staff consultation with the GNSO Council if the Board or staff is acting in contravention to a statement made by the GNSO Council outside of the Policy Development Process. Therefore, even if staff's action here was in direct contravention to the GNSO Council statement in a letter, the Bylaws requirement for consultation does not apply..." Technically and legally, the BGC is correct. As much as this goes against the very nature of the multi-stakeholder model (and frankly the message ICANN delivers to the world), the ICANN Board/staff is free to ignore the GNSO Council (and thus has no accountability for these actions). This is true despite the fact that the Bylaws also state: "There shall be a policy-development body known as the Generic Names Supporting Organization (GNSO), which shall be responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains." Therefore, what the BGC is telling us is that despite the fact that the Bylaws charges the GNSO with developing and recommending substantive policies, it can ignore the GNSO community at any time if the issue did not go through a formal PDP. I personally believe that is broken. Therefore, I would like for the Council to consider recommending to the ICANN Board a change to the Bylaws for an additional measure of accountability that at a minimum would require some form of consultation if the GNSO Council (on behalf of the GNSO Community) issues a recommendation or develops policy outside of a formal PDP. As the former chair of the PDP Working Group that helped revise the PDP process, I can tell you that we were encouraged by the community to allow other mechanisms for developing policy outside of formal PDPs. We spent countless hours on this very topic. Yes, if it does not go through a formal PDP, it may not trigger a 2/3 Board vote to overturn the recommendation, but it was never our intention that after going through that process, the Board to IGNORE the GNSO Community. At a time when the community is trying to find ways to develop policies outside of the stringent PDP, this is NOT an incentive for doing that. Therefore, I would like to see the following changes made to the Bylaws (no pride in authorship here...so feel free to suggest other words). This is language that is VERY similar to the language the GAC has in the Bylaws: The substantive policies and recommendations of the Generic Names Supporting Organization relating to generic top-level domains shall be duly taken into account, both in the formulation and adoption of policies, whether or not the policy development process as set forth in Article X, section 6 were followed. In the event that the ICANN Board determines to take an action that is not consistent with the GNSO policies or recommendations, it shall so inform the GNSO and state the reasons why it decided not to follow that advice. The GNSO and the ICANN Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution. If no such solution can be found, the ICANN Board will state in its final decision the reasons why the GNSO recommendations or policies were not followed. If the multi-stakeholder model truly has any meaning, I view these changes as non-controversial and essential to preserve what so many have so long been advocating. Thanks. Jeffrey J. Neuman Neustar, Inc. / Vice President, Business Affairs 46000 Center Oak Plaza, Sterling, VA 20166 Office: +1.571.434.5772 Mobile: +1.202.549.5079 Fax: +1.703.738.7965 / jeff.neuman(a)neustar.biz<mailto:jeff.neuman@neustar.biz> / www.neustar.biz<http://www.neustar.biz/> ________________________________ 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.

2 1

Re: [Ispcp-private] Draft agenda for todays call at 14.00 UTC
by Novoa, Osvaldo June 5, 2013

June 5, 2013

Thank you, I'm on the line now. Regards, Osvaldo El 05/06/2013, a las 10:08, "alain.bidron(a)orange.com<mailto:alain.bidron@orange.com>" <alain.bidron(a)orange.com<mailto:alain.bidron@orange.com>> escribió: Participant: 3429 # -----Message d'origine----- De : Ispcp-private [mailto:ispcp-private-bounces@bgnws.com] De la part de Novoa, Osvaldo Envoyé : mercredi 5 juin 2013 16:05 À : Tony Holmes Cc : ispcp-private(a)server.haven2.com<mailto:ispcp-private@server.haven2.com> Objet : Re: [Ispcp-private] Draft agenda for todays call at 14.00 UTC Tony, I am ready for the call but don't have the pass code for the adigo conference. Could you send it to me. Regards, Osvaldo El 05/06/2013, a las 05:17, "Tony Holmes" <tonyarholmes(a)btinternet.com<mailto:tonyarholmes@btinternet.com><mailto:tonyarholmes@btinternet.com>> escribió: Agenda · Update on arrangements for Durban · Agenda items for CSG session Durban · Agenda items for ISPCP mtg Durban · Operating plan and budget · Issues for June 13 GNSO council mtg · AoB · Date of next call Please add any additional items and circulate to the list. Tony _______________________________________________ Ispcp-private mailing list Ispcp-private(a)bgnws.com<mailto:Ispcp-private@bgnws.com><mailto:Ispcp-private@bgnws.com> http://bgnws.com/mailman/listinfo/ispcp-private ________________________________ 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. _______________________________________________ Ispcp-private mailing list Ispcp-private(a)bgnws.com<mailto:Ispcp-private@bgnws.com> http://bgnws.com/mailman/listinfo/ispcp-private _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you. ________________________________ 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.

1 0

ATRT2 discussion
by Tony Holmes June 4, 2013

June 4, 2013

All Alice Jansen has kindly circulated a doodle poll for the discussion between the CSG Constituencies and the ATRT 2 team at - <http://www.doodle.com/2ckehd6qtdk85dn5> http://www.doodle.com/2ckehd6qtdk85dn5 Could you please complete ASAP Thanks Tony

1 0

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