December 2013 - council - lists.icann.org

what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
by Mike O'Connor Jan. 14, 2014

Jan. 14, 2014

dear all, i would like to introduce a gap-closing proposal for the GNSO -- namely, to take a hard look at SSAC reports and determine whether any of their recommendations bear on GNSO Consensus Policy. this gap between what the SSAC says and the GNSO does has been an issue for me for quite some time, and i think one easy way to close it would be to routinely take up each SSAC report and make that determination. there would likely be cases where we review the reports among the stakeholder groups and conclude that: -- there are NO recommendations that require PDPs -- there ARE recommendations that require PDPs, or -- there are recommendations that we would like to know more about before we decided whether a PDP is in order. i'll give an example of the reason why this is on my mind. in 2005 the SSAC produced an extensive report that addressed the issue of domain-name hijacking. in 2011, six years later, the members of the IRTP-B working group stumbled across the following observation in that ancient report and realized that it would be a good idea Collect emergency contact information from registrants, registrars, and resellers for parties who are suited to assist in responding to an urgent restoration of domain name incident. Define escalation processes (emergency procedures) that all parties agree can be instituted in events where emergency contacts are not available. it took six years for that very common-sense idea to find it's way into Consensus Policy. and it probably took another year or two to implement. and it was all practically by accident. what if we: -- discuss this "formally review SSAC reports" idea with our stakeholders and on the Council list for a while -- put an agenda item on our next call to share what we've heard and test a way forward -- get started, presuming nobody thinks this is a horrible idea i've attached the recommendations from the three (count 'em, three) SSAC reports that were released in Buenos Aires. just to give you an idea of the substantive reports that the SSAC is producing. i think it would be really helpful to run these through a process to decide which, if any, of these recommendations warrant action via PDP. there are plenty more SSAC reports to review in the backlog. thanks, mikey SAC061: SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf Recommendation 1: SSAC reiterates its recommendation from SAC055: The ICANN Board should explicitly defer any other activity (within ICANN’s remit) directed at finding a ‘solution’ to ‘the WHOIS problem’ until the registration data policy has been developed and accepted in the community. The EWG should clearly state its proposal for the purpose of registration data, and focus on policy issues over specific implementations. Recommendation 2: The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process. Recommendation 3: SSAC recommends that the EWG state more clearly its positions on the following questions of data availability: A. Why is a change to public access justified? This explanation should describe the potential impact upon ordinary Internet users and casual or occasional users of the directory service. B. Does the EWG believe that access to data currently accessible in generic Top Level Domain (gTLD) WHOIS output should become restricted? If so, what fields and to what extent exactly? Under the EWG proposal, queries from non- authenticated requestors would return only “public data available to anyone, for C. Should all gTLD registries be required to provision their contact data into the Aggregated Registration Data Service (ARDS)? There may be jurisdictions that prohibit by law the export of personally identifiable information outside the jurisdiction. If so, the ARDS may not be a viable way to deliver data accuracy and compliance across all gTLDs. D. Does the EWG propose more types of sensitive registration data be provisioned into ARDS than are found in current gTLD WHOIS output? Recommendation 4: The SSAC suggests that the EWG address this recommendation from SAC058: “SSAC Report on Domain Name Registration Data Validation”3: As the ICANN community discusses validating contact information, the SSAC recommends that the following meta-questions regarding the costs and benefits of registration data validation should be answered: • What data elements need to be added or validated to comply with requirements or expectations of different stakeholders? • Is additional registration processing overhead and delay an acceptable cost for improving accuracy and quality of registration data? • Is higher cost an acceptable outcome for improving accuracy and quality? • Would accuracy improve if the registration process were to provide natural persons with privacy protection upon completion of multi-factored validation? SAC062: SSAC Advisory Concerning the Mitigation of Name Collision Risk http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf Recommendation 1: ICANN should work with the wider Internet community, including at least the IAB and the IETF, to identify (1) what strings are appropriate to reserve for private namespace use and (2) what type of private namespace use is appropriate (i.e., at the TLD level only or at any additional lower level). Recommendation 2: ICANN should explicitly consider the following questions regarding trial delegation and clearly articulate what choices have been made and why as part of its decision as to whether or not to delegate any TLD on a trial basis: -- Purpose of the trial: What type of trial is to be conducted? What data are to be collected? -- Operation of the trial: Should ICANN (or a designated agent) operate the trial or should the applicant operate it? -- Emergency Rollback: What are the emergency rollback decision and execution procedures for any delegation in the root, and have the root zone partners exercised these capabilities? -- Termination of the trial: What are the criteria for terminating the trial (both normal and emergency criteria)? What is to be done with the data collected? Who makes the decision on what the next step in the delegation process is? Recommendation 3: ICANN should explicitly consider under what circumstances un-delegation of a TLD is the appropriate mitigation for a security or stability issue. In the case where a TLD has an established namespace, ICANN should clearly identify why the risk and harm of the TLD remaining in the root zone is greater than the risk and harm of removing a viable and in-use namespace from the DNS. Finally, ICANN should work in consultation with the community, in particular the root zone management partners, to create additional processes or update existing processes to accommodate the potential need for rapid reversal of the delegation of a TLD. SAC063: SSAC Advisory on DNSSEC Key Rollover in the Root Zone http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf Recommendations: Recommendation 1: Internet Corporation for Assigned Names and Numbers (ICANN) staff, in coordination with the other Root Zone Management Partners (United States Department of Commerce, National Telecommunications and Information Administration (NTIA), and Verisign), should immediately undertake a significant, worldwide communications effort to publicize the root zone KSK rollover motivation and process as widely as possible. Recommendation 2: ICANN staff should lead, coordinate, or otherwise encourage the creation of a collaborative, representative testbed for the purpose of analyzing behaviors of various validating resolver implementations, their versions, and their network environments (e.g., middle boxes) that may affect or be affected by a root KSK rollover, such that potential problem areas can be identified, communicated, and addressed. Recommendation 3: ICANN staff should lead, coordinate, or otherwise encourage the creation of clear and objective metrics for acceptable levels of “breakage” resulting from a key rollover. Recommendation 4: ICANN staff should lead, coordinate, or otherwise encourage the development of rollback procedures to be executed when a rollover has affected operational stability beyond a reasonable boundary. Recommendation 5: ICANN staff should lead, coordinate, or otherwise encourage the collection of as much information as possible about the impact of a KSK rollover to provide input to planning for future rollovers. PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

6 14

Holiday card (electronic version)
by Glen de Saint Géry Dec. 31, 2013

Dec. 31, 2013

[cid:578EC140-800D-4AE9-B80A-BC051E7CE466]

6 5

new gTLD update
by Bruce Tonkin Dec. 20, 2013

Dec. 20, 2013

Hello All, Please see attached slides from the new gTLD update webinar held on 17 Dec 2013. http://newgtlds.icann.org/en/announcements-and-media/webinars Applicant Update Webinar Date/Time: 17 December 2013, 23:00 - 00:30 UTC General information on the current status of the Program. Topics will include Evaluation, Contracting, Pre-Delegation Testing, Objections & Dispute Resolution, GAC Advice, Name Collision, Trademark Clearinghouse, etc. Regards, Bruce Tonkin

1 0

Re: what about a process to review/evaluate whether SSAC recommendations warrant action by the GNSO
by Mike O'Connor Dec. 20, 2013

Dec. 20, 2013

wow. will you look at that! another terrific resource i'd never heard of before. i imagine this is the first time folks on the Council list are seeing this reply from Patrik, since he's not subscribed. but for those of you who don't already know, Patrik is the Chair of the SSAC. i'll elevate his "Advice to the ICANN Board" link up into this reply post to make sure the rest of you see it https://www.myicann.org/board-advice i agree -- it could be really useful to link the GNSO into this process a bit more proactively. one of the appealing things about that page is that it covers ALAC advice as well. this might also tie into our GAC - GNSO engagement initiative that is under way. this page is still a pilot, but it's promised that a more mature version will be rolled out sometime. this looks like a good starting point for that review-process i'm envisioning. Patrik, have you figured out an automated way to monitor that page? thanks! mikey On Dec 19, 2013, at 11:03 AM, Patrik Fältström <patrik(a)frobbit.se> wrote: > Mikey, > > I think you can/should tie an initiative like this to the new tracking mechanism that is built and tested for the SSAC and ALAC recommendations. > > <https://www.myicann.org/board-advice> > > Patrik Fältström > SSAC Chair > > On 19 dec 2013, at 17:53, Mike O'Connor <mike(a)haven2.com> wrote: > >> dear all, >> >> i would like to introduce a gap-closing proposal for the GNSO -- namely, to take a hard look at SSAC reports and determine whether any of their recommendations bear on GNSO Consensus Policy. >> >> this gap between what the SSAC says and the GNSO does has been an issue for me for quite some time, and i think one easy way to close it would be to routinely take up each SSAC report and make that determination. there would likely be cases where we review the reports among the stakeholder groups and conclude that: >> >> -- there are NO recommendations that require PDPs >> -- there ARE recommendations that require PDPs, or >> -- there are recommendations that we would like to know more about before we decided whether a PDP is in order. >> >> i'll give an example of the reason why this is on my mind. in 2005 the SSAC produced an extensive report that addressed the issue of domain-name hijacking. in 2011, six years later, the members of the IRTP-B working group stumbled across the following observation in that ancient report and realized that it would be a good idea >> >> Collect emergency contact information from registrants, registrars, and resellers for parties who are suited to assist in responding to an urgent restoration of domain name incident. Define escalation processes (emergency procedures) that all parties agree can be instituted in events where emergency contacts are not available. >> >> it took six years for that very common-sense idea to find it's way into Consensus Policy. and it probably took another year or two to implement. and it was all practically by accident. >> >> what if we: >> >> -- discuss this "formally review SSAC reports" idea with our stakeholders and on the Council list for a while >> >> -- put an agenda item on our next call to share what we've heard and test a way forward >> >> -- get started, presuming nobody thinks this is a horrible idea >> >> i've attached the recommendations from the three (count 'em, three) SSAC reports that were released in Buenos Aires. just to give you an idea of the substantive reports that the SSAC is producing. i think it would be really helpful to run these through a process to decide which, if any, of these recommendations warrant action via PDP. there are plenty more SSAC reports to review in the backlog. >> >> thanks, >> >> mikey >> >> >> >> >> SAC061: SSAC Comment on ICANN’s Initial Report from the Expert Working Group on gTLD Directory Services >> >> http://www.icann.org/en/groups/ssac/documents/sac-061-en.pdf >> >> Recommendation 1: SSAC reiterates its recommendation from SAC055: The ICANN Board should explicitly defer any other activity (within ICANN’s remit) directed at finding a ‘solution’ to ‘the WHOIS problem’ until the registration data policy has been developed and accepted in the community. The EWG should clearly state its proposal for the purpose of registration data, and focus on policy issues over specific implementations. >> >> Recommendation 2: The ICANN Board should ensure that a formal security risk assessment of the registration data policy be conducted as an input into the Policy Development Process. >> >> Recommendation 3: SSAC recommends that the EWG state more clearly its positions on the following questions of data availability: >> >> A. Why is a change to public access justified? >> This explanation should describe the potential impact upon ordinary Internet users and casual or occasional users of the directory service. >> >> B. Does the EWG believe that access to data currently accessible in generic Top Level Domain (gTLD) WHOIS output should become restricted? >> If so, what fields and to what extent exactly? Under the EWG proposal, queries from non- authenticated requestors would return only “public data available to anyone, for >> >> C. Should all gTLD registries be required to provision their contact data into the Aggregated Registration Data Service (ARDS)? >> There may be jurisdictions that prohibit by law the export of personally identifiable information outside the jurisdiction. If so, the ARDS may not be a viable way to deliver data accuracy and compliance across all gTLDs. >> >> D. Does the EWG propose more types of sensitive registration data be provisioned into ARDS than are found in current gTLD WHOIS output? >> >> Recommendation 4: The SSAC suggests that the EWG address this recommendation from SAC058: “SSAC Report on Domain Name Registration Data Validation”3: >> As the ICANN community discusses validating contact information, the SSAC recommends that the following meta-questions regarding the costs and benefits of registration data validation should be answered: >> >> • What data elements need to be added or validated to comply with requirements or expectations of different stakeholders? >> • Is additional registration processing overhead and delay an acceptable cost for improving accuracy and quality of registration data? >> • Is higher cost an acceptable outcome for improving accuracy and quality? >> • Would accuracy improve if the registration process were to provide natural persons with privacy protection upon completion of multi-factored validation? >> >> >> SAC062: SSAC Advisory Concerning the Mitigation of Name Collision Risk >> >> http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf >> >> Recommendation 1: ICANN should work with the wider Internet community, including at least the IAB and the IETF, to identify (1) what strings are appropriate to reserve for private namespace use and (2) what type of private namespace use is appropriate (i.e., at the TLD level only or at any additional lower level). >> >> Recommendation 2: ICANN should explicitly consider the following questions regarding trial delegation and clearly articulate what choices have been made and why as part of its decision as to whether or not to delegate any TLD on a trial basis: >> >> -- Purpose of the trial: What type of trial is to be conducted? What data are to be collected? >> >> -- Operation of the trial: Should ICANN (or a designated agent) operate the trial or should the applicant operate it? >> >> -- Emergency Rollback: What are the emergency rollback decision and execution procedures for any delegation in the root, and have the root zone partners exercised these capabilities? >> >> -- Termination of the trial: What are the criteria for terminating the trial (both normal and emergency criteria)? What is to be done with the data collected? Who makes the decision on what the next step in the delegation process is? >> >> Recommendation 3: ICANN should explicitly consider under what circumstances un-delegation of a TLD is the appropriate mitigation for a security or stability issue. In the case where a TLD has an established namespace, ICANN should clearly identify why the risk and harm of the TLD remaining in the root zone is greater than the risk and harm of removing a viable and in-use namespace from the DNS. Finally, ICANN should work in consultation with the community, in particular the root zone management partners, to create additional processes or update existing processes to accommodate the potential need for rapid reversal of the delegation of a TLD. >> >> SAC063: SSAC Advisory on DNSSEC Key Rollover in the Root Zone >> >> http://www.icann.org/en/groups/ssac/documents/sac-063-en.pdf >> >> Recommendations: >> >> Recommendation 1: Internet Corporation for Assigned Names and Numbers (ICANN) staff, in coordination with the other Root Zone Management Partners (United States Department of Commerce, National Telecommunications and Information Administration (NTIA), and Verisign), should immediately undertake a significant, worldwide communications effort to publicize the root zone KSK rollover motivation and process as widely as possible. >> >> Recommendation 2: ICANN staff should lead, coordinate, or otherwise encourage the creation of a collaborative, representative testbed for the purpose of analyzing behaviors of various validating resolver implementations, their versions, and their network environments (e.g., middle boxes) that may affect or be affected by a root KSK rollover, such that potential problem areas can be identified, communicated, and addressed. >> >> Recommendation 3: ICANN staff should lead, coordinate, or otherwise encourage the creation of clear and objective metrics for acceptable levels of “breakage” resulting from a key rollover. >> >> Recommendation 4: ICANN staff should lead, coordinate, or otherwise encourage the development of rollback procedures to be executed when a rollover has affected operational stability beyond a reasonable boundary. >> >> Recommendation 5: ICANN staff should lead, coordinate, or otherwise encourage the collection of as much information as possible about the impact of a KSK rollover to provide input to planning for future rollovers. >> >> PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.) >> > PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 2

ICANN Publishes Annual Report for Fiscal Year 2013
by Glen de Saint Géry Dec. 19, 2013

Dec. 19, 2013

http://www.icann.org/en/news/announcements/announcement-18dec13-en.htm ICANN Publishes Annual Report for Fiscal Year 2013 18 December 2013 The 2013 Annual Report for the Internet Corporation for Assigned Names and Numbers (ICANN) has been published online today. The report highlights the organization's achievements and progress from 1 July 2012 to 30 June 2013, including: * Continued accountability and transparency efforts. * Opened new offices to increase ICANN's internationalization. * Completed evaluation of more than a thousand new gTLDs and preparations to place them in the root. * Finalized new Registrar Accreditation Agreement. * Establishment of Trademark Clearinghouse. Further content includes: * Audited financial statements for fiscal year 2013. * Biographical details on each of the Board of Directors. * Messages from the CEO and Chairman. The complete annual report is available online at: http://www.icann.org/en/about/annual-report/annual-report-2013-en.pdf [PDF, 6.69 MB] Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org<mailto:gnso.secretariat@gnso.icann.org> http://gnso.icann.org<http://gnso.icann.org/>

1 0

Newcomer Open House -- transcripts of the pilot session that took place yesterday
by Mike O'Connor Dec. 18, 2013

Dec. 18, 2013

hi all, i built a little web page on our site to introduce links to small, bite-sized pieces of the newcomer open house pilot that took place yesterday. it met with good reaction from the people who participated, but it was a pilot and we're looking for ideas on how to improve it. the whole thing is about an hour, but it's broken into small pieces so that people can select what they'd like to look at. thanks to Nathalie Perigrine for coming up with and driving the idea. and Marika, Lars and Glen for making it happen. i was/am honored to have been asked to be the presenter. mikey here's a link to the page (good for sharing with friends and colleagues) http://www.ispcp.info/policy-resources/gnso-working-groups-newcomer-open-ho… and here's the content on that page (as long as i have your attention) GNSO Working Groups — Newcomer Open House ISPCP member Mikey O’Connor moderated a pilot session of a webinar intended to provide orientation, information and resources to members of the GNSO community who are joining a GNSO PDP Working Group for the first time. Here’s a link to the slide deck that was presented — this PDF contains a wealth of links to written resources for working-group participants. Newcomers Open House.pdf Here are links to recordings of the session. Introduction, Tips and Tricks, Session Goals and Overview, Resources In which you will; experience how we start up every working-group call, get an introduction to some tips and tricks of the Adobe room that we use, be introduced to the ICANN policy staff, get an overview of goals and topics of the session and get your first set of helpful links. https://icann.adobeconnect.com/p29xh8ldqb4/ (20 minutes) Consensus Policy and the “Picket Fence” This is a discussion of the relationship between the GNSO consensus policy-making process and the contracts that bind Registries, Registrars and ICANN together. https://icann.adobeconnect.com/p6f5tyvjmma/ (7 minutes) The GNSO Policy Development Process An overview of the whole Policy Development Process (PDP). This section quickly introduces you to all of the steps of the PDP; requesting an Issue Report, launching a Working Group, moving that work through the approval process, implementation into policy. https://icann.adobeconnect.com/p64j05q58kx/ (11 minutes) – Presentation https://icann.adobeconnect.com/p9fzftl3rar/ (12 minutes) – Questions and Answers PDP Working Group Guidelines A brief introduction to the documentation that describes the PDP work processes, rules and responsibilities. Special attention is paid to a discussion of the Standard Methodology for Making Decisions (also known as the level of consensus). https://icann.adobeconnect.com/p8qtevealwa/ (7 minutes) Question and Answer Session A brief Q&A session that focused on the social media aspects of working groups. https://icann.adobeconnect.com/p2lml89ip4g/ (3 minutes) PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)

2 2

Re: [council] FYI - Save the Date - ICANN Brussels Briefing, 18 Dec 2013 at Renaissance hotel
by Marika Konings Dec. 17, 2013

Dec. 17, 2013

And now with the attachment. Apologies, Marika From: Marika Konings <marika.konings(a)icann.org> Date: Tuesday 10 December 2013 12:07 To: Council GNSO <council(a)gnso.icann.org> Subject: [council] FYI - Save the Date - ICANN Brussels Briefing, 18 Dec 2013 at Renaissance hotel For your information BRUSSELS BRIEFING; 18TH DECEMBER 2013 As 2013 comes to an end we would like you to save the date for the second (and last of year) ICANN Brussels briefing, on December 18 at 09.30hrs at the Renaissance Hotel <https://maps.google.com/maps?ie=UTF-8&q=Renaissance+Brussels+Hotel&fb=1&hq= renaissance+hotel&hnear=0x47c3a4ed73c76867:0xc18b3a66787302a7,Brussels,+Belg ium&cid=10687355292024950971&ei=Is2lUqnxEIeqhQf20YGABw&ved=0CPYBEPwSMAs> , the event will finish with a buffet lunch. It will be an occasion to meet and update you on the ICANN developments including the new gTLD program, outcomes from the ICANN 48 Buenos Aires and larger IG topics such as the preparation of the San Paulo meeting on the Future of the Internet Governance, the 1NET movement and the WSIS+10 review process. We will also to take stock from the first public session on the ICANN Engagement Strategy for Europe <https://community.icann.org/display/gseeuropewkspc/ICANN+Engagement+Strateg y+for+Europe> (IESE) held at ICANN 48, and design toghether the roadmap to build a solid regional strategy. 2014 is set to be a key year in the global IG ecosystem, would be very good too see you and exchange greetings before we start the Christmas break and a very intense year ahead. Please "spread the news" and let us know if you can come (Register sending your details to petya.minkova(a)icann.org) Best regards, Nigel Hickson nigel.hickson(a)icann.org <mailto:nigel.hickson@icann.org> Andrea Beccalli andrea.beccalli(a)icann.org <mailto:andrea.beccalli@icann.org>

1 1

Public Comment Period: New gTLD Auction Rules
by Glen de Saint Géry Dec. 17, 2013

Dec. 17, 2013

http://www.icann.org/en/news/announcements/announcement-17dec13-en.htm New gTLD Auction Rules Comment / Reply Periods (*) Comment Open Date: 17 December 2013 Comment Close Date: 14 January 2014 - 23:59 UTC Reply Open Date: 15 January 2014 Reply Close Date: 4 February 2014 - 23:59 UTC Important Information Links Public Comment Announcement<http://www.icann.org/en/news/announcements/announcement-17dec13-en.htm> To Submit Your Comments (Forum)<mailto:comments-new-gtld-auction-rules-16dec13@icann.org> View Comments Submitted<http://forum.icann.org/lists/comments-new-gtld-auction-rules-16dec13/> Brief Overview Originating Organization: Global Domains Division Categories/Tags: * New gTLD Auctions Purpose (Brief): To gather community input regarding the detailed rules and processes for Auctions to resolve string contention sets in the New gTLD Program. Current Status: The Auction Rules (version 2013.12.12) have been updated since the publication of the Preliminary Auction Rules on 1 Nov 2013 based on community feedback, including feedback received in Webinars and sessions at the ICANN 48 meeting in Buenos Aires. Additionally the Bidder's Agreement, Bidder forms, and a Draft Auction Schedule have been published for community input. Next Steps: Based on public comment feedback, a final set of Auction Rules and Bidder's Agreement will be published and New gTLD Auctions to resolve string contention sets will be implemented and executed per the rules. Staff Contact: Russ Weinstein Email Staff Contact<mailto:russ.weinstein@icann.org?subject=More%20information%20on%20the%20New%20gTLD%20Auction%20Rules%20public%20comment%20period> Detailed Information Section I: Description, Explanation, and Purpose: ICANN is pleased to announce the publication of an updated version (2013.12.12) of the Auction Rules, the Bidder Agreement, the Bidder Forms, and a Draft Auction Schedule for community review. The Auction Rules have been updated since the initial release of the Preliminary Auction Rules on 1 Nov 2013 based on feedback received including during the Auctions Webinar on 7 November 2013 and the ICANN 48 Meeting in Buenos Aires. The documents being published for comment are: · Auction Rules version 2013.12.12 - provides a detailed insight into all facets of the Auctions program, including eligibility, scheduling considerations, preparation procedures, deposits, bidding limits, bidding procedures, the conclusion of auctions, payments and refunds. This version of the Auction Rules only addresses Contention Sets with direct contention relationships; an update or addendum will be published at later time to address Contention Sets with both direct and indirect contention relationships. · Bidder Forms - allows an applicant to designate itself or another entity to act as the bidder on its behalf. These forms will be used by ICANN and Power Auctions (the Auction Manager) to perform due diligence, set up a bank subaccount and a user account on the Auction Site. The bidder forms must be completed for each application participating in an Auction. · Bidder Agreement - an agreement between the Applicant and/or Bidder and Power Auctions, detailing the roles and responsibilities of each of these parties in the Auction process. The Bidder Agreement must be executed at least one time for each Applicant, and if an applicant utilizes a Designated Bidder, the agreement must be executed for each unique configuration of Applicant and Designated Bidder. · Draft Auction Schedule - Using the preliminary contention sets which do not include the effect any objection determinations may have, a Draft Auction Schedule has been created. This schedule utilizes the scheduling criteria defined in the Auction Rules but, due to the dynamic nature of application status, does not take into account the eligibility requirements for a contention set to be sent to Auction by ICANN as defined in the Applicant Guide Book and the Auction Rules. Should contention sets either resolve prior to their scheduled Auction or not yet be eligible for an Auction, ICANN will adjust the schedule in attempt to maintain approximately 20 contention sets per Auction. ICANN intends to publish a Master Escrow agreement between ICANN, Power Auctions and the Escrow Provider for informational purposes prior to the conclusion of the public comment period. It is not envisioned that Bidders will execute an agreement with the Escrow Provider; rather the Bidder's Agreement will create a relationship where the Bidder will be a third party beneficiary to the Escrow Agreement. The Escrow provider will establish accounts by Bidder to securely hold deposits, issue refunds to Bidders based on the Auction Results, and collect winning fees on behalf of ICANN. All feedback will be taken into account, but community feedback on the following topics will be especially helpful. * The pace and schedule of auctions to resolve all outstanding contention sets * The duration of auction rounds and recesses between rounds * The effects of the Name Collision issues on the eligibility for auction of a contention set With the input from the community in this public comment period, ICANN will complete and publish the Auction Rules, Bidder's Agreement, Bidder Forms and move forward to administer Auctions to resolve string contention sets on the new gTLD program. Section II: Background: Section 4.3 of the Applicant Guidebook describes auctions as the last resort method to resolve string contention sets. This section provides for an Ascending Clock Auction methodology and provides an overview of the process and simplified illustrations of the execution of a contention set auction. On 1 November 2013, a preliminary version of the Auction rules was published. The Auction Rules were published as preliminary because there were several aspects related to scheduling that would benefit from community feedback prior to finalization and execution of the Auction program. The Auction Rules have since been updated to provide more details of the Auction processes and procedures as well as to incorporate community feedback received since the initial publication. Section III: Document and Resource Links: Applicant Guide Book section 4.3<http://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04…> [PDF, 429 KB] New gTLD Auction Rules 2013.12.12<http://newgtlds.icann.org/en/applicants/auctions/rules-12dec13-en.pdf> [PDF, 323 KB] New gTLD Auction Rules_1Nov13<http://newgtlds.icann.org/en/applicants/auctions/prelim-rules-31oct13-en.pdf> [PDF, 235 KB] (Preliminary) Redline of Auction Rules 2013.12.12 to 2013.11.01<http://newgtlds.icann.org/en/applicants/auctions/rules-redline-12dec13-en.p…> [PDF, 352 KB] (Comparison of current version to preliminary) Draft Auction Schedule 2013.12.16<http://newgtlds.icann.org/en/applicants/auctions/draft-schedule-16dec13-en.…> [PDF, 308 KB] New gTLD Auction Bidder Agreement<http://newgtlds.icann.org/en/applicants/auctions/bidder-agreement-12dec13-e…> [PDF, 171 KB] New gTLD Auction Bidder Forms<http://newgtlds.icann.org/en/applicants/auctions/bidder-designation-form-16…> [PDF, 241 KB] Section IV: Additional Information: N/A ________________________________ (*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses. Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org<mailto:gnso.secretariat@gnso.icann.org> http://gnso.icann.org<http://gnso.icann.org/>

1 0

RySG Candidate Election
by Gomes, Chuck Dec. 16, 2013

Dec. 16, 2013

Glen, Please note that Bret Faucet was elected by the RySG to fill the vacated Council seat of Jeff Neuman and will fill that seat effective immediately so you can remove me from the Council list. I enjoyed working with all of you since the second Council meeting in Buenos Aires and trust that your work in the coming year will be productive and effective. Merry Christmas and Happy New Year. Chuck "This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately."

4 3

GNSO Council resolutions 12 December 2013
by Glen de Saint Géry Dec. 13, 2013

Dec. 13, 2013

Dear Councillors, The GNSO Council resolved the following resolutions at its meeting on Thursday 12 December 2013. 1. Motion to adopt the Joint ccNSO/GNSO IDN Working Group (JIG) Final Report on Universal Acceptance of IDN TLDs WHEREAS, 1. The JIG (Joint ccNSO/GNSO IDN Working Group) was formed by mutual charters between the ccNSO and GNSO councils, and extended (ccNSO: http://ccnso.icann.org/workinggroups/minutes-council-23aug11-en.pdf | GNSO: http://gnso.icann.org/resolutions/#201107) to complete its work on the 3 identified issues of common interest between the ccNSO and GNSO; 2. One of those issues concerns Universal Acceptance of IDN TLDs; 3. The JIG published its Draft Final Report on Universal Acceptance of IDN TLDs for public comment which closed on 16 August 2013, http://www.icann.org/en/news/public-comment/idn-tld-acceptance-final-25jun1…) 4. The JIG reviewed the comments received and finalized its report accordingly. 5. The JIG submitted its Final Report to the GNSO Council on 17 November (http://buenosaires48.icann.org/en/schedule/mon-jig/presentation-jig-final-i…) 6. The GNSO Council reviewed and considered the Final Report. Resolved, 1. The GNSO Council adopts the JIG Final Report on Universal Acceptance of IDN TLDs and its recommendations and will submit it to the ICANN Board for its consideration. 2. The GNSO Council thanks the JIG for its work, with special thanks to Jothan Frakes for his contributions in proactively reaching beyond the ICANN community to address issues identified in the report. 3. The GNSO Council recognizes that further work needs to be done in relation to IDNs, in particular IDN variants and universal acceptance of IDNs and asks the JIG to put forward suggestions on how to deal with these issues and deliver these suggestions to the GNSO Council by the ICANN Singapore Meetings in March 2014. 2. Motion to adopt the Final Report of the joint DNS stability and security analysis Working Group (DSSA) Whereas 1. The joint DNS Security and Stability Analysis working group was established by the participating Supporting Organizations and Advisory Committees ALAC, ccNSO, GNSO and NRO to better understand the security and stability of the global domain name system (DNS) in 2011. 2. In October 2011 the ICANN Board of Directors established the Board DNS Risk Management Framework Working Group (DNS RMF WG), with the objective to oversee the development of a risk management framework and system for the DNS as it pertains to ICANN's role as defined in the ICANN Bylaws. 3. At the time the DSSA published its draft Report Phase 1 (August 2012), the DSSA went into hibernation to avoid overlap with the work of the Board DNS RMF and noted and informed the participating SO's and AC's that in order to reflect the changed environment and working method, the charter of the DSSA would need to be updated to reflect these changes. 4. The co-chairs of the DSSA WG have sent a letter (http://gnso.icann.org/en/correspondence/dssa-to-so-ac-chairs-09nov13- en.pdf) to the chairs of each of the participating stakeholder organizations to submit the Final Report and the work products contained in it (available at: http://ccnso.icann.org/workinggroups/dssa-final-08nov13-en.pdf) This letter outlines the reasons the co-chairs recommend not proceeding with phase 2. 5. The DSSA recommends the acceptance of the Final Report and further recommends that the Final Report be disseminated to registry operators and registrars for their consideration. 6. Upon adoption of the Final report of the DSSA, and notification of adoption to the co-chairs of the DSSA, the working group will be closed. Resolved 1. The GNSO Council adopts the Report submitted by the co-chairs of the DSSA WG, as the Final Report of the DSSA WG in accordance with section 2.4 of its charter. 2. The chair of the GNSO Council is requested to inform the co-chairs of the DSSA WG of adoption of the Report by the GNSO Council. 3. The chair of GNSO Council is also requested to inform the chairs of the other participating SO's and AC's (SSAC, ALAC, ccNSO and NRO). 4. Finally, the GNSO Council thanks and congratulates all, and in particular the co-chairs of the WG: Olivier Crepin- LeBlond (ALAC), Joerg Schweiger (.DE, ccNSO), Mikey O'Connor (GNSO), James Galvin (SSAC) and Mark Kosters (NRO) and all volunteers and staff who helped with this effort. Please let me know if you have any questions. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0