ATT: for BC call tomorrow: Draft Agenda for GNSO Council Meeting - 15 December 2011 at 20:00UTC
Posting the Agenda for the GNSO Council meeting for FYI for members, in preparation for tomorrow's BC members call. We will push to conclude this call in an hour. Some information will be sent separately on background/and status on motions: Motions:I call attention to the UDRP issue: my understanding is that the IPC has developed a 'friendly amendment'. I would ask Zahid to post that to the BC list for information for the members.I am not sure it will be accepted as 'friendly', so the BC Councilors will want to discuss it with the members. Outreach Proposal. John Berard has been 'sherping' a motion that was summitted within the time frame, that would a) thank the previous TF and the former chairb) ask staff [not policy staff] to gather, compile, and summarize existing outreach and participation activities, materials, and include the incoming requests from Constituencies/SGs into the Budget/Operating Plan; and the initiative that Kurt Pritz is briefing the Chairs of the Constituencies/SGs/ ALAC, and SOs next week, but just before the Council meets. c) delay any further GNSO Council discussions until after that summary is provided to the GNSO's constituencies/SGs; GNSO Council, ALAC, GAC, SOs, and Public Participation Committee. I did a lot of the work on that motion, with John's excellent editing and improving. We can discuss the status and probabilities for that motion. Item 6: this item probably needs some attention and thought by all of us. Fraud and abuse is of high interest to many of our BC members. Finally, as noted in an earlier email, Steve DelBianco and I are working on a letter that summarizes the four items the BC has identified for further improvements in the new gTLD Guidebook/before launch of the new gTLD program. I look forward to talking to all of you tomorrow. Marilyn CadeBC Chair -------------------- Agenda for GNSO Council Meeting - 15 December 2011http://gnso.icann.org/meetings/agenda-council-15dec11-en.htmWiki Agendahttps://community.icann.org/display/gnsocouncilmeetings/Agenda+15+December+2... agenda was established according to the GNSO Council Operating Procedures approved 22 September 2011 for the GNSO Council. http://gnso.icann.org/council/gnso-operating-procedures-22sep11-en.pdfFor convenience:* An excerpt of the ICANN Bylaws defining the voting thresholds is provided in Appendix 1 at the end of this agenda. * An excerpt from the Council Operating Procedures defining the absentee voting procedures is provided in Appendix 2 at the end of this agenda.Meeting Time 20:00 UTCCoordinated Universal Time: 20:00 UTC12:00 Los Angeles; 15:00 Washington DC; 20:00 London; 21:00 Paris;16 December 2011 05:00 Tokyo; 09:00 WellingtonDial-in numbers will be sent individually to Council members. Councilors should notify the GNSO Secretariat in advance if a dial out call is needed.GNSO Council meeting audiocast http://stream.icann.org:8000/gnso.m3uItem 1: Administrative matters (10 minutes)Roll Call 1.2 Statement of interest updates· Mason Cole https://community.icann.org/display/gnsosoi/Mason+Cole+SOI 1.3 Review/amend agenda 1.4. Note the status of minutes for the previous Council meeting per the GNSO Operating Procedures:· 17 November minutes – will be approved on 8 December 2011. . Item 2: GNSO Pending Projects List (5 minutes)Standard agenda item looking at changes made to the GNSO's Pending Projects list since the previous meeting. Refer to Pending Projects list http://gnso.icann.org/meetings/pending-projects-list.pdf2.1 Changes to Pending Projects List since last Council meeting (Stéphane Van Gelder)• GNSO activities: 9 (9 - No change). • Other activities: 10 (11 - Deleted: RAP, request to ICANN Compliance complete) • Joint SO/AC WGs: 7 (7 - no change). • Outstanding recommendations: 2 (2 - no change).Item 3: Outreach Task Force Charter (20 minutes)As part of the GNSO improvements, the Operations Steering Committee (OSC)'s Constituency and Stakeholder Group Operations Work Team worked on a set of recommendations on a global outreach programAt the previous Council meeting, a motion on this was not approved. It was proposed that a small group be assisted by Staff to produce a new motion that would include specific revisions to the charter.Refer to motion:https://community.icann.org/display/gnsocouncilmeetings/Motions+15+December+... Reading of the motion (Zahid Jamil) 3.1 Discussion3.2 Vote3.3 Next stepsItem 4: UDRP (25 minutes)Following the drafting of an Issue Report on a possible review of the UDRP, a motion is before the Council to initiate a PDP on this topic and that a drafting team be formed to write a charter for the working group.Refer to motion https://community.icann.org/display/gnsocouncilmeetings/Motions+15+December+... motion was deferred from the Nov 17 Council meeting.4.1 Reading of the motion (Jeff Neuman) 4.2 Discussion 4.3 Vote Item 5: Joint ccNSO/GNSO IDN Working Group (JIG) (15 minutes) The JIG is proposing that both GNSO and ccNSO councils ask their Chairs to send to the ICANN Board a letter in response to their August 2011 resolution on Single Character IDN TLDs.The letter would note discrepancies between the WG's work and the Board resolution.Refer to motion https://community.icann.org/display/gnsocouncilmeetings/Motions+15+December+... Reading of the motion (Ching Chiao) 5.2 Discussion 5.3 VoteItem 6: Cross-TLD registration scam and domain kiting (10 minutes)At the previous Council meeting, there was discussion on possible next steps and decisions that could be made on this topic, following SSAC's response (http://gnso.icann.org/correspondence/gnso-council-chair-to-faltstrom-10oct11...) .Staff has suggested several options: Adding these issues to the mandate of the Fake Renewal Notices Drafting Team which is tasked to prepare a request for information for the Registrar Stakeholder Group to obtain further information on the issue of Fake Renewal Notices in order to help inform the GNSO Council on the appropriate next steps, if any. As there are certain similarities, especially between the cross-tld registration scam and fake renewal notices, it might be possible for this DT to also try and obtain further information on that specific issue to help inform the Council's deliberations.Continue discussions on the topic of cross-TLD registration scam with the ccNSO to discuss whether there are any steps that could be taken or considered jointly. The GNSO Council and the ccNSO Council had some initial discussions on this topic at its meeting in Dakar and as this is an issue that also affects ccTLDs there might be common approaches to be explored. As noted, such approaches might involve improved communication / education in relation to this issue as it is not clear at this stage that this issue could be addressed through policy development.Do nothing – as there is no set mechanism for data gathering or monitoring of abuses at the moment or any evidence that these practices are in non-compliance with ICANN policies or agreements, the GNSO Council could decide to not undertake any further action at this stage. Note, at any point in time, should further information or data become available, any Council member or SO/AC could raise this issue again for further consideration. This discussion item aims at seeing if this issue should be closed or if work should continue.6.1 Discussion 6.2 Next steps Item 7: Joint SO/AC WG on New gTLD Applicant Support Working Group (JAS WG) (10 minutes) This agenda item is to update the Council on recent developments in the JAS WG, and more specifically details of the measures being taken to implement the recommendations made in the JAS Final Report that was sent to the Board.7.1 Update from Staff (X Y) 7.2 DiscussionItem 8: Transitioning existing PDP work to the new PDP procedures (10 minutes) At its meeting on December 8, 2011, the Board adopted the new GNSO PDP.Out of that comes the following text: 'For all ongoing PDPs initiated prior to the adoption by the Board, the Council shall determine the feasibility of transitioning to the procedures set forth in this Annex A for all remaining steps within the PDP. If the Council determines that any ongoing PDP cannot be feasibly transitioned to these updated procedures, the PDP shall be concluded according to the procedures set forth in Annex A in force on before the adoption of the new Annex A by the Board'.Currently the following PDPs are under way:- IRTP Part C (Working Group)- Thick Whois (Preliminary Issue Report out for public comment)- RAA (Preliminary Issue Report in preparation)- Uniformity of Contracts (Preliminary Issue Report in preparation)- UDRP (pending)- Law Enforcement recommendations (pending)8.1 Update from Staff (Margie Milam) 8.2 Discussion 8.3 Next stepsItem 9: Any Other Business (5 minutes)Appendix 1: GNSO Council Voting Thresholds (ICANN Bylaws, Article X, Section 3)9. Except as otherwise specified in these Bylaws, Annex A hereto, or the GNSO Operating Procedures, the default threshold to pass a GNSO Council motion or other voting action requires a simple majority vote of each House. The voting thresholds described below shall apply to the following GNSO actions:1. Create an Issues Report: requires an affirmative vote of more than 25% vote of each House or majority of one House; 2. Initiate a Policy Development Process (“PDP”) Within Scope (as described in Annex A): requires an affirmative vote of more than 33% of each House or more than 66% of one House; 3. Initiate a PDP Not Within Scope: requires an affirmative vote of more than 75% of one House and a majority of the other House (“GNSO Supermajority”); 4. Approve a PDP Recommendation Without a GNSO Supermajority: requires an affirmative vote of a majority of each House and further requires that one GNSO Council member representative of at least 3 of the 4 Stakeholder Groups supports the Recommendation; 5. Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO Supermajority; and 6. Approve a PDP Recommendation Imposing New Obligations on Certain Contracting Parties: where an ICANN contract provision specifies that “a two-thirds vote of the council” demonstrates the presence of a consensus, the GNSO Supermajority vote threshold will have to be met or exceeded with respect to any contracting party affected by such contract provision.Appendix 2: Absentee Voting Procedures (GNSO Operating Procedures 4.4) 4.4.1 Applicability Absentee voting is permitted for the following limited number of Council motions or measures. a. Initiate a Policy Development Process (PDP); b. Approve a PDP recommendation; c. Recommend amendments to the GNSO Operating Procedures (GOP) or ICANN Bylaws; d. Fill a Council position open for election.4.4.2 Absentee ballots, when permitted, must be submitted within the announced time limit, which shall be 72 hours from the meeting‟s adjournment. In exceptional circumstances,announced at the time of the vote, the Chair may reduce this time to 24 hours or extend the time to 7 calendar days, provided such amendment is verbally confirmed by all Vice-Chairs present.4.4.3 The GNSO Secretariat will administer, record, and tabulate absentee votes according to these procedures and will provide reasonable means for transmitting and authenticating absentee ballots, which could include voting by telephone, e- mail, web-based interface, or other technologies as may become available. 4.4.4 Absentee balloting does not affect quorum requirements. (There must be a quorum for the meeting in which the vote is initiated.) ---------------------------------------------------------------------------- Local time between October & March, Winter in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 20:00 ---------------------------------------------------------------------------- California, USA (PST) UTC-8+0DST 12:00 New York/Washington DC, USA (EST) UTC-5+0DST 15:00 Buenos Aires, Argentina (ART) UTC-3+0DST 17:00 Montevideo, Uruguay (UYST) UTC-3+1DST 18:00 London, United Kingdom (BST) UTC+0DST 20:00 Abuja,Nigeria (WAT) UTC+1+0DST 21:00 Tunis, Tunisia (CET) UTC+1+0DST 21:00 Bonn, Germany (CET) UTC+1+0DST 21:00 Paris, France (CET) UTC+1+0DST 21:00 Ramat Hasharon, Israel(IST) UTC+2+0DST 22:00 Karachi, Pakistan (PKT ) UTC+5+0DST 01:00 next day Beijing, China (CST ) UTC+8+0DST 04:00 next day Tokyo, Japan (JST) UTC+9+0DST 05:00 next day Wellington, New Zealand (NZDT ) UTC+12+1DST 09:00 next day ---------------------------------------------------------------------------- The DST starts/ends on last Sunday of March 2012, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places see http://www.timeanddate.com Glen de Saint GéryGNSO Secretariatgnso.secretariat@gnso.icann.orghttp://gnso.icann.org
Here is a follow-up to Marilyn's final agenda item for today's BC member call: Finally, as noted in an earlier email, Steve DelBianco and I are working on a letter that summarizes the four items the BC has identified for further improvements in the new gTLD Guidebook/before launch of the new gTLD program. Below (and attached) is a draft of specific adjustments the BC could request in the gTLD expansion. We hope to discuss on today's call. 1) Ensure that ICANN can enforce all registry restrictions and commitments made to potential objectors. A key commitment that ICANN made to GAC members was to allow early warnings and objections to proposed TLDs that may offend cultural, religious or national sensibilities. However, the BC is concerned that the Implementation approach in the Guidebook won't empower ICANN to deliver on that commitment. While ICANN is asking governments and other stakeholders to base their response to proposed strings on the proposed commitments in the application, those terms won't actually be enforceable unless they are included as part of the formal Registry Agreement. For ICANN to enforce such restrictions, theymust be included in the TLD registry agreements, and ICANN Compliance and Enforcement must accept responsibility for enforcement of said commitments. ICANN needs to require that commitments included in the application are included as measurable and enforceable elements in the gTLD registry agreement. This loophole should be closed before the first applications areaccepted, or ICANN risks breaking a commitment made to governments and other users. 2) Ensure that this gTLD expansion includes TLDs serving multiple languages and scripts. Internationalized domain names (IDNs) are the major benefit ICANN has described to global Internet users, as required in the Affirmation of Commitments. IDNs have great potential to reach the next billion globalInternet users, most of whom don't use the Latin alphabet as their primary script for reading and writing. However, based on current activity in the new gTLD applicant community, it appears that IDN applications will represent only a small fraction of the total applicant pool, thereby leaving underserved linguistic groups behind. The BC and other ICANN stakeholders have offered proposals to increase IDNs in this round, but ICANN’s Board and management have thus far shown little interest. ICANN should include incentives and other ways to encourage applicants to offer additional versions of their gTLD in underserved scripts and languages. ICANN staff has already acknowledged costs savings of consolidating the applicant and technical evaluations for applicants whopropose multiple versions of their gTLD. To encourage the applicants of ASCII and IDN strings to offer additional scripts for their string, those cost savings could be passed along to the applicant as an incentive to serve smaller linguistic communities that might not otherwise be served. Furthermore, applicants who propose multiple language and IDN strings should not be penalized by strict string similarity tests that prevent additional linguistic versions of their gTLD; linked gTLD strings should bekept together if ICANN processes applications in separate batches. ICANN must take seriously its commitment to serve global Internet users, and IDN prioritization is essential to meet that commitment. 3) Rights protection mechanisms (RPMs) must be monitored for effectiveness. If an RPM is working effectively, it should be extended; if an RPM is not effective, ICANN must be prepared to adjust or expand the mechanism. The issue of rights protection and fraud prevention has been a centerpiece of the new gTLD debate, and still dominates discussion about the program outside of the ICANN community. The Internet ecosystem includes businesses – large and small – that are actually driving e-commerce and online services. Those businesses should be supporting an expansion of domains toserve global registrants and users. But today, many businesses are not supportive of the new gTLD program, or are calling for Guidebook improvements not previously addressed. And some want to stop the new gTLD program altogether. The ICANN community developed a suite of rights protections mechanisms (RPMs) to minimize costs of defensive registrations and mitigate the risk of fraud and abuse in new gTLDs. But most of these new RPMs are untested and must therefore be closely monitored and adjusted to achieve their intended effect. The BC recommends that ICANN make the following adjustments to RPMs: A. Protect consumers and registrants by requiring TM claims notices beyond the first 60 days of each gTLD debut. In the present approach, trademark claims notices — based on names accepted in the Trademark Clearinghouse database – are only required for 60 days after the launch of each new gTLD. If TM notices are effective at reducing abusive registrations, it makes no sense to stop giving these notices once a gTLD is 60 days old. If TM claims are working as expected, ICANN should require them to continue indefinitely. Moreover, ICANN should embrace its responsibility to provide access to a centralized TM clearinghouse database at minimal cost to registrars and registries. If TM claims notices are not effective in preventing cybersquatting and fraudulent registrations in new gTLDs, ICANN should be ready to implement additional RPMs based on the TM Clearinghouse database. B. Extend Sunrise Periods to a minimum of 60 days. Even if the Sunrise Registration Process is highly effective, it may not be possible for TM owners to use the process effectively if dozens of new gTLDs are conducting their Sunrise simultaneously for just the required minimum of 30 days. ICANN should extend the length of Sunrise services to a standard period of 60 days required by all new gTLDs. A standardized approach in process will minimize confusion for those who seek to use such services. C. The Uniform Rapid Suspension (URS) process should be centralized under ICANN supervision. For the URS to have its intended effect, ICANN should initiate URSwith a single, proven provider such as WIPO, at least for an initial two year period. Other vendors could later be approved to provide URS services, but only after ICANN has compiled a record of experience, effectiveness, and reasonable costs. Moreover, the disposition of URS cases must be monitored for effectiveness. If it turns out that most domains subject to a URS take-down are quickly re-registered by others, the URS disposition should be adjusted to allow a transfer of the domain to the TM holder, for an additional fee. 4) Amend the Registrar Accreditation Agreement for registrars distributing names in new gTLDS. The new gTLD program offers a unique opportunity to strengthenICANN's contractual agreements with registrars who will sell and manage names in new TLDs. When millions of new registrants enter the market, it is the registrars — not registries — they will be dealing with. New TLDs are just as important for registrars as for registries, especially now that cross-ownership and vertical integration are permitted. Citing urgency to address law enforcement issues, ICANN’s Board adopted a resolution in the ICANN meeting in Dakar, in October 2011, directing RAA negotiations to commence immediately. While ICANN has a prolonged process for amending existing contracts like theRAA, these negotiations can quickly generate a new RAA covering new gTLDs. Ideally, ICANN should require registrars to comply with an improved RAA in order to gain accreditation to distribute names in the new gTLDs. At a minimum, ICANN should encourage each new gTLD registry to require this improved RAA for any registrar distributing or managing domain names in the new gTLDs. Improve the Communications Plan for new gTLDs: The adjustments described above are achievable within the present implementation plan for new gTLDs. And these improvements should also be featured in ICANN’s new gTLD communications plan – which is still significantly lacking in detail, despite its critical importance to global Internet users. The BC remains concerned that the Communications Plan does not sufficiently inform Internet users about the implications of this massive expansion of the domain space. Commit to a Second Round of new gTLDs: ICANN should also commit to open a second round for new gTLDs at adate certain, based upon evaluations and improvements to conditions for a second round. The dates can be contingent on first round milestones and adjustments, but the commitment must be firm enough to provide assurance to potential applicants that they can obtain a gTLD in a second round. Taking these further steps will reduce the burdens and costs that the gTLD expansion would impose on existing registrants, to businesses, and to NGOs. ICANN’s business constituency understands the critical importance of a well-executed expansion of new top level domains.
participants (2)
-
Marilyn Cade -
Steve DelBianco