February 2011 - council - lists.icann.org

Fwd: Stéphane Van Gelder comments to the PDP-WT's proposed final report
by Stéphane Van Gelder Feb. 22, 2011

Feb. 22, 2011

Just for your information, please find below the comments I have sent on the PDP WT's report. Stéphane Début du message réexpédié : > De : Stéphane Van Gelder <stephane.vangelder(a)indom.com> > Date : 22 février 2011 13:49:37 HNEC > À : gnso-pdp-final-report(a)icann.org > Objet : Stéphane Van Gelder comments to the PDP-WT's proposed final report > > Having read the Policy Development Process Work Team's Proposed Final Report, I would like to commend the WT on the quality of the work that has gone into preparing this report and offer the following questions/comments (also provided as an attached PDF). > > Please note that these comments are made in my personal capacity. I do offer them in the hope that my experience over the past few years as first a GNSO Councillor, then Council Vice Chair and now Council Chair may be of use. But they should by no means be considered statements made either by the GNSO Council Chair or on behalf of the Council as a whole. > > Stéphane Van Gelder > > Rec 1. > > What's the rationale behind leaving in place the possibility of an issues report being requested by the Board or an AC? How does the WT see the GNSO Council coping with such "outside influences"? Wouldn't this have been a good opportunity to remove this possibility from the rules and therefore bring them in line with the reality of the PDP process as we see it today (the report does state that a request from the Board or another AC has never been made in the past). > > Rec 4. > > Of what use does the WT see the proposed template being if it is not compulsory? Given the severe load that already exists on volunteers in the GNSO community, does the WT not feel that requesting that extra work be done before an issues report, but not making it compulsory ,will lead to people taking "short cuts" and not filling out the proposed template? > > Rec 12. > > What is the WT's recommendation to Council on how to determine which issues require a workshop and which don't? > > Re 14. > > What is the WT's recommendation to Council on how these resources should be measured and how Council can determine the availability of resources, given that there is currently no mechanism in place to allow Council to do so? > > Rec 16. > > I know of no practice to allow a Councillor to defer a PDP for one meeting (which does not mean that such a practice does not exist). We do have an informal practice of allowing a GNSO SG or Constituency to request through one of its Council reps that a vote on a motion be deferred for one meeting if it is the first time that motion has come up. Is this what is meant here? > > This also applies to Rec 38. > > Rec 19. > > I recommend a change of wording to make this recommendation clearer. I recommend that the last work, "bylaws", be changed to "GNSO Bylaws" to make it clear that this is not the same document that is being referenced earlier in this paragraph (ICANN Bylaws). > > Rec 22. > > Congratulations to the WT on this recommendation, which I think will serve to simplify our processes. > > Rec 34. > > What are the WT's recommendations on the timing of the initial report, i.e. when does the WT think this should be published by the working group in question? It may be that the WG does not have a clear enough idea of what it will report on in the first few weeks of its work. And as Rec 36 talks about actions when there are significant differences between a WG's initial and final reports, I think the expectations that are placed on the WG for its initial report should be clarified and detailed. > > Also, I see this is not addressed in the WT's timing chart or recommendations listed in the "overarching issues" part of the report. > > Rec 39. > > Why is the WT "concerned" with the GNSO Council accepting some recommendations and not others? Surely that is exactly what is expected of the Council, to provide final approval, or disapproval, of recommendations made as part of a PDP… > > Small point: there's a typo in this rec's last sentence (see word crossed out and shown in red below). The PDP-WT would like to encourage the GNSO Council that there were it does have concerns or would propose changes to recommendations, it passes these concerns and/or recommendations for changes back to the respective PDP Working Group for their input. > > Rec 42. > > As the WT indicates it is seeking further input from the community on this point, I would like to voice my preference for option 1, the "narrow sense" interpretation. In my view, the Board cannot choose to ignore a GNSO Council vote as it sees fit. That would constitute a negation of the bottom-up policy development process. > > Preliminary conclusions. > > The WT discusses the relationship between the current (considered by some) low voting thresholds required to request an issues report and the Council's ongoing prioritization effort. In my view, the WT should not link the two but make a determination on the voting thresholds directly. The Council is indeed experiencing severe strain on all its resources (staff and volunteers) and it is my view that the voting thresholds for an issues report, which is in effect the first step towards initiating a PDP, are too low. I would therefore encourage the WT to recommend something in this area, and not "throw this back" to the Council's prioritisation efforts which are currently an attempt more to deal with workload that is already there than to cope with possible new workload coming in. > > > > > >

1 0

Public Comment: Draft Proposal for the Study of Issues Related to the Delegation of IDN Variant TLDs
by Glen de Saint Géry Feb. 22, 2011

Feb. 22, 2011

http://www.icann.org/en/announcements/announcement-5-21feb11-en.htm Public Comment: Draft Proposal for the Study of Issues Related to the Delegation of IDN Variant TLDs 21 February 2011 Explanation/Background: The delegation and management of Variant TLDs remains an important issue. The ICANN community seeks to develop solutions to enable the delegation of Variant TLDs for the benefit of users in different regions. Today, ICANN is publishing for public comment a Draft Proposal for an IDN Variant Issues Project - a proposal for moving this work forward. On 25 September 2010 the Board of Directors of the Internet Corporation for Assigned Names and Numbers (ICANN) directed the CEO "to develop an issues report identifying what needs to be done with the evaluation, possible delegation, allocation and operation of gTLDs containing variant characters IDNs as part of the new gTLD process in order to facilitate the development of workable approaches to the deployment of gTLDs containing variant characters IDNs." (http://www.icann.org/en/minutes/resolutions-25sep10-en.htm-2.5) The proposed project work plan includes a series of case studies to investigate issues associated with delegating and using IDN variant TLDs in different communities, a staffing plan involving community members and a resource allocation plan. Importantly, this work will be coordinated with the Joint IDN Working Group and other community work on this topic. ICANN will also engage with the IETF to coordinate the consideration of technical issues associated with IDN variant TLDs delegation. ICANN is also planning to conduct a workshop at the San Francisco meeting to discuss the Draft Proposal. In this session, representatives from different language communities will be invited to provide an overview of the potential issues with IDN variant TLDs. Document Links: * Draft Proposal: IDN Variant Issues Project [PDF, 393 KB] The Process From Here: At the end of this Public Comment Forum period, ICANN will review the comments submitted and prepare a summary analysis of the various submissions, and consider changes to the work plan based on public comments. Deadline and How to Submit Comments: At the direction of the Board, ICANN is opening a 45-day public consultation forum, from 21 February through 6 April 2011 and invites community comments concerning any/all elements of the proposal for "IDN Variant Issues Project". The formal Public Comment Forum Box is located here: http://www.icann.org/en/public-comment/public-comment-201104-en.htm#idn-var… To submit comments: idn-variant-tld(a)icann.org To view comments: http://forum.icann.org/lists/idn-variant-tld/ Staff Member Responsible: Kurt Pritz Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

New gTLDS: Briefing Papers for ICANN Board-GAC Consultations
by Glen de Saint Géry Feb. 22, 2011

Feb. 22, 2011

http://www.icann.org/en/announcements/announcement-6-21feb11-en.htm New gTLDS: Briefing Papers for ICANN Board-GAC Consultations 21 February 2011 In preparation for the ICANN Board-GAC consultation in Brussels on 28 February and 1 March 2011, ICANN has prepared briefing papers to address the 12 topics identified in the GAC's Cartagena communiqué as "...outstanding and require additional discussion between the Board and the GAC." As some of the topics were considered to overlap or be inter-related, more than one topic is covered in some of the briefing papers. The aim of the briefing papers is to identify the areas of difference which remain between the ICANN Board and the GAC on the nominated topics to focus the discussion on the issues in Brussels. These areas of difference have been identified through the GAC Principles on New gTLDs, GAC communications to the Board on the new gTLD program, and GAC communiqués. There have also been conference calls among ICANN Board, GAC and staff in the past few weeks to confirm the areas of difference. The papers also provide background and ICANN's position on the issues raised. Also attached to most briefing papers is an annex containing reference documents: the first is a summary of actions taken responding to GAC and public comments; and the second is a table which provides a chronological listing of GAC advice and comments on new gTLDs, responses provided by ICANN and key documents published on the topics. Note that the GAC is preparing its own scorecard on these same issues - highlighting GAC consensus positions on the New gTLD Program and where that position differs from the current implementation model. It is expected that the GAC and ICANN papers will differ. The primary purpose of the Brussels consultation is to get joint understanding of specific differences between the GAC and Board positions. Once that understanding is obtained, the parties can work toward a common position. These briefing papers are being posted for information only, so that interested participants will be able to have a sense of the issues to be discussed during the ICANN Board-GAC consultation. They are not being published for public comment. The briefing papers are as follows: Objection Procedures: includes requirements for governments to pay fees; procedures for review of sensitive strings; and early warning to applications-whether a proposed string would be considered controversial or to raise sensitivities (including geographical names) [PDF, 362 KB] Root Zone Scaling (to be provided) Market and Economic Impacts [PDF, 312 KB] Registry-Registrar Separation [PDF, 321 KB] Protection of Rights Owners (trademark protections) [PDF, 273 KB] Consumer Protection Issues (malicious conduct) [PDF, 259 KB] Law Enforcement Due Diligence Recommendations [PDF, 141 KB] Post Delegation Disputes with governments [PDF, 250 KB] Geographic Names: use and protection of geographical names [PDF, 370 KB] Legal Recourse for Applicants [PDF, 170 KB] Providing Opportunities for all Stakeholders [PDF, 256 KB] The Agenda for the meeting is still being finalized. Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Public Comment: Proposed New GNSO Policy Development Process
by Glen de Saint Géry Feb. 21, 2011

Feb. 21, 2011

http://www.icann.org/en/announcements/announcement-3-21feb11-en.htm Public Comment: Proposed New GNSO Policy Development Process PDP-WT presents its Proposed Final Report 21 February 2011 As part of GNSO Improvements, the Policy Development Process (PDP) Work Team (WT) was tasked to develop recommendations for a new GNSO policy development process. ICANN's policies have wide-ranging impact on how domain names are handled in the gTLD environment, so the method of developing the policies matters. Following review of the comments received on its Initial Report and continued deliberations on remaining issues, the PDP-WT now publishes its Proposed Final Report which contains amongst others forty-eight (48) recommendations, an outline of the proposed new Annex A as well as a supporting document that is envisioned to be included in the GNSO Council Operating Procedures as the PDP Manual. Before finalizing its report and submitting it to the GNSO Council for its consideration, the Working Group is asking for your input. The public comment forum will be open until 1 April 2011. For those interested, the PDP-WT will present its report and the proposed new GNSO Policy Development Process at the ICANN meeting in San Francisco (see http://svsf40.icann.org/sched-overview for further details). Key Recommendations * Some of the key recommendations of the new PDP include: o Recommending the use of a standardized "Request for an Issue Report Template" (recommendation 4) o The introduction of a "Preliminary Issues Report" which shall be published for public comment prior to the creation of a Final Issues Report to be acted upon by the GNSO Council (recommendations 10 & 11). o A Requirement that each PDP Working Group operate under a Charter (recommendation 19) o Dialogue between the GNSO Council and an Advisory Committee in the event that an the GNSO Council decides not to initiate a PDP following an Issues Report requested by such Advisory Committee (recommendation 18) o Changing the existing Bylaws requiring a mandatory public comment period upon initiation of a PDP to optional at the discretion of the PDP Working Group (recommendation 22) o Clarification of 'in scope of ICANN policy process or the GNSO' (recommendation 23) o Changing the timeframes of public comment periods including (i) a required public comment period of no less than 30 days on a PDP Working Group's Initial Report and (ii) a minimum of 21 days for any non-required public comment periods the PDP WG might choose to initiate at its discretion (recommendation 28) o Maintaining the existing requirement of PDP Working Groups producing both an Initial Report and Final Report, but giving PDP Working Groups the discretion to produce additional outputs (recommendation 34) o A recommendation allowing for the termination of a PDP prior to delivery of the Final Report (recommendation 37) o Guidance to the GNSO Council on the treatment of PDP WG recommendations (recommendation 39) o New procedures on the delivery of recommendations to the Board including a requirement that all reports presented to the Board are reviewed by either the PDP Working Group or the GNSO Council and made publicly available (recommendation 40) o The use of Implementation Review Teams (recommendation 43) o A redefinition of 'GNSO Supermajority vote' to include the original meaning of GNSO Supermajority i.e. 2/3 of Council members of each house so a GNSO Supermajority vote would be 75% of one House and a majority of the other house or 2/3 of Council members of each house (recommendation 48) For a complete overview of all the recommendations, please see Section 2 of the Proposed Final Report. Background On 26 June 2008 the ICANN Board approved a set of recommendations designed to improve the effectiveness of the GNSO, including its policy activities, structure, operations, and communications. The following pertains to the PDP-WT's mission: Revising the PDP: The Policy Development Process (PDP) needs to be revised to make it more effective and responsive to ICANN's needs. It should be brought in-line with the time and effort actually required to develop policy and made consistent with ICANN's existing contracts (including, but not limited to, clarifying the appropriate scope of GNSO "consensus policy" development). While the procedure for developing "consensus policies" will need to continue to be established by the Bylaws as long as required by ICANN's contracts, the GNSO Council and Staff should propose new PDP rules for the Board's consideration and approval that contain more flexibility. The new rules should emphasize the importance of the preparation that must be done before launch of a working group or other activity, such as public discussion, fact-finding, and expert research in order to properly define the scope, objective, and schedule for a specific policy development goal and the development of metrics for measuring success. The charter of the PDP-WT is to develop and document a revised GNSO Policy Development Process that achieves the goals established by the ICANN Board. The PDP-WT, with staff assistance, will need to determine what changes to the bylaws will be required. New processes will need to be documented properly to ensure that the bylaws (and any related operational rules or procedures) are updated accurately. The revised PDP, after review and approval by the PPSC, GNSO Council, and ICANN Board, would replace the current PDP defined in Annex A of the ICANN bylaws. Further Information PDP-WT Proposed Final Report - http://gnso.icann.org/issues/pdp-wt-proposed-final-report-21feb11-en.pdf [PDF, 1.21 MB] PDP-WT Proposed Final Report - Executive Summary Only - http://gnso.icann.org/issues/pdp-wt-executive-summary-proposed-final-report… [PDF, 580 KB] PDP-WT Proposed Final Report - without annexes - http://gnso.icann.org/issues/pdp-wt-proposed-final-report-no-annexes-21feb1… [PDF, 998 KB] PDP-WT Initial Report - http://gnso.icann.org/issues/pdp-initial-report-31may10-en.pdf [PDF, 2.36 MB] PDP-WT Workspace - https://st.icann.org/icann-ppsc/index.cgi?pdp_team GNSO Improvements - http://gnso.icann.org/en/improvements/ Deadline and how to submit comments Comments are welcome via e-mail to gnso-pdp-final-report(a)icann.org until 1 April 2011. Access to the public comment forum from which comments can be posted can be found at http://www.icann.org/en/public-comment/public-comment-201104-en.htm#gnso-pd… An archive of all comments received will be publicly posted at http://forum.icann.org/lists/gnso-pdp-final-report/. Staff responsible: Marika Konings Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Public Comment: Post-Expiration Domain Name Recovery Working Group Presents Its Proposed Final Report
by Glen de Saint Géry Feb. 21, 2011

Feb. 21, 2011

http://www.icann.org/en/announcements/announcement-2-21feb11-en.htm Public Comment: Post-Expiration Domain Name Recovery Working Group Presents Its Proposed Final Report Your Input Requested on Fourteen (14) Recommendations 21 February 2011 The GNSO Post-Expiration Domain Name Recovery (PEDNR) Policy Development Process Working Group was tasked to address questions in relation to what extent registrants should be able to renew their domain names after they expire. At issue is whether the current policies of registrars on the renewal, transfer and deletion of expired domain names are adequate. Following review of the comments received on its Initial Report and further deliberations, the Working Group now presents its Proposed Final Report, which contains fourteen (14) recommendations to address the five charter questions it was assigned. Before finalizing its report and submitting it to the GNSO Council for its consideration, the Working Group is asking for your input on the proposed Final Report, especially the proposed recommendations. The public comment forum will be open for 45 days (until 7 April 2011). For those interested, the PEDNR Working Group will present its report and proposed recommendations at the ICANN meeting in San Francisco (see http://svsf40.icann.org/sched-overview for further details). The Recommendations (abbreviated version) The full recommendations including rationales and other comments can be found in the proposed Final Report. Recommendation #1: Define "Registered Name Holder at Expiration" (RNHaE) to clearly identify the entity or individual that was eligible to renew the domain name registration immediately prior to expiration. Recommendation #2: Provide a minimum of 8 days after expiration when the RNHaE can renew, and disable normal operation during that time to attract the attention of the RNHaE. Recommendation #3: Changes to WHOIS after expiration must not alter the RNHaE ability to renew. Recommendation #4: All unsponsored gTLD Registries shall offer the Redemption Grace Period (RGP). Recommendation #5: If a Registrar offers registrations in a gTLD that supports the RGP, the Registrar must allow the Registered Name Holder at Expiration to redeem the Registered Name after it has entered RGP. Recommendation #6: Registrar website should state any fee(s) charged for the post-expiration renewal of a domain name. Recommendation #7: Registrars who have a web presence, shall provide a link to ICANN published web content providing educational materials with respect to registrant responsibilities and the gTLD domain life-cycle. Recommendation #8: ICANN, with the support of Registrars, ALAC and other interested parties, is to develop educational materials about how to properly steward a domain name and how to prevent unintended loss. Recommendation #9: The registration agreement and Registrar web site (if one is used) must clearly indicate what methods will be used to deliver pre- and post-expiration notifications. Recommendation #10: Registrar must notify Registered name Holder of impending expiration no less than two times. Subject to an exceptions policy, the timing of such notices is specified. Recommendation #11: Notifications of impending expiration must include method(s) that do not require explicit action other than standard e-mail receipt in order to receive such notifications. Recommendation #12: Unless the Registered Name is deleted by the Registrar, at least one notification must be sent after expiration. Recommendation #13: If at any time after expiration when the Registered Name is still renewable by the RNHaE, the Registrar changes the DNS resolution path to effect a different landing website than the one used by the RNHaE prior to expiration, the page shown must explicitly say that the domain has expired and give instructions on how to recover the domain. Recommendation #14: Best Practice: If post-expiration notifications are normally sent to a point of contact using the domain in question, and delivery is known to have been interrupted by post-expiration actions, post-expiration notifications should be sent to some other contact point associated with the registrant if one exists. Deadline and how to submit comments Comments are welcome via e-mail to pednr-proposed-final-report(a)icann.org until 7 April 2011. Access to the public comment forum from which comments can be posted can be found at: http://www.icann.org/en/public-comment/public-comment-201104-en.htm#pednr-p… An archive of all comments received will be publicly posted: http://forum.icann.org/lists/pednr-proposed-final-report/ Further information: * PEDNR PDP Proposed Final Report [PDF, 972 KB] * PEDNR PDP Proposed Final Report - Executive Summary only [PDF, 376 KB] * PEDNR PDP Initial Report [PDF, 1.02 MB] * PEDNR PDP Initial Report - Executive Summary o English [PDF, 128 KB] * PEDNR WG workspace Background At the ICANN Meeting in Cairo in November 2008, the At-Large Advisory Committee (ALAC), voted to request an Issues Report on the subject of registrants being able to recover domain names after their formal expiration date. The ALAC request was submitted to ICANN policy staff and the GNSO Council on 20 November 2008. The Issues Report on Post-Expiration Domain Name Recovery [PDF, 422 KB] was submitted to the GNSO Council on 5 December 2008. The GNSO Council initiated a PDP on 7 May 2009 and tasked a Working Group to answer the following charter questions: * Whether adequate opportunity exists for registrants to redeem their expired domain names; * Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough; * Whether adequate notice exists to alert registrants of upcoming expirations; * Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold status, a notice on the site with a link to information on how to renew, or other options to be determined); * Whether to allow the transfer of a domain name during the RGP. The Post-Expiration Domain Name Recovery (PEDNR) PDP Working Group started its deliberations in July 2009. Staff responsible: Marika Konings Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Public Comment: Inter-Registrar Transfer Policy Part B Working Group Presents Proposed Final Report
by Glen de Saint Géry Feb. 21, 2011

Feb. 21, 2011

http://www.icann.org/en/announcements/announcement-21feb11-en.htm Public Comment: Inter-Registrar Transfer Policy Part B Working Group Presents Proposed Final Report Nine (9) Recommendations for Community Consideration 21 February 2011 The GNSO Inter-Registrar Transfer Policy (IRTP) Part B Policy Development Process Working Group was tasked to address five issues focusing on issues related to domain hijacking, the urgent return of an inappropriately transferred name and "lock status". Following review of the public comments received on the Initial Report and further deliberations, the Working Group now presents its proposed Final Report which contains nine (9) recommendations to address the five charter questions it was tasked with. Before finalizing its report and submitting it to the GNSO Council for its consideration, the Working Group is asking for your input on the proposed Final Report, especially the proposed recommendations. Comments can be submitted until 31 March 2011. For those interested, the IRTP Part B Working Group will present its report and proposed recommendations at the ICANN meeting in San Francisco (see http://svsf40.icann.org/sched-overview for further details). The Recommendations Recommendation #1: The WG is considering recommending requiring registrars to provide an Emergency Action Channel (as described in SAC007 [PDF, 400 KB]). The WG recognizes that there are further details that would need to be worked out in relation to this proposal such as: Within what timeframe should a response be received after an issue has been raised through the Emergency Action Channel (for example, 24 hours - 3 days has been the range discussed by the WG)? What qualifies as 'a response'? Is an auto-response sufficient? Should there be any consequences when a response is not received within the required timeframe? Is there a limited time following a transfer during which the Emergency Action Channel can be used? Which issues may be raised through the Emergency Action Channel? How/who should document the exchanges of information on the Emergency Action Channel? Who is entitled to make use of the Emergency Action Channel? The WG is requesting input from the ICANN Community on these questions and the recommendation itself, so this can be factored into the WG deliberations going forward. Recommendation #2: The WG notes that in addition to reactive measures such as outlined in recommendation #1, proactive measures to prevent hijacking are of the utmost importance. As such, the WG strongly recommends the promotion by ALAC and other ICANN structures of the measures outlined in the recent report of the Security and Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). In particular, the IRTP WG recommends that registrants consider the measures to protect domain registrar accounts against compromise and misuse described in SAC044, Section 5. These include practical measures that registrants can implement "in house", such as ways to protect account credentials and how to incorporate domain name registrations into employee or resource management programs typically found in medium and large businesses. It suggests ways that registrants can use renewal and change notifications from registrars as part of an early warning or alerting system for possible account compromise. Recommendation #3: The WG recommends requesting an Issues Report on the requirement of 'thick' WHOIS for all incumbent gTLDs. The benefit would be that in a thick registry one could develop a secure method for a gaining registrar to gain access to the registrant contact information. Currently there is no standard means for the secure exchange of registrant details in a thin registry. In this scenario, disputes between the registrant and admin contact could be reduced, as the registrant would become the ultimate approver of a transfer. Such an Issue Report and possible subsequent Policy Development Process should not only consider a possible requirement of 'thick' WHOIS for all incumbent gTLDs in the context of IRTP, but should also consider any other positive and/or negative effects that are likely to occur outside of IRTP that would need to be taken into account when deciding whether a requirement of 'thick' WHOIS for all incumbent gTLDs would be desirable or not. Recommendation #4: The WG notes that the primary function of IRTP is to permit Registered Name Holders to move registrations to the Registrar of their choice, with all contact information intact. The WG also notes that IRTP is widely used in the domain name community to affect a "change of control," moving the domain name to a new Registered Name Holder. The discussions within the WG and with ICANN Staff have determined that there is no defined "change of control" function. Therefore, the IRTP-B WG recommends requesting an Issue Report to examine this issue, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space, and any associated security concerns. Recommendation #5: The WG recommends modifying section 3 of the IRTP to require that the Registrar of Record/Losing Registrar be required to notify the Registered Name Holder/Registrant of the transfer out. The Registrar of Record has access to the contact information for the Registrant and could modify their systems to automatically send out the Standardized Form for Losing Registrars ("Confirmation FOA") to the Registrant. Recommendation #6: The WG does recognize that the current language of denial reason #6 is not clear and leaves room for interpretation especially in relation to the term 'voluntarily' and recommends therefore that this language is expanded and clarified to tailor it more to explicitly address registrar-specific (i.e. non-EPP) locks in order to make it clear that the registrant must give some sort of informed opt-in express consent to having such a lock applied, and the registrant must be able to have the lock removed upon reasonable notice and authentication. The WG recommends to modify denial reason #6 as follows: Express objection to the transfer by the Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the Transfer Contact on an opt-in basis and upon request by the Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the Transfer Contact to remove the lock within five (5) calendar days. Recommendation #7: The WG recommends that if a review of the UDRP is conducted in the near future, the issue of requiring the locking of a domain name subject to UDRP proceedings is taken into consideration. Recommendation #8: The WG recommends standardizing and clarifying WHOIS status messages regarding Registrar Lock status. The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Based on discussions with technical experts, the WG does not expect that such a standardization and clarification of WHOIS status messages would require significant investment or changes at the registry/registrar level. The WG recommends that ICANN staff is asked to develop an implementation plan for community consideration which ensures that a technically feasible approach is developed to implement this recommendation. Recommendation #9: The WG recommends deleting denial reason #7 as a valid reason for denial under section 3 of the IRTP as it is technically not possible to initiate a transfer for a domain name that is locked, and hence cannot be denied, making this denial reason obsolete. Instead denial reason #7 should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked. The WG recommends that ICANN staff is asked to develop an implementation plan for community consideration including proposed changes to the IRTP to reflect this recommendation. Background The IRTP Part B Policy Development Process (PDP) is the second in a series of five PDPs that address areas for improvements in the existing Inter-Registrar Transfer Policy. The Inter-Registrar Transfer Policy (IRTP) aims to provide a straightforward procedure for domain name holders to transfer their names from one ICANN-accredited registrar to another should they wish to do so. The policy also provides standardized requirements for registrar handling of such transfer requests from domain name holders. The policy is an existing community consensus policy that was implemented in late 2004 and is now being reviewed by the GNSO. Deadline and how to submit comments Comments are welcome via e-mail to irtp-b-proposed-final-report(a)icann.org until 31 March 2011. Access to the public comment forum from which comments can be posted can be found at: http://www.icann.org/en/public-comment/public-comment-201103-en.htm#irtp-b-… An archive of all comments received will be publicly posted at: http://forum.icann.org/lists/irtp-b-proposed-final-report/ Further information IRTP Part B PDP Proposed Final Report [PDF, 734 KB] IRTP Part B PDP Proposed Final Report - Executive Summary only [PDF, 320 KB] IRTP Part B PDP Initial Report [PDF, 765 KB] Inter-Registrar Transfer Policy (IRTP) Staff responsible: Marika Konings Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Proposed IRTP Part B Final Report Published
by Marika Konings Feb. 21, 2011

Feb. 21, 2011

Dear All, For your information, the proposed IRTP Part B Final Report has been published and the public comment forum is open until 31 March (see http://www.icann.org/en/announcements/announcement-21feb11-en.htm and http://www.icann.org/en/public-comment/public-comment-201103-en.htm#irtp-b-…) The IRTP Part B WG is scheduled to provide an overview of the report and the recommendations to the GNSO Council during its weekend session in San Francisco. With best regards, Marika

1 0

Reminder:Policy Update Webinar invitation
by Glen de Saint Géry Feb. 21, 2011

Feb. 21, 2011

PRE-SAN FRANCISCO ICANN POLICY UPDATE WEBINAR INVITATION In order to participate, please RSVP via email to the GNSO Secretariat (gnso.secretariat(a)gnso.icann.org<mailto:gnso.secretariat@gnso.icann.org>) to receive the call details. Whether you plan to participate in the upcoming ICANN meeting in San Francisco remotely or in person, you're invited to a quick reminder of the background and current status of each major policy issue currently under discussion in ICANN. The ICANN Policy Staff will provide a briefing on Thursday 3 March at 13.00 and 20.00 UTC, summarizing policy issues across the different ICANN Supporting Organizations, namely the Generic Names Supporting Organization (GNSO), Country Code Names Supporting Organization (ccNSO) and Address Supporting Organization (ASO). Amongst other topics, updates will be provided on: - Registration Abuse Policies Recommendations (GNSO) - New gTLD Recommendation 6 WG - Post-Expiration Domain Name Recovery (GNSO) - Recent WHOIS work - Country names study group (ccNSO) - Delegation and Re-delegation Working Group (ccNSO) - Joint DNS Security and Stability Analysis Working Group - Global policy for handling recovered IPv4 address space (ASO) The two sessions are duplicates, scheduled to accommodate different time zones. Each session, scheduled to run for 90 minutes, will be conducted in English only. The meeting will be run in Adobe Connect with a slide presentation along with a dial-in conference bridge for audio. Participants will have opportunity to ask questions at the end of each session. During the course of the webinar, questions may be submitted using the chat function of Adobe Connect. If you are not able to participate in either of the live sessions, the slides and MP3 will be made available shortly after the meeting. The policy staff is always available to answer any questions that you email to policy-staff(a)icann.org<mailto:policy-staff@icann.org>. In order to participate, please RSVP via email to the GNSO Secretariat (gnso.secretariat(a)gnso.icann.org<mailto:gnso.secretariat@gnso.icann.org>) to receive the call details. Please indicate which call you would like to join, 13.00 UTC or 20.00 UTC (to convert those times into your local time, see: http://www.timeanddate.com/worldclock/fixedform.html) We will send you an e-mail reminder before the event with log-in and dial-in details. Please DO NOT RSVP to any other ICANN staff members e-mail address.

1 0

SO/AC Chair Roundtable and Dinner
by Stéphane Van Gelder Feb. 21, 2011

Feb. 21, 2011

Councillors, I wanted to update you on the discussion that is due to happen between the SO/AC Chairs and Rod prior to the SF meeting. Here is some information I have received about this from Rod: "Based on the input received, we are now planning a two- hour informal roundtable for the SO/AC Chairs on Friday, March 1. Following the SO/AC roundtable, I am pleased to host a dinner. As I have noted to some of you, for several ICANN meetings now, I wished to find more time to have the Chairs come together with me to exchange views on their activities and programs for the future. As this has been a scheduling challenge during the midst of the public meetings, I asked David Olive, Vice President for Policy Development Support to investigate whether we might find some time just prior to the March ICANN meeting. I am glad to know that March 11 turns out to be the best time to get together. The goal is to have an informal discussion of what the SO/AC Chairs hope to see as the most significant challenges/opportunities for ICANN and how we could work better together on sharing information about SO/AC priorities." Stéphane

1 0

GNSO SF schedule
by Olga Cavalli Feb. 21, 2011

Feb. 21, 2011

Hi, attached you can find an updated version of the GNSO SF schedule, including the suggested changes. Please note that there are meetings and activities still to be confirmed or defined. (marked yellow) Let me know if we have missed something or if there is any other change to be done. Best regards Olga

1 0