- Bc-gnso - lists.icann.org

for consideration, as an alternative way to amend the RAA
by Steve DelBianco Oct. 22, 2011

Oct. 22, 2011

In Saturday's GNSO Work Session, we debated how to proceed amending<http://gnso.icann.org/issues/raa/r%20aa-improvements-proposal-final-%20repo…> the RAA. Contract parties are not willing to accept the process motion <https://community.icann.org/display/gnsocouncilmeetings/Motions+26+October+…> offered by Kristina Rosette and supported by the BC. Jeff Neuman (RySG) then suggested that Council adopt an amendment process that matches the Registry Agreement amendment process, as described in new gTLD Guidebook, Module 5<http://www.icann.org/en/topics/new-gtlds/agreement-specs-clean-19sep11-en.p…>, section 7.6 (below). Jeff basically suggested copying this section and changing Registry to Registrar. 7.6 Amendments and Waivers. (a) If ICANN determines that an amendment to this Agreement (including to the Specifications referred to herein) and all other registry agreements between ICANN and the Applicable Registry Operators (the “Applicable Registry Agreements”) is desirable (each, a “Special Amendment”), ICANN may submit a Special Amendment for approval by the Applicable Registry Operators pursuant to the process set forth in this Section 7.6, provided that a Special Amendment is not a Restricted Amendment (as defined below). Prior to submitting a Special Amendment for such approval, ICANN shall first consult in good faith with the Working Group (as defined below) regarding the form and substance of a Special Amendment. The duration of such consultation shall be reasonably determined by ICANN based on the substance of the Special Amendment. Following such consultation, ICANN may propose the adoption of a Special Amendment by publicly posting such amendment on its website for no less than thirty (30) calendar days (the “Posting Period”) and providing notice of such amendment by ICANN to the Applicable Registry Operators in accordance with Section 7.8. ICANN will consider the public comments submitted on a Special Amendment during the Posting Period (including comments submitted by the Applicable Registry Operators). (b) If, within two (2) calendar years of the expiration of the Posting Period (the “Approval Period”), (i) the ICANN Board of Directors approves a Special Amendment (which may be in a form different than submitted for public comment) and (ii) such Special Amendment receives Registry Operator Approval (as defined below), such Special Amendment shall be deemed approved (an “Approved Amendment”) by the Applicable Registry Operators (the last date on which such approvals are obtained is herein referred to as the “Amendment Approval Date”) and shall be effective and deemed an amendment to this Agreement upon sixty (60) calendar days notice from ICANN to Registry Operator (the “Amendment Effective Date”). In the event that a Special Amendment is not approved by the ICANN Board of Directors or does not receive Registry Operator Approval within the Approval Period, the Special Amendment will have no effect. The procedure used by ICANN to obtain Registry Operator Approval shall be designed to document the written approval of the Applicable Registry Operators, which may be in electronic form. (c) During the thirty (30) calendar day period following the Amendment Approval Date, Registry Operator (so long as it did not vote in favor of the Approved Amendment) may apply in writing to ICANN for an exemption from the Approved Amendment (each such request submitted by Registry Operator hereunder, an “Exemption Request”). Each Exemption Request will set forth the basis for such request and provide detailed support for an exemption from the Approved Amendment. An Exemption Request may also include a detailed description and support for any alternatives to, or a variation of, the Approved Amendment proposed by such Registry Operator. An Exemption Request may only be granted upon a clear and convincing showing by Registry Operator that compliance with the Approved Amendment conflicts with applicable laws or would have a material adverse effect on the long- term financial condition or results of operations of Registry Operator. No Exemption Request will be granted if ICANN determines, in its reasonable discretion, that granting such Exemption Request would be materially harmful to registrants or result in the denial of a direct benefit to registrants. Within ninety (90) calendar days of ICANN’s receipt of an Exemption Request, ICANN shall either approve (which approval may be conditioned or consist of alternatives to or a variation of the Approved Amendment) or deny the Exemption Request in writing, during which time the Approved Amendment will not amend this Agreement; provided, that any such conditions, alternatives or variations shall be effective and, to the extent applicable, will amend this Agreement as of the Amendment Effective Date. If the Exemption Request is approved by ICANN, the Approved Amendment will not amend this Agreement. If such Exemption Request is denied by ICANN, the Approved Amendment will amend this Agreement as of the Amendment Effective Date (or, if such date has passed, such Approved Amendment shall be deemed effective immediately on the date of such denial), provided that Registry Operator may, within thirty (30) calendar days following receipt of ICANN’s determination, appeal ICANN’s decision to deny the Exemption Request pursuant to the dispute resolution procedures set forth in Article 5. The Approved Amendment will be deemed not to have amended this Agreement during the pendency of the dispute resolution process. For avoidance of doubt, only Exemption Requests submitted by Registry Operator that are approved by ICANN pursuant to this Section 7.6(c) or through an arbitration decision pursuant to Article 5 shall exempt Registry Operator from any Approved Amendment, and no exemption request granted to any other Applicable Registry Operator (whether by ICANN or through arbitration) shall have any effect under this Agreement or exempt Registry Operator from any Approved Amendment. (d) Except as set forth in this Section 7.6, no amendment, supplement or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties, and nothing in this Section 7.6 shall restrict ICANN and Registry Operator from entering into bilateral amendments and modifications to this Agreement negotiated solely between the two parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement or failure to enforce any of the provisions hereof shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided. For the avoidance of doubt, nothing in this Section 7.6 shall be deemed to limit Registry Operator’s obligation to comply with Section 2.2. meanings: (e) For purposes of this Section 7.6, the following terms shall have the following (i) “Applicable Registry Operators” means, collectively, the registry operators of the top-level domains party to a registry agreement that contains a provision similar to this Section 7.6, including Registry Operator. (ii) “Registry Operator Approval” means the receipt of each of the following: (A) the affirmative approval of the Applicable Registry Operators whose payments to ICANN accounted for two-thirds of the total amount of fees (converted to U.S. dollars, if applicable) paid to ICANN by all the Applicable Registry Operators during the immediately previous calendar year pursuant to the Applicable Registry Agreements, and (B) the affirmative approval of a majority of the Applicable Registry Operators at the time such approval is obtained. For avoidance of doubt, with respect to clause (B), each Applicable Registry Operator shall have one vote for each top-level domain operated by such Registry Operator pursuant to an Applicable Registry Agreement. (iii) “Restricted Amendment” means the following: (i) an amendment of Specification 1, (ii) except to the extent addressed in Section 2.10 hereof, an amendment that specifies the price charged by Registry Operator to registrars for domain name registrations, (iii) an amendment to the definition of Registry Services as set forth in the first paragraph of Section 2.1 of Specification 6, or (iv) an amendment to the length of the Term. (iv) “Working Group” means representatives of the Applicable Registry Operators and other members of the community that ICANN appoints, from time to time, to serve as a working group to consult on amendments to the Applicable Registry Agreements (excluding bilateral amendments pursuant to Section 7.6(d)).

1 0

Re: [bc-gnso] IRTP-B -- heads up
by Mike O'Connor Oct. 21, 2011

Oct. 21, 2011

thanks Mike! that connection across to the IPC folks would be especially helpful. mikey On Oct 21, 2011, at 7:38 AM, Mike Rodenbaugh wrote: > Thanks Mikey for raising these issues, and maintaining a voice of “non-registrar” reason in that WG. > > I agree with you on both points, and particularly think the second one is fairly huge. So I will echo your comments to the WG list, fwiw. I also will raise these issues in the IPC and see if any of them will speak up too. > > Mike Rodenbaugh > RODENBAUGH LAW > tel/fax: +1.415.738.8087 > http://rodenbaugh.com > > From: owner-bc-gnso(a)icann.org [mailto:owner-bc-gnso@icann.org] On Behalf Of Mike O'Connor > Sent: Tuesday, October 18, 2011 6:29 AM > To: bc - GNSO list > Subject: [bc-gnso] IRTP-B -- heads up > > hi all, > > and especially those of you who participated in the IRTP working group. > > there's a pretty important end-game being played out in IRTP-B. it would be helpful if those who participated in the working group would dial back in and make comments to the list. and those of you who didn't also will have an opportunity to weigh in. > > i'm lobbying for two changes (here's what i posted to the working-group list): > > Rec #8 > > i like the idea of ensuring that the link is preserved within WHOIS output. > > but when we drafted this recommendation, our intent was to deliver the definition of the status code *within* WHOIS, not through a link to a list somewhere else. the link works fine for sophisticated consumers of WHOIS but, in my opinion, does not reach the "clarify WHOIS status codes" goal that we were striving for when we wrote this. i'd like to take up this discussion one more time. this dilution of our recommendation hasn't been sufficiently justified in my view -- certainly "technical complexity" doesn't cut it. even i, a long-dead programmer, could come up with code to do this in an afternoon, complete with lookups that scraped the definitions off the InterNIC page (so that updates would automatically flow through my code to the output). > > Rec #9 > > this one still suffers from the vagueness that we discussed on our last call. the culprit is in this phrase -- "the registrar may still be permitted or required to restrict some registration changes or transfers pursuant to the UDRP or [sic] other ICANN consensus policies or legal requirements." > > the trouble comes in the phrase "or legal requirements." *which* legal requirements? legal requirements imposed by the registrar? or *external* legal requirements? i'd be a bit more cheerful with wording like this -- "the registrar may still be permitted or required to restrict some registration changes or transfers pursuant to the UDRP, ICANN consensus policies or other external legal requirements." > > i'm not keen on allowing registrar-imposed legal requirements into this policy -- that's effectively opening the door for registrars to block just about any transfer, the prevention of which was one of the primary reasons the IRTP was instituted in the first place. > > i'm pretty much the only non-Registrar commenting at this point. we have a working group developing policy constraining Registrar behavior that is: chaired by a Registrar, is dominated by Registrar participants, has a Council-Liaison that's a Registrar and reports to a Council that's chaired by a Registrar. so i'm feeling a little lonely at the moment. :-) > > i'm forwarding a post from the Chair of the WG in which lays out the process. note that the recommendations are reversed and have different designations. Recommendation 8 in the IRTP report corresponds to RESOLVED (E) while Recommendation 9 corresponds to RESOLVED (D). sorry about that -- above my pay-grade. the main point is that we could use a few more comments from non-Registrars (both on and off the WG). > > thanks, > > mikey > > Begin forwarded message: > > > From: "Michele Neylon :: Blacknight" <michele(a)blacknight.ie> > Date: October 17, 2011 5:26:55 AM CDT > To: "Gnso-irtp-b-jun09(a)icann.org" <Gnso-irtp-b-jun09(a)icann.org> > Subject: [gnso-irtp-b-jun09] IRTP B .. Proposals etc > > > Dear All > > It's great seeing some healthy discussions on the mailing list, so before jumping ahead and setting up any new calls, I'd like to encourage others to express their views on the mailing list. > > As a reminder, please note that the recommendations as resolved by the GNSO Council in relation to these two issues are as follows: > > RESOLVED (D), prior to the consideration of approval of the recommendation which states: "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 GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation. > > RESOLVED (E), prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation. > > Also note that Staff is planning to put out these proposals for community input, so even if the WG is not able to reach a common position on the proposals, individual members will have an opportunity to share their views as part of the public comment forum. > > I'm sure Staff is also reviewing these comments and will try to address these in the best way possible. > > I'd also like to remind you that an IRTP Update has been scheduled to take place at the ICANN meeting in Dakar on Thursday from 10.00 – 11.30 (seehttp://dakar42.icann.org/node/27007) during which you will have another opportunity to share your views. > > Regards > > Michele > > > > Mr Michele Neylon > Blacknight Solutions ♞ > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://blacknight.biz > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > UK: 0844 484 9361 > Locall: 1850 929 929 > Facebook: http://fb.me/blacknight > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > > > - - - - - - - - - > phone 651-647-6109 > fax 866-280-2356 > web http://www.haven2.com > handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.) > - - - - - - - - - phone 651-647-6109 fax 866-280-2356 web http://www.haven2.com handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)

2 1

CSG /Members discussion on Tuesday with Council Chair Candidate/attached Candidate statement - announcement of V.Chair Candidate from Non Contracted House
by Marilyn Cade Oct. 20, 2011

Oct. 20, 2011

I am pleased to advise BC members that Stephane Van Gelder, who is standing for Council Chair re-election for a one year term, has accepted an invitation to meet with the full CSG membership on Tuesday, 4 p.m., in the CSG meeting room. His Candidate Statement is attached for your convenience. While Stephane is standing unopposed, he must still gain 60% of the votes of both houses to be elected. Vice Chairs are chosen separately, and differently. Each House determines their procedure, and provides one vice chair. The procedure in the Non Contracted Party House is discussed separatly. However, I would like to advise Members that Wolf Ulrich Knoben, ISPCP Councilor, has been nominated by the CSG as a Vice Chair Candidate. I will forward his candidate statement in due course.

1 0

Policy calendar for 19-Oct-2011 BC member call
by Steve DelBianco Oct. 19, 2011

Oct. 19, 2011

Here is the latest BC policy calendar, for use during 19-Oct-2011 BC member call. Channel 1. BC participation in ICANN Public Comment process: ICANN Public Comment page is at http://www.icann.org/en/public-comment/ 1. Case studies on TLD variant issues for six IDN scripts (14-Nov) 2. Draft 2012-2015 Strategic Plan (17-Nov) 3. Draft final report on Internationalized Registration Data (17-Nov) 4. Framework for consent in delegation and re-delegation of ccTLDs (1-Dec) 5. Registries' proposal for Continued Operations Fund in new gTLD program (2-Dec) 6. Final report on Support for gTLD Applicants from developing economies (16-Dec) 7. Recommendations to modify Geographic Regions (19-Dec) Note: BC members are encouraged to submit individual / company comments. Based on member interest, the BC selects topics on which to submit official positions. Channel 2. Support for discussion and votes of our representatives on GNSO Council GNSO Project Status available at https://www.icann.org/en/processes/gnso/current-issues.html Agenda<http://gnso.icann.org/meetings/agenda-council-26oct11-en.htm> and motions<https://community.icann.org/display/gnsocouncilmeetings/Motions+26+October+…> for 26-Oct GNSO Council meeting in Dakar: Item 3: Open Council Meetings – drafting team suggestions Item 4: Motion (1) on process to amend the Registrar Accreditation Agreement (RAA) Item 5: Motion (2) on PDP improvements Item 6: Cross Community Working Group drafting team delivers its first status report Item 7: Geo Regions Working Group, discussion of draft<http://www.icann.org/en/public-comment/geo-regions-draft-final-report-30sep…> report (new Council convenes) Item 2: vote for Council chair Channel 3. Supporting discussion and voting on policy matters before the Commercial Stakeholders Group (CSG) Sarah Deutsch (stepping down as CSG Liaison since she has been elected to Nominating Committee) Marilyn Cade (alt) Council leadership elections Channel 4. BC statements and responses during public meetings (outreach events, public forum, etc.) Affirmation review team for Whois (Susan Kawaguchi, Lynn Goodendorf) Affirmation review team for SSR (Security, Stability, & Reslience) (Jeff Brueggeman) Public Forum on Thu 27-Oct

2 1

Update regarding Dakar Travel
by Benedetta Rossi Oct. 19, 2011

Oct. 19, 2011

Dear BC Members, Just an announcement directed at members who are traveling to Dakar this week: I have just received confirmation from ICANN staff that the complimentary shuttle service operating from the airport is already active, and will be running 24 hours per day. All participants can use this service when they arrive at the airport by following the person who has the ICANN 42 Sign. I have also been informed that a shuttle service to the venue hotel will be available for members who are staying at the Hotel Des Almadies from Saturday at 7am local time, running all day long. Members who are arriving before that will need to take a taxi from the Hotel des Almadies to the Meridien. It is apparently very hot in Dakar, so be prepared! I hope this helps! -- Kind Regards, Benedetta Rossi BC Secretariat www.bizconst.org bc-secretariat(a)icann.org

1 0

U.S. analyst puts form to global Internet trends
by john＠crediblecontext.com Oct. 19, 2011

Oct. 19, 2011

Every year, Kleiner Perkin's (Palo Alto, CA) analyst, Mary Meeker, offers her view of the global technology marketplace at the Web 2.0 conference in San Francisco. This year's presentation (here: http://www.kpcb.com/insights/internet-trends-2011) is as provocative as expected. Global, mobile, social, sure, but she suggests an interdependence that has implications for the new gTLD program. I thought it might help stimulate your own thinking (as it has mine). Cheers, John Berard

1 0

IRTP-B -- heads up
by Mike O'Connor Oct. 18, 2011

Oct. 18, 2011

hi all, and especially those of you who participated in the IRTP working group. there's a pretty important end-game being played out in IRTP-B. it would be helpful if those who participated in the working group would dial back in and make comments to the list. and those of you who didn't also will have an opportunity to weigh in. i'm lobbying for two changes (here's what i posted to the working-group list): > Rec #8 > > i like the idea of ensuring that the link is preserved within WHOIS output. > > but when we drafted this recommendation, our intent was to deliver the definition of the status code *within* WHOIS, not through a link to a list somewhere else. the link works fine for sophisticated consumers of WHOIS but, in my opinion, does not reach the "clarify WHOIS status codes" goal that we were striving for when we wrote this. i'd like to take up this discussion one more time. this dilution of our recommendation hasn't been sufficiently justified in my view -- certainly "technical complexity" doesn't cut it. even i, a long-dead programmer, could come up with code to do this in an afternoon, complete with lookups that scraped the definitions off the InterNIC page (so that updates would automatically flow through my code to the output). > > Rec #9 > > this one still suffers from the vagueness that we discussed on our last call. the culprit is in this phrase -- "the registrar may still be permitted or required to restrict some registration changes or transfers pursuant to the UDRP or [sic] other ICANN consensus policies or legal requirements." > > the trouble comes in the phrase "or legal requirements." *which* legal requirements? legal requirements imposed by the registrar? or *external* legal requirements? i'd be a bit more cheerful with wording like this -- "the registrar may still be permitted or required to restrict some registration changes or transfers pursuant to the UDRP, ICANN consensus policies or other external legal requirements." > > i'm not keen on allowing registrar-imposed legal requirements into this policy -- that's effectively opening the door for registrars to block just about any transfer, the prevention of which was one of the primary reasons the IRTP was instituted in the first place. i'm pretty much the only non-Registrar commenting at this point. we have a working group developing policy constraining Registrar behavior that is: chaired by a Registrar, is dominated by Registrar participants, has a Council-Liaison that's a Registrar and reports to a Council that's chaired by a Registrar. so i'm feeling a little lonely at the moment. :-) i'm forwarding a post from the Chair of the WG in which lays out the process. note that the recommendations are reversed and have different designations. Recommendation 8 in the IRTP report corresponds to RESOLVED (E) while Recommendation 9 corresponds to RESOLVED (D). sorry about that -- above my pay-grade. the main point is that we could use a few more comments from non-Registrars (both on and off the WG). thanks, mikey Begin forwarded message: > From: "Michele Neylon :: Blacknight" <michele(a)blacknight.ie> > Date: October 17, 2011 5:26:55 AM CDT > To: "Gnso-irtp-b-jun09(a)icann.org" <Gnso-irtp-b-jun09(a)icann.org> > Subject: [gnso-irtp-b-jun09] IRTP B .. Proposals etc > > > Dear All > > It's great seeing some healthy discussions on the mailing list, so before jumping ahead and setting up any new calls, I'd like to encourage others to express their views on the mailing list. > > As a reminder, please note that the recommendations as resolved by the GNSO Council in relation to these two issues are as follows: > > RESOLVED (D), prior to the consideration of approval of the recommendation which states: "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 GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation. > > RESOLVED (E), prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation. > > Also note that Staff is planning to put out these proposals for community input, so even if the WG is not able to reach a common position on the proposals, individual members will have an opportunity to share their views as part of the public comment forum. > > I'm sure Staff is also reviewing these comments and will try to address these in the best way possible. > > I'd also like to remind you that an IRTP Update has been scheduled to take place at the ICANN meeting in Dakar on Thursday from 10.00 – 11.30 (see http://dakar42.icann.org/node/27007) during which you will have another opportunity to share your views. > > Regards > > Michele > > > > Mr Michele Neylon > Blacknight Solutions ♞ > Hosting & Colocation, Brand Protection > ICANN Accredited Registrar > http://www.blacknight.com/ > http://blog.blacknight.com/ > http://blacknight.biz > http://mneylon.tel > Intl. +353 (0) 59 9183072 > US: 213-233-1612 > UK: 0844 484 9361 > Locall: 1850 929 929 > Facebook: http://fb.me/blacknight > Twitter: http://twitter.com/mneylon > ------------------------------- > Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty > Road,Graiguecullen,Carlow,Ireland Company No.: 370845 > > - - - - - - - - - phone 651-647-6109 fax 866-280-2356 web http://www.haven2.com handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)

1 0

BC Members Travelling to Dakar: What to Expect Upon Arrival
by Benedetta Rossi Oct. 18, 2011

Oct. 18, 2011

Dear BC Members, Below is what to expect upon your arrival to Dakar. 1) Upon landing, please see the person holding an "ICANN 42 Dakar" sign, where they will re-direct you to go to a separate bus from the rest of the group. 2) The bus will then take you to a separate holding facility where you will be processed for your passport, visa, and etc. 3) After you have been processed, you will then need to complete a form indicating which hotel the shuttle bus will drop you off. 4) If you brought any luggage, they will escort you back to the main airport where you will collect your luggage. 5) After you've collected your luggage, you will then be escorted to your shuttle bus to take you to your hotel. Safe travels!! -- Kind Regards, Benedetta Rossi BC Secretariat www.bizconst.org bc-secretariat(a)icann.org

2 1

ALERTS From the Secretariat: Draft Agenda for GNSO Council Public Meeting in Dakar 26 October 2011‏
by Benedetta Rossi Oct. 18, 2011

Oct. 18, 2011

Dear BC Members, Please find the*Draft Agenda for GNSO Council Public Meeting in Dakar 26 October 2011. *http://gnso.icann.org/meetings/agenda-council-26oct11-en.htm Also posted on the Wiki at: https://community.icann.org/display/gnsocouncilmeetings/Agenda+26+October+2… This 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.pdf For 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 14:00 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=GNSO+Council+Publi…> Coordinated Universal Time: 14:00 UTC - see below for local times (07:00 Los Angeles, 10:00 Washington DC, 14:00 Dakar, 15:00 London, 16:00 Brussels, 23:00 Tokyo Thursday 27 October 01:00 Melbourne Dial-in numbers will be sent individually to Council members who will be absent. Councilors should notify the GNSO Secretariat in advance if a dial out call is needed. *Refer to:* *http://dakar42.icann.org/node/26967 14:00- 15:00 GNSO Council Public Forum. * Presentations by Stakeholder and Constituency Group leaders. * gTLD Registries Stakeholder Group - David Maher * Registrar Stakeholder Group - Mason Cole * Non Commercial Users Constituency (NCUC) – ·Not-for-Profit Operational Concerns Constituency (NPOC). – Debbie Hughes * Commercial and Business Users Constituency (BC) – * Intellectual Property Constituency (IPC) – * Internet Service Providers and Connectivity Providers (ISPCP) - *Break 15:30* *_Item 1: Administrative matters (10 minutes) _*1.1 Roll Call*_ _* 1.2 Updated statement of interest 1.3 Review/amend agenda 1.4. Note the status of minutes for the previous Council meeting per the GNSO Operating Procedures: •6 October minutes <http://gnso.icann.org/mailing-lists/archives/council/msg12194.html>–will be approved on 24 October 2011. *_ Item 2: GNSO Pending Projects List (10 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.pdf 2.1 Changes to Pending Projects List since last Council meeting (Stéphane Van Gelder) • GNSO activities: 6(10 – PEDNR, PDP-WT, OSC, GCOT, CSG Removed, IRTP- C added) • Other activities: 10 (9 –Thick Whois added) • Joint SO/AC WGs: 7 (7 –RAA Removed, RC-IOC added). • Outstanding recommendations: 2 (2– no change). 2.2 Open microphone * _Item 3: Open Council Meeting Drafting Team (15 minutes)_* Following the Singapore meeting, a GNSO Drafting Team was formed to work on possible enhancements to the format of the GNSO Council's Open Meetings. Today's meeting is the first since the formation of this DT. As an introduction to the meeting, the DT would like to present some of its suggested enhancements and receive feedback on them. 3.1 Update from DT (Adrian Kinderis) 3.2 Discussion 3.3 Next steps 3.4 Open microphone *_Item 4: Amendments to RAA (15 minutes)_*** In its ongoing work on the Registrar Accreditation Agreement (RAA), and more specifically to identify potential amendments to the RAA, the Council is considering a motion to approve an amended process to develop a new form of RAA termed "process B". Refer to motion 1 https://community.icann.org/display/gnsocouncilmeetings/Motions+26+October+… This motion was deferred from the October 6, 2011 meeting. 4.1 Reading of the motion (Kristina Rosette) 4.2 Discussion 4.3 Vote 4.4 Open microphone *_Item 5: Policy Development Process Work Team (PDP-WT) (15 minutes)_*** As part of the GNSO improvements, the PPSC's PDP WT has produced a final report on how the GNSO's policy develop process should be handled. Refer to PDP-WT Final Report This report has been put out for public comment and is now being presented to the Council for approval. Refer to motion 2 https://community.icann.org/display/gnsocouncilmeetings/Motions+26+October+… This motion was deferred from the October 6, 2011 meeting. 5.1 Reading of the motion (Jeff Neuman) 5.2 Discussion 5.3 Vote 5.4 Open microphone *_Item 6: Cross Community WG Drafting Team (15 minutes)_*** In order to identify exactly how the GNSO should interact with, or participate in, Cross Community efforts, a drafting team has been examining how to best conduct these joint activities. The GNSO Council approved the team's charter on October 6. Today, the team is delivering its first status report. Link to report 6.1 Update from DT (Jonathan Robinson) 6.2 Discussion 6.3 Next steps 6.4 Open microphone * _Item 7: Geo regions WG (15 minutes)_* The Geo Regions WG is currently drafting its final report and plans to produce it early next year. The GNSO Council will be able to comment the report at that time. A draft document is currently the subject of a public comment forum:http://www.icann.org/en/public-comment/geo-regions-draft-final-report…. This is a discussion item to update the Council on this work, and also to determine if the current Council reps to the WG are able to continue in this role. The current reps are Olga Cavalli and Zahid Jamil. As Olga will no longer sit on the GNSO Council after the Dakar meeting, she may wish to ask the Council for another rep. 7.1 Update from Staff (Rob Hoggarth) 7.2 Discussion 7.3 Rep choices 7.4 Open microphone *_Item 8 Thanks to outgoing Councilors_* *_Item 9. Any Other Business (5 minutes)_* *BREAK* _ *18:00 - 18:30 New Council convenes*_ *_Item 1. Seating of new Council_* 1.1 Roll call 1.2 Statements of interest *_Item 2 Vote for GNSO Council chair_* One nomination: Stéphane van Gelder Vote by show of hands *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 <http://gnso.icann.org/council/gnso-op-procedures-07apr11-en.pdf>**) * 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 March & October, Summer in the NORTHERN hemisphere ---------------------------------------------------------------------------- Reference (Coordinated Universal Time) UTC 14:00 ---------------------------------------------------------------------------- California, USA (PDT) UTC-8+1DST 07:00 Cedar Rapids, USA (CDT) UTC-6+1DST 09:00 New York/Washington DC, USA (EDT) UTC-5+1DST 10:00 Buenos Aires, Argentina UTC-3+0DST 11:00 Rio de Janeiro/Sao Paulo Brazil UTC-3+0DST 12:00 Dakar, Senegal UTC 14:00 London, United Kingdom (BST) UTC+1DST 15:00 Tunis, Tunisia (CET)UTC+1+0DST 16:00 Darmstadt, Germany (CET) UTC+1+1DST 16:00 Paris, France (CET) UTC+1+1DST 16:00 Moscow, Russian Federation UTC+3+1DST 18:00 Karachi, Pakistan UTC+5+0DST 19:00 Beijing, China UTC+8+0DST 22:00 Tokyo, Japan UTC+9+0DST 23:00 Melbourne,/Sydney Australia (EST) UTC+10+0DST 01:00 next day ---------------------------------------------------------------------------- The DST starts/ends on last Sunday of October 2011, 2:00 or 3:00 local time (with exceptions) ---------------------------------------------------------------------- For other places seehttp://www.timeanddate.com <http://www.timeanddate.com/> -- Kind Regards, Benedetta Rossi BC Secretariat www.bizconst.org bc-secretariat(a)icann.org

1 0

ALERTS From the Secretariat: Framework of Interpretation Working Group – Interim Report
by Benedetta Rossi Oct. 18, 2011

Oct. 18, 2011

http://www.icann.org/en/announcements/announcement-12oct11-en.htm Framework of Interpretation Working Group – Interim Report Comment Period Deadlines^(*) Important Information Links Public Comment Box <http://www.icann.org/en/public-comment/foiwg-interim-report-12oct11-en.htm> *Open Date:* 12 October 2011 To Submit Your Comments (Forum) <mailto:foiwg-interim-report@icann.org> *Close Date:* 1 December 2011 *Time (UTC):* 23:59 View Comments Submitted <http://forum.icann.org/lists/foiwg-interim-report/> *Section I: Description, Explanation, and Purpose* The Framework of Interpretation Working Group (FOIWG) is seeking public comment on Interim Report on the first topic it has addressed: obtaining and documenting consent for delegation and re-delegation requests. The Final Report of the Delegation Redelegation and Retirement Working Group (DRDWG) identified the following issues with the topic of "consent": /"The Interpretation of consent (communication that the transfer is agreed), by IANA's own admission, is highly variable depending on a number of factors including culture and the immediate physical security of the ccTLD manager. This includes interpreting a failure to reply to an IANA email as consent in certain cases of re-delegations where the current manager has stated he does not support the request."/ The FOIWG identified the applicable polices and procedure statements and analysed all past cases of ccTLD re-delegations researching the stated consent in each instance. Based on this analysis the FOIWG identified the issues in the context of the applicable policies. These issues were further analysed to identify any issues arising from this analysis. Based on this analysis the FOIWG developed draft recommendations. To be most helpful input and feed-back from the community is sought with respect to the following questions: 1. Is the approach used by the FOIWG satisfactory? 2. Is the documentation that was analyzed to identify issues comprehensive? 3. Do the issues identified by the FOIWG for this topic capture the major problems associated with the topic? If not, what is missing? 4. Are the proposed guidelines effective solutions to the issues that were identified? 5. Are the recommendations effective in addressing the concerns raised in the final report of the DRDWG regarding this topic? *Section II: Background* The FOIWG was created by the ccNSO Council following the recommendations of the Delegation and Re-delegation Working Group (DRDWG): */Recommendation 2: Delegation and re-delegation of ccTLDs/* /The DRDWG recommends that, as a first step, the ccNSO Council undertakes the development of a “Framework of Interpretation” for the delegation and re-delegation of ccTLDs. This framework should provide a clear guide to IANA and the ICANN Board on interpretations of the current policies, guidelines and procedures relating to the delegation and re-delegation of ccTLDs./ /The results of the use of such a Framework of Interpretation should be formally monitored and evaluated by the ccNSO Council after a pre-determined period. If the results of this evaluation indicate that the Framework of Interpretation failed to provide logical and predictable outcomes in ICANN decision making, the ccNSO Council should then launch PDPs on the delegation and re-delegation of ccTLDs./ The charter of the FOIWG was adopted by the ccNSO Council at its meeting on 16 March 2011 and appointed as its chair Keith Davidson of .NZ (former Chair of the DRDWG). In June 2011 the charter was updated to reflect the participation of the Governmental Advisory Committee (GAC). The charter and the list of participants of the working group can be found athttp://ccnso.icann.org/workinggroups/foiwg.htm) The objective of the FOIWG is to develop and propose a "Framework of Interpretation" for the delegation and re-delegation of ccTLDs. This framework should provide a clear guide to IANA and the ICANN Board on interpretation of the current policies and guidelines pertaining to the delegation and redelegation of ccTLD’s. The scope of the FOIWG also clearly specifies that: * Any proposal to amend, update or change the Policy Statements is outside the scope of the FOIWG. * The IANA functions contract between the US Government and ICANN, including any contract implementation issues or procedures relating to it, are outside the scope of the FOIWG. *Section III: Document and Resource Links* _Documents posted for comment_: The Interim Report is posted here:http://ccnso.icann.org/workinggroups/interim-report-consent-final-12oc…, 1.63 MB] _Additional Resources_: Further information on the work of the Framework of Interpretation Working Group is available at:http://ccnso.icann.org/workinggroups/foiwg.htm. *Section IV: Additional Information* The Interim Report addresses the first of the following topics the FOIWG identified which will be considered individually and in the order presented: * Obtaining and documenting consent for delegation and re-delegation requests * Obtaining and documenting support for delegation and re-delegation requests from Significantly Interested Parties (sometimes referred to as Local Internet Community or LIC). * Developing recommendations for un-consented re-delegations * Developing a comprehensive glossary of the terms used for the delegation and re-delegation of ccTLDs. * Developing recommendations for IANA reports on delegation and re-delegation. *Staff Contact:* Bart Boswinkel *Email:* bart.boswinkel(a)icann.org <mailto:bart.boswinkel@icann.org?subject=More%20information%20on%20the%20Framework%20of%20Interpretation%20Working%20Group%20%E2%80%93%20Interim%20Report%20public%20comment%20period> -- Kind Regards, Benedetta Rossi BC Secretariat www.bizconst.org bc-secretariat(a)icann.org

1 0