June 2008 - council - lists.icann.org

RE: [council] Fast Flux Policy Development Process
by Tim Ruiz 09 Jun '08

09 Jun '08

Glen, The following RrC members would like to participate on this WG: "Eric Brunner-Williams" <ebw(a)abenaki.wabanaki.net> "Margie Milam" <Margie.Milam(a)markmonitor.com> "Paul Stahura" <Paul.Stahura(a)enom.com> "James M. Bladel" <jbladel(a)godaddy.com> I believe there one or two others who are also considering it. I will forward those names when/if they make a decision. Tim -------- Original Message -------- Subject: [council] Fast Flux Policy Development Process From: "GNSO.SECRETARIAT(a)GNSO.ICANN.ORG" <gnso.secretariat(a)gnso.icann.org> Date: Mon, June 02, 2008 8:21 am To: "'Council GNSO'" <council(a)gnso.icann.org> Dear All, We would like to draw your attention to the Fast Flux notice and invitation to join the working group that is on the GNSO homepage http://gnso.icann.org/ What's New: During its meeting of 29 May, the GNSO council decided to create a WG in order to meet its requirements for the PDP. The details are contained in the motion attached below. In order to initiate this working group the following steps are being taken: This public announcement is being made of the working group's formation. Each constituency, and the liaisons, are invited to discuss the composition of the working group and to provide a list of names of expected participants who can then be added to the WG mailing list. Other stakeholders and experts may be invited to join the WG by the GNSO council. Community members who wish to be invited to join the group should contact the GNSO secretariat and the invitations will be reviewed by the GNSO council. The Working Group will have an initial meeting on 21 June (time to be announced) in Paris. Remote participation facilities will be available. At the initial meeting, one topic will be that of a picking a working group chair. The choice of working group chair will be subject to GNSO council approval at its meeting of 25 June. It is expected that discussion on candidates for chair will occur before the 21 June meeting. In the interim, Avri Doria, as GNSO council chair, will chair the working group. The GNSO council in its approval of the charter decided that more guidance may be required on the meaning of rough consensus and its application to this WG. This topic will be discussed on the GNSO council list and if/when further guidance is agreed upon, it will be forwarded to the working group and its chair. At its meeting on 25 June, the GNSO council will also decide on its liaison to the WG. Interested council members are invited to make their willingness to serve in this capacity known. Motion which was passed by the GNSO Council: http://gnso.icann.org/announcements/announcement-30may08.htm. Please let me know if you have any questions. Thank you. Kind regards, Glen de Saint G�ry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org -- Glen de Saint G�ry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

RE: [council] RE: [gnso-trans-pdp] Report from Drafting Group on Clarification of Reasons for Denial
by Tim Ruiz 09 Jun '08

09 Jun '08

3 2

ICANN Opens Public Comment Period for Draft/Interim Terminated Registrar Transition Procedure
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 06 Jun '08

06 Jun '08

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://www.icann.org/en/announcements/announcement-2-06jun08-en.htm ICANN Opens Public Comment Period for Draft/Interim Terminated Registrar Transition Procedure 6 June 2008 0.1 In consultation with the community, ICANN has developed this draft/interim procedure for managing transition of gTLD domain name registrations from a de-accredited registrar to an accredited gaining registrar. This process is currently being used by ICANN staff to facilitate transition of gTLD registrations of de-accredited registrars and is being posted until 7 July 2008 for public comment for further refinement. Along with ICANN’s Registrar Data Escrow, Registry Failover, and Contractual Compliance programs, this procedure is intended to enhance protection of registrants. A graphical representation of this procedure is also posted at http://www.icann.org/registrars/drt-procedure-flowchart-06jun08.pdf [PDF, 21K]. 0.2 Comments regarding this draft/interim procedure may be posted by email to dtr-procedure-2008(a)icann.org until 7 July 2008 and viewed at http://forum.icann.org/lists/dtr-procedure-2008/. Following conclusion of this public comment period, the resulting procedure will be revised as appropriate and submitted to the ICANN Board of Directors for adoption and fully implemented upon approval. 1. Introduction 1.1 Upon the termination or expiration of a registrar’s Registrar Accreditation Agreement (RAA), the registrations sponsored by the de-accredited registrar must be transitioned to a competent accredited registrar. In the past, such transitions have generally been accomplished through a “bulk transfer,” as described in Part B of the Inter-Registrar Transfer Policy <http://www.icann.org/transfers/policy-12jul04.htm>, and have required the cooperation of the “losing” (de-accredited) registrar because the losing registrar was the sole source of registration data necessary to identify registration rights in the affected domain names. 1.2 With the implementation of the Registrar Data Escrow (RDE) program <http://www.icann.org/announcements/announcement-2-09nov07.htm> ICANN will have greater ability to enable a transition of names, even where the de-accredited registrar is not cooperative in a bulk transfer. Although the RDE program is currently still being implemented across all registrars, this process is intended to be used by ICANN to facilitate the transition of registrations of terminated registrars whether the necessary registration data is immediately available to ICANN or not. 1.3 This draft/interim process is currently being used by ICANN staff in facilitating the transition of registrations from two recently de-accredited registrars. It was developed from learning by staff in previous registrar de-accreditations (including both voluntary and involuntary terminations) and with input provided by the community at the Registrar Termination workshop hosted in Delhi, India at the February 2008 ICANN meeting. (Transcript, presentation slides, and summary of participant comments available at: http://delhi.icann.org/node/53.) Through the workshop in Delhi, community members provided several well-considered ideas for addressing particular scenarios that could be encountered upon the de-accreditation of a registrar. Although many of suggestions have been incorporated into this draft/interim procedure, some of the suggestions are not currently implementable due to existing policy limitations or a need for further development of long-term solutions. It is anticipated that, after this procedure has been finalized and approved, it will be periodically reevaluated and adapted as warranted by ICANN’s experience with its use. 2. Draft/Interim Terminated Registrar Transition Procedure 2.1 The Terminated Registrar Transition Procedure generally does not become operative until a registrar’s RAA has been finally terminated because the RAA gives registrars certain rights to, for example, cure a breach after ICANN issues a notice of breach and contest a termination through arbitration. Nevertheless, before the procedure is initiated, ICANN will have taken steps to help ensure as smooth a transition as possible, by conducting an assessment of the availability of registration data (either through the registrar data escrow program or otherwise) and working with registries to ensure registrations are not deleted due to the actions or inaction of a de-accredited registrar. 2.2 Under Part B of the Inter-Registrar Transfer Policy (the “Policy”), the sponsorship of all gTLD registrations of one registrar may be transferred in bulk to another registrar (a “bulk transfer”) where a registrar is no longer accredited as a registrar and ICANN approves the bulk transfer. Under the Policy, the bulk transfer can only be effected where the gaining registrar is accredited and operational (with a registry-registrar agreement in force) for the respective TLD(s) and where ICANN certifies to the registry operator that “the transfer would promote the community interest, such as the interest in stability that may be threatened by the actual or imminent business failure of a Registrar.” 3. Voluntary Bulk Transfers 3.1 When a registrar’s RAA is terminated or not renewed, it may often be in the best interests of registrants and at-large users of the Internet for ICANN to permit the de-accredited registrar to designate a “gaining registrar” to receive a bulk transfer of its names. Such a transition could help minimize customer confusion while ensuring that the gaining registrar receives as much customer and registration data from the losing registrar as possible. Moreover, a voluntary transition generally involves the least amount of friction. 3.2 In some cases, however, a voluntary transition is not possible or practical because either the losing registrar is uncooperative or because its designation of a gaining registrar would not serve the community interest. By way of example, a proposed transfer might not be in the community’s interest if the gaining registrar is not in good standing with its ICANN obligations or where the losing registrar appears to be using the termination of its RAA as a vehicle for avoiding its obligations to ICANN or its customers by transferring the registrations to an affiliated registrar without satisfying the outstanding obligations. 3.3 While recognizing the potential benefits of a voluntary bulk transfer, the Terminated Registrar Transition Procedure employs a balancing of interests in the decision to approve or not approve a proposed voluntary bulk transfer. The considerations in this decision include, without limitation: whether the gaining registrar is in good-standing with its ICANN obligations, whether the gaining registrar is operational and experienced in managing the affected TLDs, whether there is a relationship between the losing registrar and gaining registrar that could allow abuse or gaming of the proposed bulk transfer, whether the losing registrar would continue to manage the registrations as a reseller for the gaining registrar or otherwise be involved in the management of the names and customers, and whether, as a result of the bulk transfer, obligations to ICANN and the losing registrar’s customers are likely to be satisfied. 3.4 In weighing all considerations, ICANN may either approve the voluntary bulk transfer by announcing the approval to the registrars and involved registries, or deny the requested transfer, by giving the losing registrar another opportunity to name a gaining registrar or proceeding to designate a gaining registrar without deference to the losing registrar’s suggestion. If ICANN approves the voluntary transfer, the approval could be conditioned on satisfaction of certain conditions (e.g., payment of outstanding ICANN invoices or registry fees). Failure by the registrars to satisfy the approval condition(s) could result in the withdrawal of ICANN’s approval of the transfer, leaving ICANN to select a gaining registrar itself. 4. Involuntary Bulk Transfers 4.1 The RAA provides ICANN a license to use or transfer registrar data to provide registrar services upon termination of a registrar’s accreditation agreement. Where a de-accredited registrar does not cooperate with ICANN’s transition efforts or ICANN does not approve the proposed gaining registrar in a voluntary bulk transfer, ICANN must select a gaining registrar to manage the orphaned registrations. During the terminated registrar workshop in Delhi, some participants suggested options for transition that would parcel out registrations across multiple registrars. Although such alternatives might be necessary in the event no one registrar is operational in all affected TLDs or when other challenges make a single bulk transfer impractical, one bulk transfer is the preferred course of action, to avoid potentially confusing registrants and to minimize complications in the transfer process. 5. Availability of Registration Data 5.1 In order to effect a transfer of registrations from one registrar to another, the gaining registrar must be provided with at least basic registration data in order to be able to identify registrants and process registration updates, such as renewals, contact changes, and nameserver updates. Outside the RDE program, a handful of tools are available that would help permit identification of registrants where a de-accredited registrar does not cooperate with a bulk transfer. 5.2 When a voluntary bulk transfer is not possible, ICANN must assess the extent to which registration data is available to it (or more accurately, to the potential gaining registrar). Because such data could come from a variety of sources, its completeness and integrity will need to be analyzed by ICANN to determine whether to proceed to selection of a gaining registrar or whether other courses of action must be considered. 5.3 If registration data is unavailable or deemed unreliable, ICANN may: 5.3.1 initiate litigation or arbitration to obtain registration data to facilitate a transfer through this procedure; 5.3.2attempt to collect Whois / registration data from non-authoritative sources; 5.3.3 allow the de-accredited registrar to continue limited operations to be able to service existing customer needs (by processing renewals and updates but not new registrations, for example); 5.3.4 negotiate an arrangement with the de-accredited registrar to obtain its cooperation with a bulk transfer; 5.3.5 allow registrations to expire on their expiration date; 5.3.6 instruct registries to delete names (in limited and unique situations, such as, for example, where it appears the names are all test-registrations with no beneficial owner); or 5.3.7 pursue more than one of these potential options or a different alternative altogether. 5.4 If ICANN is satisfied with the availability and quality of registration data, it will proceed to the Gaining Registrar Selection Process. 6. Gaining Registrar Selection Process 6.1 The first step in the selection of a gaining registrar by ICANN is a solicitation of statements of interest through the posting of a Request for Information (RFI) at http://www.icann.org and distribution through the Registrar Constituency. The RFI will request that applicants submit an application within a time frame of approximately one week. The responses should include details about the applicant-registrar’s qualifications, such as ability to technically manage the transition of registrations and capacity to provide competent customer service to new registrants. (An example of an RFI recently posted pursuant to this procedure is available at: http://www.icann.org/en/announcements/announcement-06jun08-en.htm.) 6.2 In reviewing the RFI responses, ICANN will determine whether a formal Request for Proposals (RFP) or auction process is necessary to select a gaining registrar. This determination is largely based on the feasibility of negotiating with the registrars who responded to the RFI. That is, if only a few statements of interest were received or if all but a few were apparently unqualified to act as gaining registrar, ICANN may elect to engage the qualified bidders in direct negotiations to select the gaining registrar. If, however, direct negotiations are impractical or if no statements of interest are received, ICANN may initiate an RFP or auction as appropriate. Regardless of whether an RFI, RFP, or auction is utilized, the gaining registrar selection criteria are the same. The gaining registrar should: 6.2.1 be able to quickly transition registrations and customer information into its registrar operations to be able to provide timely service to the newly acquired registrants; 6.2.2 be able to demonstrate prior experience in managing a portfolio of registrations/customers comparable to those of the de-accredited registrar; 6.2.3 have available sufficient customer service staff to timely respond to customer service requests during and following the bulk transfer; 6.2.4 be accredited and operational in all applicable gTLDs and in good-standing under its RAA; 6.2.5 have experience in and knowledge of bulk transfer procedures; 6.2.6 have documented procedures in place to resolve potential disputes of domain name control or registration rights; 6.2.7 be experienced as a customer-facing / “retail” registrar business (if applicable); 6.2.8 have experience in managing second-level internationalized domain names (if applicable); 6.2.9 be able and willing to provide ICANN with regular status reports; and 6.2.10 provide adequate compensation for the portfolio of customers/registrations. 6.3 While these criteria will guide ICANN’s selection of a gaining registrar, they are not intended as inflexible rules. That is, an applicant who meets most of the criteria may nevertheless be considered to be the gaining registrar, and similarly, unique circumstances may require consideration of additional factors not listed here. 7. Alternatives When No Gaining Registrar is Identified 7.1 If no qualified gaining registrar can be located through the Gaining Registrar Selection Process, ICANN might: 7.1.1 temporarily operate the registrar through its “terminated registrar” registry account and establish a deadline by which all registrants must transfer their names out; 7.1.2 operate the terminated registrar indefinitely by providing unlocking and auth-code services to registrants; 7.1.3 retain the services of a registrar backend service (or backend and customer service) provider either temporarily or indefinitely; 7.1.4 compensate a registrar to receive the bulk transfer; 7.1.5 offer a temporary accreditation to potential gaining registrars; or 7.1.6 allow names to be deleted upon expiration. 7.2 These alternatives reflect, to varying degrees, handling of a “worst-case” scenario. It is expected that, in nearly every de-accreditation, the customer portfolio of the de-accredited registrar will have some value, such that a gaining registrar can be identified through the Gaining Registrar Selection Process described above. 8. Ongoing Process Development 8.1 ICANN recognizes that this procedure may not address all possible scenarios of registrar de-accreditation or other RAA terminations. Moreover, viable alternatives to the procedures described in this document may be available in the future, pending possible policy development or further coordination between relevant stakeholders and upon full implementation of the registrar data escrow program. For these reasons ICANN staff will periodically review the effectiveness of this Terminated Registrar Transition Procedure and implement modifications as necessary to ensure it remains a useful and efficient tool in the protection of registrants. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Front Running Drafting Team
by Tim Ruiz 06 Jun '08

06 Jun '08

Has this group kicked off yet? Tomorrow is/was the deadline. Tim

2 1

RE: [gnso-trans-pdp] Report from Drafting Group on Clarification of Reasons for Denial
by Gomes, Chuck 06 Jun '08

06 Jun '08

Thanks Mike. Olof said the same thing and as you know Tim has as well. Chuck > -----Original Message----- > From: owner-gnso-trans-pdp(a)icann.org > [mailto:owner-gnso-trans-pdp@icann.org] On Behalf Of Mike O'Connor > Sent: Friday, June 06, 2008 9:48 AM > To: Gomes, Chuck; Olof Nordling; council(a)gnso.icann.org > Cc: gnso-trans-pdp(a)icann.org > Subject: RE: [gnso-trans-pdp] Report from Drafting Group on > Clarification of Reasons for Denial > > > hi Chuck, > > i haven't seen Olof's reply -- i may not have been copied on > it. if so, please forgive me if this is a duplicate reply. > > we operated on a consensus-based process -- everybody in the > group supports the document. we hammered out the > disagreements during the drafting. > > m > > At 09:48 AM 6/5/2008, Gomes, Chuck wrote: > >Thank you very much Olof. What was the level of support in > the small > >group for the recommendations? > > > >Chuck > > > > > >---------- > >From: owner-gnso-trans-pdp(a)icann.org > >[mailto:owner-gnso-trans-pdp@icann.org] On Behalf Of Olof Nordling > >Sent: Thursday, June 05, 2008 5:13 AM > >To: council(a)gnso.icann.org > >Cc: gnso-trans-pdp(a)icann.org > >Subject: [gnso-trans-pdp] Report from Drafting Group on > Clarification > >of Reasons for Denial > > > >Dear Councilors, > > > >On behalf of the Chair, Mike O'Connor, and the whole Drafting Group, > >please find attached the Final Draft from the Group, for your > >consideration and decisions on how to proceed. The Final > Draft is also > >available on the Drafting Group's Wiki, at > ><https://st.icann.org/irt-pdp/index.cgi?final_draft>https://s > t.icann.or > >g/irt-pdp/index.cgi?final_draft > >. > > > >Very best regards > > > >Olof > > > > > >No virus found in this incoming message. > >Checked by AVG. > >Version: 8.0.100 / Virus Database: 270.0.0/1485 - Release Date: > >6/5/2008 10:07 AM > >

1 0

Fast Flux WG
by Gomes, Chuck 06 Jun '08

06 Jun '08

Understanding that we are interested in getting technical experts on the Fast Flux working group, please add Matt Larson from VeriSign to the WG. Chuck

1 0

"Relation between ccNSO and gNSO: New gTDLs" posted on website
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 06 Jun '08

06 Jun '08

Dear All, The document "Relation between ccNSO and gNSO: New gTDLs" by Jon Bing which will be discussed on Sunday 22 June at the GNSO Working Sessions in Paris, is posted on page: http://gnso.icann.org/correspondence/ and may be directly viewed at: http://gnso.icann.org/correspondence/bing-to-ccnso-26mar08.pdf Thank you. Kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

RSTEP Report on PIR's Request to Implement DNSSEC in .ORG
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 06 Jun '08

06 Jun '08

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://icann.org/en/announcements/announcement-2-05jun08-en.htm RSTEP Report on PIR's Request to Implement DNSSEC in .ORG 5 June 2008 On 21 April 2008, ICANN referred Public Interest Registry (PIR)'s proposed implementation (http://icann.org/registries/rsep/pir-request-03apr08.pdf) [PDF, 205K] of DNS Security Extensions (DNSSEC) in .ORG to the Registry Services Technical Evaluation Panel (RSTEP). In accordance with the Registry Services Evaluation Policy (RSEP) (http://icann.org/registries/rsep/rsep.html) the RSTEP had 45 calendar days to review the proposal and prepare a written report on whether the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Security or Stability. The RSTEP Review Team completed its report that can be found at http://icann.org/registries/rsep/rstep-report-pir-dnssec-04jun08.pdf [PDF, 481K]. Very briefly, the technical evaluation found that the proposed implementation of DNSSEC, "does create a reasonable risk of a meaningful adverse effect on security and stability, which can be effectively mitigated by policies, decisions, and actions to which ! PIR either has expressly committed in its proposal or could reasonably be required to commit." The Review Team consisted of the following members: Patrik Fältström (Cisco; USA) Paul Hoffman (VPN Consortium, USA) (Chair) Mark Kosters (ARIN, USA) Frederico A C Neves (NIC.br, Brasil) Andrew Sullivan (Command Prompt, Canada) Under the terms of the RSEP, following receipt of the RSTEP report, the ICANN Board will determine whether the proposed Registry Service creates a reasonable risk of a meaningful adverse effect on Stability or Security. ICANN invites public comments on the RSTEP Report through 20 June 2008 23:59 UTC. Comments can be submitted to pir-dnssec-proposal(a)icann.org, and viewed at http://forum.icann.org/lists/pir-dnssec-proposal/. All documents related to the PIR proposal are available at http://www.icann.org/registries/rsep/#2008004. The Board is expected to consider the RSTEP Report and PIR's proposal following synthesis and reporting of the public comment. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Internationalized Domain Name Program Adds Two Languages
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 06 Jun '08

06 Jun '08

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://www.icann.org/ http://icann.org/en/announcements/announcement-05jun08-en.htm Internationalized Domain Name Program Adds Two Languages Thai, Urdu wikis added for users to share experiences, insights 5 June 2008 MARINA DEL REY, Calif.: Thai and Urdu are the newest languages available on the Internet Corporation for Assigned Names and Numbers wikipages set up for the global testing of Internationalized Domain Names (IDNs). "Each new language made available means more users from around the world will be more naturally able to share their experiences as we test the technical impact of IDNs," said Tina Dam, Director of ICANN’s IDN Program. "The wikipages are also a great tool for people to learn — in their own language — about the work being done to make close to 100,000 characters from the languages of the world available for top level Internet addresses." ICANN launched the wiki pages with the domain name "example.test" last October in the 11 languages — Arabic, Persian, Chinese (simplified and traditional), Russian, Hindi, Greek, Korean, Yiddish, Japanese and Tamil. Since then, Hebrew and Amharic have been added. The wikis allow Internet users to establish their own subpages with their own names in their own language — one suggestion is: example.test/yourname. Thai is internationalized on the fourth level and can be accessed via the following links: (These links are also available at: http://www.icann.org/en/announcements/announcement-05jun08-en.htm) http://ไทย.idn.icann.org ( http://xn--o3cw4h.idn.icann.org ) http://xn--o3cw4h.idn.icann.org http://th.idn.icann.org Urdu uses the same script as Persian and can therefore also be accessed through the Persian .test TLD. http://نمونہ.آزمایشی ( http://xn--mgbqf7g.idn.icann.org ) http://xn--hhbbbh02d.xn--hgbk6aj7f53bba (http://xn--mgbqf7g.idn.icann.org ) http://اردو.idn.icann.org ( http://xn--mgbqf7g.idn.icann.org ) http://xn--mgbqf7g.idn.icann.org http://ur.idn.icann.org More information, as well as links to all of the wikis, is available at http://idn.icann.org. Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

The Final Draft from Drafting Group, GNSO PDP on Clarification of Transfer Denial Reasons
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 05 Jun '08

05 Jun '08

[To: council[at]gnso.icann.org] [To: gnso-trans-pdp(a)icann.org] Dear All, The Final Draft from Drafting Group, GNSO PDP on Clarification of Transfer Denial Reasons may be viewed directly at: http://gnso.icann.org/issues/transfers/gnso-final-draft-denial-reasons-04ju… This report is posted on pages: http://gnso.icann.org/issues/ under 'Transfers' and http://gnso.icann.org/ Please let me know if you have any questions. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0