May 2013 - Bc-gnso - lists.icann.org

Re: [bc-gnso] Minutes and transcript: BC Members call on GAC Advice - Part 2 held on May 8th, 2013 at 11 am EST
by Stéphane Van Gelder Consulting 10 May '13

10 May '13

Hi all, My messages aren't getting to the list at the moment. Hopefully that is now fixed. Resending my earlier message (see below) just to test. Stéphane Le 10 mai 2013 à 11:20, Stéphane Van Gelder Consulting <stephvg(a)gmail.com> a écrit : > Thanks Martin. > > The GAC has a big responsibility in the multi-stakeholder process and by presenting advice that appears half-assed at best it makes it look like it doesn’t take that responsibility seriously. > > I made the point the other day about the fact that GAC advice is not consistent with the ICANN model if it is an attempt to redefine, at the last minute, policy that was established through community BU development a long time ago. > > Stéphane Van Gelder > Chairman and Managing Director/Fondateur > STEPHANE VAN GELDER CONSULTING > > T (UK): +44 (0)7583 457053 > T (FR): +33 (0)6 20 40 55 89 > Skype: SVANGELDER > www.StephaneVanGelder.com > ---------------- > Follow us on Twitter: @stephvg and "like" us on Facebook: www.facebook.com/DomainConsultant > LinkedIn: fr.linkedin.com/in/domainconsultant/ > > Le 10 mai 2013 à 09:28, martinsutton(a)hsbc.com a écrit : > >> All, >> >> This is an interesting article which illustrates the difficulties about who/how are strings determined to be in a particular category according to the GAC advice - http://domainincite.com/12944-this-is-how-stupid-the-gacs-new-gtlds-advice-…. >> >> ------------------------------------------------------------------------------------------------------------------------------------- >> For the last few weeks I’ve been attempting to write a sensible analysis of the Governmental Advisory Committee’s advice on new gTLDs without resorting to incredulity, hyperbole or sarcasm. >> I failed, so you’ll have to read this instead. >> >> I’m sorry, but the GAC’s Beijing communique (pdf) just has too much stupid in it to take seriously. >> >> As a quick reminder, the bulk of the GAC’s advice was taken up by a list of hundreds of applied-for strings, in 12 categories, that “are likely to invoke a level of implied trust from consumers”. >> >> The GAC said that any string on the list should be subject to more stringent regulation than others, turning their registries into data security regulators and creating an obligation to partner with “relevant regulatory, or industry self-regulatory, bodies”. >> >> The GAC, having advised the creation of these unexpected obligations, decided that it wasn’t its responsibility to figure out whether any of them would be feasible to implement. >> >> That’s apparently up to ICANN to figure out. >> >> But that’s not the most infuriating part of the advice. The most infuriating part is the list of strings it provided, which by the GAC’s own admission was unhelpfully “non-exhaustive”. >> >> When one performs a cursory analysis of the list, and compares it to the strings that did not make it, the dumb just accumulates. >> >> My spies tell me that the GAC worked into the early hours on a few occasions during the Beijing meeting in order to put this advice together, and some might say it’s unfair to expect its members to have read and formed consensus opinions on all 1,930 original new gTLD applications. >> >> But the GAC wasn’t expected to read them all, nor did it. Its job was originally conceived of as commenting on the strings alone, and that appears to be what it ultimately did limit itself to. >> >> I think it’s fair to try to get some insight into the GAC’s collective thought process by looking at the “Category 1″ strings that it did put on the list and those that it did not. >> >> Not because I think there’s a coherent thought process at work here, but because I think there isn’t. >> >> Remember, the GAC had nine months to come up with its list. This article was written in an afternoon. >> >> Here’s my list of bizarre inconsistencies, failed reality checks and pure dumb I found in the Beijing communique. >> >> It’s non-exhaustive. >> >> Destroy all pirates! >> >> The GAC is clearly a bit worried that people might use new gTLDs to offer pirated and counterfeited goods (like they do in existing TLDs), so it has placed a few dozen content-related strings on its list. >> >> The intellectual property list is one of the longest of the 12 categories in the Beijing communique. >> >> But it could be longer. >> >> I wonder why, for example, the GAC doesn’t consider .stream a threat to copyright? Streaming sites are frequent targets of takedown notices. >> >> Why does .hiphop get a mention but not .country, a gTLD specifically designed for country music lovers? >> >> Why are .photography, .photo, .photos, .pictures and .pics not on the list? Image theft is pandemic online, enabled by default in browsers (no P2P required) and utterly trivial to execute. >> >> And if .tours is considered a problem, why not .events, or .tickets? >> >> We’re talking about sectors with abuse potential here, and ticketing is considered worthy of legislation in many places. Here in England you can get a £5,000 fine for reselling a ticket to a football match. >> >> Why is .tours even on the intellectual property list? It could just as easily refer to organized vacations or guide services provided by museums. Or the French city of the same name, for that matter. >> >> Why aren’t our friends in Tours getting the same GAC love as Spa and Date — towns in Belgium and Japan — which have caused the delay of advice on .spa and .date respectively? >> >> And why are .free, .gratis and .discount considered intellectual property problems? >> >> How is the .free registry supposed to follow the GAC’s demand that it partner with “relevant regulatory, or industry self‐regulatory, bodies” for free stuff? Does “.free” even have an “implied level of trust”? >> >> Is the GAC’s goal to kill off the bid by the back door? >> >> Goodbye .free, you couldn’t guarantee that there wouldn’t be piracy in your TLD so your application is forfeit? A potentially cool TLD, sacrificed on the altar of Big Copyright? >> >> Don’t even get me started on .art… >> >> Won’t somebody think of the children?! >> >> The GAC did not say why the “children” category exists, but I assume it’s about ensuring that the content in TLDs such as .kids and .school is suitable for “kids” (pick your own definition, the GAC doesn’t have one). >> >> It goes without saying that any TLD that is obliged to follow child-friendly rules will be saddled with a commercial death sentence, as the US government already knows full well. >> >> The GAC didn’t include .family on the list for some reason, but it did inexplicably include .game and .games. >> >> In the last game I played, my character stabbed a guy in the neck with a broken bottle, stole his clothes and threw his body off a cliff. Gaming is a predominantly adult pastime nowadays. >> >> Suggesting that .games sites need to be child-friendly is just as stupid as saying .movie or .book sites need to be child-friendly. >> >> I’m sure GAC chair Heather Dryden is far too sensible and grown-up to play games, but I’d be surprised if not a single member of the committee owns an Xbox. One of them should have pointed this nonsense out. >> >> If the GAC is not saying this — if it’s merely saying the .games registry should work cooperatively with the gaming industry — then why is .games in the “Children” category? >> >> The GAC Diet >> >> Another couple dozen strings are listed under the “health and fitness” category, ranging from the not-unreasonable, such as .doctor, to the terrifically broad, such as .diet and .care. >> >> Really? .care? >> >> Donuts, the .care applicant, has to partner with some kind of medical register in order to sell a TLD that could just as easily be used for customer support by a company that sells shoes? >> >> And .diet? If the GAC is concerned about internet users getting dodgy dieting advice from a disreputable .diet registrant, why not also issue advice against .eat and .food? >> >> If .fitness is a problem, why isn’t .yoga? >> >> Why isn’t the GAC bothered by .tattoo and .ink? Where I live, you need to be a licensed professional in order to stick people with an inky needle. >> >> For that matter, why aren’t .beauty and .salon a problem? Pretty much every beauty salon I’ve walked past in the last couple of years wants to inject toxins into my face for a fee. >> >> If we’re already saying games are for kids, that free equals fake, and that tours can be pirated, it doesn’t seem like too unreasonable a leap to to regulate .beauty too. >> >> You feed beefburgers to swans >> >> There’s a provision in the Beijing communique saying that every string on the GAC’s list must force its registrants “to comply with all applicable laws, including those that relate to… organic farming.” >> >> So why the hell doesn’t .farm appear on the list?!? >> >> Really, it doesn’t. I’ve triple-checked. It’s not there. According to the GAC’s advice, a .bingo registrant has to abide by organic farming laws but a .farm registrant does not. >> >> Some professions are more equal than others >> >> For all of the “Category 1″ strings the GAC has advised against, the headline argument is this: >> >> Strings that are linked to regulated or professional sectors should operate in a way that is consistent with applicable laws. >> >> But there are plenty of strings that are “linked to regulated or professional sectors” that don’t merit a mention in the communique. >> >> Alcohol, for example. The sale of booze is regulated pretty much everywhere — in some places it’s illegal — but .pub and .bar don’t make it to the GAC’s advice. Neither does .vodka. >> >> If the GAC wants .weather to have strict controls — with no abuse scenario I can think of — why not a couple of TLDs that could, potentially, be used to sell alcohol over the internet? >> >> What of construction? There may have been advice against .engineer, but .construction, .building, .contractors and .build got a pass. Why? Governments everywhere regulate the building industry tightly. >> >> Here in the UK, if you want a plumber to come over and tinker with your heating you’d better hope they’re on the Gas Safe Register, but .plumber doesn’t show up in the Beijing communique. >> >> Why not? An abusive .dentist registrant could mess up my teeth, but he’ll need an expensive surgery to do it in. An abusive .plumber, on the other hand, can come over and blow up my house with no such outlay. >> >> Taxis are regulated in most big cities, but .taxi and .limo escaped GAC advice. Hell, even porn is strictly controlled in many countries, but .porn got a pass. >> >> I could go on. >> >> Anyway… >> >> You might think I’m being petty, but remember: the GAC got the list of applied-for strings last June the same as everybody else. It had plenty of time to get its advice list right. >> >> The GAC has a big responsibility in the multi-stakeholder process and by presenting advice that appears half-assed at best it makes it look like it doesn’t take that responsibility seriously. >> >> I know it does, but it doesn’t appear that way. >> >> Martin C SUTTON >> Group Risk >> Manager, Group Fraud Risk and Intelligence | HSBC HOLDINGS PLC HGHQ >> Group Security & Fraud Risk >> 8 Canada Square,Canary Wharf,London,E14 5HQ,United Kingdom >> ________________________________________________________________ >> >> Phone +44 (0)20 7991 8074 / 7991 8074 >> Mobile +44 (0) 7774556680 >> Email martinsutton(a)hsbc.com >> >> >> ________________________________________________________________ >> Protect our environment - please only print this if you have to! >> >> >> >> >> From: "Benedetta Rossi" <bc-secretariat(a)icann.org> >> To: <bc-gnso(a)icann.org> >> Date: 09/05/2013 19:03 >> Subject: [bc-gnso] Minutes and transcript: BC Members call on GAC Advice - Part 2 held on May 8th, 2013 at 11 am EST >> Sent by: owner-bc-gnso(a)icann.org >> >> >> >> >> Dear BC Members, >> >> Please find attached the minutes & transcript from yesterday’s BC Members call on GAC Advice – Part 2 which took place at 11 am EST. >> >> These materials are also available on the BC Wiki: https://community.icann.org/x/0YHbAQ >> >> Thank you, >> >> -- >> Kind Regards, >> >> Benedetta Rossi >> BC Secretariat >> bc-secretariat(a)icann.org >> https://community.icann.org/display/gnsobc/Home >> www.bizconst.org >> >> [attachment "Minutes BC Members call MAY 08 2013.pdf" deleted by Martin C SUTTON/HGHQ/HSBC] [attachment "BC MAY 08 2013.pdf" deleted by Martin C SUTTON/HGHQ/HSBC] >> >> >> >> ************************************************************ >> HSBC Holdings plc >> Registered Office: 8 Canada Square, London E14 5HQ, United Kingdom >> Registered in England number 617987 >> ************************************************************ >> ----------------------------------------- SAVE PAPER - THINK BEFORE YOU PRINT! This E-mail is confidential. It may also be legally privileged. If you are not the addressee you may not copy, forward, disclose or use any part of it. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return E-mail. Internet communications cannot be guaranteed to be timely secure, error or virus-free. The sender does not accept liability for any errors or omissions. >

2 1

Minutes and transcript: BC Members call on GAC Advice - Part 2 held on May 8th, 2013 at 11 am EST
by Benedetta Rossi 10 May '13

10 May '13

Dear BC Members, Please find attached the minutes & transcript from yesterday's BC Members call on GAC Advice - Part 2 which took place at 11 am EST. These materials are also available on the BC Wiki: https://community.icann.org/x/0YHbAQ Thank you, -- Kind Regards, Benedetta Rossi BC Secretariat bc-secretariat(a)icann.org <https://community.icann.org/display/gnsobc/Home> https://community.icann.org/display/gnsobc/Home www.bizconst.org

3 2

BC Wiki has been Updated
by Benedetta Rossi 09 May '13

09 May '13

Dear BC Members, I just wanted to let you know that the BC conference call page on the Wiki has been updated, and you can now view the minutes, transcripts, presentations & MP3 recording for the last two BC members calls here: https://community.icann.org/x/0YHbAQ The missing information for the moment is yesterday's BC call on GAC Advice Part 2. I have not yet received the transcript, and have therefore not yet drafted minutes for it. The other calls all have the materials on the Wiki. Thank you, -- Kind Regards, Benedetta Rossi BC Secretariat bc-secretariat(a)icann.org <https://community.icann.org/display/gnsobc/Home> https://community.icann.org/display/gnsobc/Home www.bizconst.org

1 0

I: [bc-gnso] For use in 8-May-2013 member call regarding BC comments on GAC Advice
by Benedetta Rossi 08 May '13

08 May '13

Dear BC Members, Please find below an email sent by Stephane Van Gelder which was unfortunately caught in an internal mailing list bounce and therefore did not get published on the list. -- Kind Regards, Benedetta Rossi BC Secretariat <x-msg://10694/bc-secretariat@icann.org> bc-secretariat(a)icann.org <https://community.icann.org/display/gnsobc/Home> https://community.icann.org/display/gnsobc/Home <x-msg://10694/www.bizconst.org> www.bizconst.org Le 7 mai 2013 à 11:58, Stéphane Van Gelder Consulting <stephvg(a)gmail.com> a écrit : Thanks Steve, and apologies in advance as I will not be able to attend the call as I will be flying back from the Dallas INTA meeting at that time. I have one comment on the process questions that the GAC Advice brings into focus. Without going into the detail of each point, this advice can be seen as rewriting the new gTLD program's basic rulebook at a very late stage in the game. In fact, I would argue that the GAC's Beijing Communiqué reads almost like a reboot of the GNSO recommendations and the implementation work done since then. At the very least, this ought to be problematic from a timing point of view. BC members just like everyone else in the community participated in the bottom-up process that led to the GNSO recommendations and then the implementation of the program based on those recommendations. They did not include many of the new rules the GAC is asking for in its Beijing advice. Is this fair to applicants and the community? Is this a predictable process? Thanks, Stéphane Van Gelder Chairman and Managing Director/Fondateur STEPHANE VAN GELDER CONSULTING T (UK): +44 (0)7583 457053 T (FR): +33 (0)6 20 40 55 89 Skype: SVANGELDER www.StephaneVanGelder.com <http://www.stephanevangelder.com/> ---------------- Follow us on Twitter: @stephvg and "like" us on Facebook: www.facebook.com/DomainConsultant LinkedIn: fr.linkedin.com/in/domainconsultant/ Le 6 mai 2013 à 17:01, Steve DelBianco <sdelbianco(a)netchoice.org> a écrit : Here is an updated outline for Wednesday's member discussion of BC comments on GAC Advice (below and attached). Under the red headings I summarized discussion from last week on the first half of the outline. Also attached are 1-May call minutes taken by Benedetta, our Secretariat. 3rd attachment is transcript from that call. Public Comment page at http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en…. Initial comments due 14-May; Reply comments close 4-Jun. Full GAC Communique and Advice is at http://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf Just the Safeguards in section IV 1.b and Annex 1 are being posted for public comment. But I think the BC could also post separate comments on other GAC advice, such as Singular-Plural contention sets, Whois, etc. BC commentary on GAC Advice, in general BC members discussed what we would say in introductory comments. Recognition that GAC has supported BC priorities on the new gTLD program. Also recognition that this GAC advice includes new requirements not in the Guidebook or Registry contract. Ron Andruff and Andrew Mack volunteered to draft a few paragraphs of introductory comments. 1. New gTLDs: a. GAC objections to specific applications (. africa . gcc . islam . halal) b. Safeguards for all new gTLDs (Annex 1) 1. Registry does Whois verification checks 2x per year 2. Registrant ToS should prohibit malware, botnets, phishing, piracy, TM/copyright infringement, fraud, deception, or anything contrary to applicable law. 3. Registry to periodically check domains in TLD for security threats (pharming, phishing, malware, botnets). Notify registrar and suspend domain if no immediate remedy. 4. Registry to maintain stats on inaccurate Whois , security threats found, and actions taken. 5. Registry needs mechanism to handling complaints about inaccurate Whois, security, etc. 6. Registry must ensure immediate consequences (incl suspension) for inaccurate Whois or domain use in breach of applicable law BC commentary on Safeguards for all TLDs: Elisa reminded BC members that we are required to take the perspective of business registrants and users/customers – even if we have other interests in new gTLDs. A majority of BC members on the 1-May call generally support 1.b safeguards. (Ron, Anjali, David, Elisa, Sarah, Susan, Zahid) Subsequent discussion revealed nuances and concerns about some safeguards: Emmett O’Keefe believes GAC advice goes far beyond settled requirements in the final Guidebook. Andy Abrams prefers PDPs instead of ICANN implementing these safeguards based solely on GAC advice. Elisa noted that many of these items are already required of registrars per the proposed RAA. (need to identify these items) Susan Kawaguchi questioned how registriescould do the security scans required in item 3. “Applicable law” could be extremely broad, covering laws of any nation whose registrants or users access the TLD. David Fares and Sarah Deutsch pointed out that broad application of law is usually beneficial for business users and registrants. John Berard questions how ICANN could require these safeguards, since Guidebook and Contract are finalized. Steve pointed out that registry operators can add safeguards to their Public Interest Commitments (Specification 11),provided ICANN allows updates at this point. Phil Corwin responded that hundreds of unique PIC Specs would make compliance enforcement extremely difficult for ICANN. Phil Corwin opposes the “suspension” requirement in safeguards 3 and 6 unless there were due process protections for registrants. Safeguards for Category 1 gTLDs: consumer protection, sensitive strings and regulated markets (non-exhaustive list of TLDs in annex 1, page 9) 1. Registrant ToS should require compliance with applicable laws, incl privacy, consumer protection, fair lending, organic farming, disclosures 2. Registry will require registrars to notify registrants of ToS at time of registration. 3. Registry will require registrants collecting sensitive health or financial data have reasonable security measures as defined by applicable laws and industry standards. 4. Registry to establish relationship with regulators or industry self-regulatory body, plus strategy to mitigate risks of fraud & illegal activities. 5. Registry will require registrants to have single point of contact for complaints and mitigation BC commentary on safeguards forCategory 1 TLDs: Item 3 raised concerns from most members on the call since it might be interpreted to require registries to police registrants as to their data security practices. Steve DelBianco suggested that BC recommend registries be required to indicate #3 as part of the Terms of Service for registrants -- but not to require registries to police registrant practices. Ron Andruff agreed, so BC will encourage ICANN to make #3 part of the ToS requirement in #1 and #2. Jim Baskin and Susan Kawaguchi said safeguards 3 and 4 would be placing too much new responsibility on registries to monitor conduct of registrants. Items 1 and 3 raise same comment on “applicable laws” as noted on safeguards for all TLDs (above). --remaining items to be discussed on May 8 Additional Safeguards for Category 1 gTLDs in financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity: 6. Registry must verify and validate registrant authorization, charter, license or other credentials 7. if in doubt about credentials, Registry should consult with national supervisory authority 8. Registry must do periodic checks on registrant validity and compliance with above requirements. Safeguards for Category 2 gTLDs: restricted registration policies 1. Strings in Category 1 may restrict registration, appropriate to risks. Be transparent and give equal access to registrars and registrants. 2. Generic gTLDs may have “exclusive” registry access if it serves a public interest goal. Non-exhaustive list of generic terms where applicant has proposed exclusive access: .antivirus, .app, .autoinsurance, .baby, .beauty, .blog, .book, .broker, .carinsurance,.cars, .cloud, .courses, .cpa, .cruise, .data, .dvr, .financialaid, .flowers, .food, .game, .grocery, .hair, .hotel, .hotels .insurance, .jewelry, .mail,.makeup, .map, .mobile, .motorcycles, .movie, .music, .news, .phone,.salon,.search, .shop, .show, .skin, .song, .store, .tennis, .theater, .theatre, .tires, .tunes, .video, .watches, .weather, .yachts c. For further GAC consideration (.amazon .patagonia .date .spa .yun .thai .zulu .wine .vin ) d. Ability for applicants to change applied-for string in order to address GACconcerns -- no prior BC position. Concerns with changing strings? e. Opinion of impacted community should be duly taken into account -- consistent with BC support for community priority for new gTLDs (2010) f. Reconsider contention sets for singular and plural versions of the same string. --consistent with BC consensus discussions before and in Beijing g. Initial protection for intergovernmental organization names and acronyms atsecond level --no official BC position, but generally supportive of GAC; --BC should support “Strawman” TMCH warning notices for IGOs -- at least until GAC review of RPMs one year after 75th gTLD is launched. 2. finalize RAA and require it for registrars selling domains in new gTLDs. --consistent with BC position (Jan-2012) 3. GAC’s 2007 Whois Principles should be “duly taken into account” by Directory Services Expert Working Group. (Susan K) 4. Amend registry agreement to require permanent protection of Olympics and Red Cross --no official BC position, but generally supportive of GAC; 5. more information on Public Interest Commitments (PIC) Specifications: 1. can 3rd party or governments raise concern about PIC compliance? 2. can applicants later amend their PICs? 3. will ICANN make registry operators aware of their PICs? 4. requirements to maximize public visibility of PICs? 5. how to amend where a registry made no PICs? (but should have) 6. Are PICs enforceable? --BC said ICANN should enforce PICs 7. Will ICANN follow sanctions recommended by PIC DRP? 8. Measures to remediate serious damage from past registration policies? <Notes for BC comments on Beijing GAC Advice.docx><Minutes BC Members call MAY 1 2013[1].pdf><BC May 1 2013.pdf>

1 0

For use in today's member call regarding BC comments on GAC Advice
by Steve DelBianco 06 May '13

06 May '13

Here is an outline for today's member discussion of BC comments on GAC Advice (below and attached) Public Comment page at http://www.icann.org/en/news/public-comment/gac-safeguard-advice-23apr13-en…. Initial comments due 14-May; Reply comments close 4-Jun. Full GAC Communique and Advice is at http://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf Just the Safeguards in section IV 1.b and Annex 1 are being posted for public comment. But let's discuss the BC also commenting on other GAC advice, such as Singular-Plural contention sets, Whois, etc. 1. New gTLDs: a. GAC objections to specific applications (. africa . gcc . islam . halal) b. Safeguards for new gTLDs (Annex 1) 1. Registry does Whois verification checks 2x per year 2. Registrant ToS should prohibit malware, botnets, phishing, piracy, TM/copyright infringement, fraud, deception, or anything contrary to applicable law. 3. Registry to periodically check domains in TLD for security threats (pharming, phishing, malware, botnets). Notify registrar and suspend domain if no immediate remedy. 4. Registry to maintain stats on inaccurate Whois , security threats found, and actions taken. 5. Registry needs mechanism to handling complaints about inaccurate Whois, security, etc. 6. Registry must ensure immediate consequences (incl suspension) for inaccurate Whois or domain use in breach of applicable law Safeguards for Category 1 gTLDs: consumer protection, sensitive strings and regulated markets (non-exhaustive list of TLDs in annex 1, page 9) 1. Registrant ToS should require compliance with applicable laws, incl privacy, consumer protection, fair lending, organic farming, disclosures 2. Registry will require registrars to notify registrants of ToS at time of registration. 3. Registry will require registrants collecting sensitive health or financial data have reasonable security measures as defined by applicable laws and industry standards. 4. Registry to establish relationship with regulators or industry self-regulatory body, plus strategy to mitigate risks of fraud & illegal activities. 5. Registry will require registrars to have single point of contact for complaints and mitigation Additional Safeguards for Category 1 gTLDs in financial, gambling, professional services, environmental, health and fitness, corporate identifiers, and charity: 6. Registry must verify and validate registrant authorization, charter, license or other credentials 7. if in doubt about credentials, Registry should consult with national supervisory authority 8. Registry must do periodic checks on registrant validity and compliance with above requirements. Safeguards for Category 2 gTLDs: restricted registration policies 1. Strings in Category 1 may restrict registration, appropriate to risks. Be transparent and give equal access to registrars and registrants. 2. Generic gTLDs may have “exclusive” registry access if it serves a public interest goal. Non-exhaustive list of generic terms where applicant has proposed exclusive access: .antivirus, .app, .autoinsurance, .baby, .beauty, .blog, .book, .broker, .carinsurance,.cars, .cloud, .courses, .cpa, .cruise, .data, .dvr, .financialaid, .flowers, .food, .game, .grocery, .hair, .hotel, .hotels .insurance, .jewelry, .mail,.makeup, .map, .mobile, .motorcycles, .movie, .music, .news, .phone,.salon,.search, .shop, .show, .skin, .song, .store, .tennis, .theater, .theatre, .tires, .tunes, .video, .watches, .weather, .yachts c. For further GAC consideration (.amazon .patagonia .date .spa .yun .thai .zulu .wine .vin ) d. Ability for applicants to change applied-for string in order to address GACconcerns -- no prior BC position. Concerns with changing strings? e. Opinion of impacted community should be duly taken into account -- consistent with BC support for community priority for new gTLDs (2010) f. Reconsider contention sets for singular and plural versions of the same string. --consistent with BC consensus discussions before and in Beijing g. Initial protection for intergovernmental organization names and acronyms atsecond level --no official BC position, but generally supportive of GAC; --BC should support “Strawman” TMCH warning notices for IGOs -- at least until GAC review of RPMs one year after 75th gTLD is launched. 2. finalize RAA and require it for registrars selling domains in new gTLDs. --consistent with BC position (Jan-2012) 3. GAC’s 2007 Whois Principles should be “duly taken into account” by Directory Services Expert Working Group. (Susan K) 4. Amend registry agreement to require permanent protection of Olympics and Red Cross --no official BC position, but generally supportive of GAC; 5. more information on Public Interest Commitments (PIC) Specifications: 1. can 3rd party or governments raise concern about PIC compliance? 2. can applicants later amend their PICs? 3. will ICANN make registry operators aware of their PICs? 4. requirements to maximize public visibility of PICs? 5. how to amend where a registry made no PICs? (but should have) 6. Are PICs enforceable? --BC said ICANN should enforce PICs 7. Will ICANN follow sanctions recommended by PIC DRP? 8. Measures to remediate serious damage from past registration policies?

1 1

Fellowship Application Round Opens for ICANN 48 in Buenos Aires, Argentina
by Benedetta Rossi 06 May '13

06 May '13

Dear BC Members, Please find below the ICANN Announcement for the Fellowshit Application Round for ICANN 48 in Buenos Aires, Argentina. -- Kind Regards, Benedetta Rossi BC Secretariat bc-secretariat(a)icann.org <https://community.icann.org/display/gnsobc/Home> https://community.icann.org/display/gnsobc/Home www.bizconst.org http://www.icann.org/en/news/announcements/announcement-01may13-en.htm Fellowship Application Round Opens for ICANN 48 in Buenos Aires, Argentina 1 May 2013 How Do I Apply for the Fellowship Program The Fellowship Program has demonstrated success in its mission to build capacity in the ICANN multi-stakeholder environment through focused interactive engagement between newcomers to ICANN and community members at each of the ICANN meetings. The program seeks to identify members of the Internet community who either have not previously been able to participate in ICANN processes and constituent organizations, or those who require further exposure to the Internet community and its work but cannot travel and attend a meeting without financial support. This outreach program seeks participants from developing regions and countries of the world, in order to help create a broader base of knowledgeable constituents who will become the new voice of experience in their regions and beyond. Applications to become an ICANN Fellow are assessed for each meeting by an independent selection committee. Priority is given to applicants who: meet minimum program requirements; are current residents of developing and least developed nations; and are interested in participating in the ICANN multi-stakeholder process and its supporting organizations, advisory committees or stakeholder groups. An effort will be made to include participants from the African region as it is the site of this ICANN meeting. All confirmed fellowship participants must comply with the terms and conditions of the Fellowship program, as outlined at <http://www.icann.org/en/about/participate/fellowships/terms-conditions> http://www.icann.org/en/about/participate/fellowships/terms-conditions. As stated within these terms and conditions, ICANN is a California non-profit public benefit corporation and must therefore comply with all the laws and regulations of California and the United States. Fellows are responsible for obtaining all travel visas once accepted into the program. ICANN will purchase tickets for Fellows after all necessary documentation has been obtained and Fellows demonstrate that they have obtained all necessary travel visas. Once all of the requirements for travel are met, the Fellowship program arranges for and covers the costs for airfare and hotel, as well as providing a stipend to assist with some meeting and subsistence costs. The stipend is provided after each selected candidate successfully completes the requirements of the Fellowship program, Recipients will be expected to actively participate in and contribute to ICANN processes during and after the meeting. As always, registration for ICANN's meetings is free for anyone wanting to attend. <http://www.icann.org/en/about/participate/fellowships> Find out more » Glen de Saint Géry GNSO Secretariat <mailto:gnso.secretariat@gnso.icann.org> gnso.secretariat(a)gnso.icann.org <http://gnso.icann.org/> http://gnso.icann.org

1 0

Public Comment: Proposed Modification of GNSO Operating Procedures Concerning the Deadline for the Submission of Reports and Motions
by Benedetta Rossi 06 May '13

06 May '13

Dear BC Members, Please find below an ICANN announcement regarding the Public Comment: Proposed Modification of GNSO Operating Procedures Concerning the Deadline for the Submission of Reports and Motions. Thank you, -- Kind Regards, Benedetta Rossi BC Secretariat bc-secretariat(a)icann.org <https://community.icann.org/display/gnsobc/Home> https://community.icann.org/display/gnsobc/Home www.bizconst.org <http://www.icann.org/en/news/announcements/announcement-02may13-en.htm> http://www.icann.org/en/news/announcements/announcement-02may13-en.htm Proposed Modification of GNSO Operating Procedures Concerning the Deadline for the Submission of Reports and Motions Comment / Reply Periods (*) Comment Open Date: 2 May 2013 Comment Close Date: 23 May 2013 - 23:59 UTC Reply Open Date: 24 May 2013 Reply Close Date: 14 June 2013 - 23:59 UTC Important Information Links <http://www.icann.org/en/news/announcements/announcement-02may13-en.htm> Public Comment Announcement <mailto:comments-gnso-op-procedures-02may13@icann.org> To Submit Your Comments (Forum) <http://forum.icann.org/lists/comments-gnso-op-procedures-02may13/> View Comments Submitted Brief Overview Originating Organization: Generic Names Supporting Organization (GNSO) Categories/Tags: * Policy Processes * Reviews/Improvements Purpose (Brief): The Generic Names Supporting Organization (GNSO) Council is proposing a modification of the GNSO Operating Procedures to make the deadline for the submission of reports and motions more precise and uniform. Current Status: As required by the ICANN Bylaws, a public comment forum is hereby initiated on the proposed changes. Next Steps: Following the closing of the public comment forum, the GNSO Council will review the comments received and revise its recommendations, if deemed appropriate. Staff Contact: Julie Hedlund <mailto:policy-staff@icann.org?subject=More%20information%20on%20the%20Propo sed%20Modification%20of%20GNSO%20Operating%20Procedures%20Concerning%20the%2 0Deadline%20for%20the%20Submission%20of%20Reports%20and%20Motions%20public%2 0comment%20period> Email Staff Contact Detailed Information Section I: Description, Explanation, and Purpose: The GNSO Council has determined that the language concerning the deadline for the submission of reports and motions in the current GNSO Operating Procedures lacks clarity. The GNSO Council thus proposes a modification of the GNSO Operating Procedures to make the deadline for the submission of reports and motions more precise and uniform. The proposed modification to the existing language in section 3.3 of the Procedures is as follows, with additions in bold and deletions stricken: Reports and motions should be submitted to the GNSO Council for inclusion on the agenda as soon as possible, but no later than 23:59 Coordinated Universal Time (UTC) 10 calendar days before the GNSO Council meeting. As required by the ICANN Bylaws, the GNSO Council is requesting community input on this proposed modification to the GNSO Operating Procedures. Section II: Background: The GNSO, its description, purpose(s), structures (e.g. Council, Stakeholder Groups), and governance mandate are covered in ICANN Bylaws, <http://www.icann.org/en/general/bylaws.htm#X> Article X, Sections 1-6. The Operating Procedures of the GNSO describes those supplementary elements of administration, governance, and other logistics/mechanics that are not already prescribed in the aforementioned ICANN Bylaws. Taken together, the ICANN Bylaws and the GNSO Operating Procedures are intended to provide a complete set of rules, procedures, and practices for governing the operations of the GNSO. The ICANN Bylaws require that any changes to the GNSO Operating Procedures are subject to a minimum 21 day public comment period ('The GNSO Operating Procedures shall be effective upon the expiration of a twenty-one (21) day public comment period, and shall be subject to Board oversight and review' - see article X, section 3, item 4, <http://www.icann.org/en/about/governance/bylaws#X> http://www.icann.org/en/about/governance/bylaws#X) Section III: Document and Resource Links: Current version of the GNSO Operating Procedures see <http://gnso.icann.org/en/council/gnso-operating-procedures-13sep12-en.pdf> http://gnso.icann.org/en/council/gnso-operating-procedures-13sep12-en.pdf [PDF, 488 KB] Section IV: Additional Information: Not applicable _____ (*) Comments submitted after the posted Close Date/Time are not guaranteed to be considered in any final summary, analysis, reporting, or decision-making that takes place once this period lapses. Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org <http://gnso.icann.org/>

1 0

Call for Volunteers: Drafting Team to develop charter for GNSO Working Group on Policy & Implementation
by Benedetta Rossi 06 May '13

06 May '13

Dear BC Members, Please find below an ICANN announcement regarding a call for volunteers for a drafting team to develop charter for GNSO WG on Policy & Implementation. Call for Volunteers: Drafting Team to develop charter for GNSO Working Group on Policy & Implementation In brief The Generic Names Supporting Organization (GNSO) Council seeks volunteers to serve on a Drafting Team that will be tasked to develop a charter for a Working Group to address issues that have been raised in the context of the recent discussions on policy & implementation that affect the GNSO (see Staff Discussion Paper <http://gnso.icann.org/en/correspondence/policy-implementation-framework-08j an13-en.pdf> and session in Beijing <http://beijing46.icann.org/node/37133> ). The Drafting Team is expected to submit the proposed Charter to the GNSO Council for approval. What This Team Will Do The Drafting Team is expected to develop a Charter on the basis of the GNSO Working Group Guidelines <http://gnso.icann.org/council/annex-1-gnso-wg-guidelines-08apr11-en.pdf> taking into account the Staff Discussion Paper as well as the discussions that took place in Beijing. At a minimum, the GNSO Council expects that the subsequent Working Group would provide recommendations on the following: 1. A set of principles that would underpin any GNSO policy / implementation related discussions 2. Recommendations on a process for providing GNSO "Policy Guidance" 3. A framework for implementation related discussions related to GNSO Policy Recommendations and 4. Further guidance on how GNSO Implementation Review Teams are expected to function and operate. How This Team Will Work ICANN Working Groups use transparent, open processes. The meetings of this DT will be recorded, and the recordings will be available to the public. The mailing list for the Drafting Team will be archived publicly. Drafting Team members are expected to submit Statements of Interest (SOI). The group will collaborate using a public workspace. The Drafting Team is expected to follow the GNSO Working Group Guidelines. <http://gnso.icann.org/council/annex-1-gnso-wg-guidelines-08apr11-en.pdf> How to Join The GNSO Council invites interested parties to provide names of expected participants who can then be added to the DT mailing list. The DT will be open to anyone interested to join. Community members who wish to be invited to join the group should contact the <mailto:gnso.secretariat@icann.org?subject=Application%20to%20Join%20Policy% 20%2526%20Implementation%20DT> GNSO secretariat (gnso.secretariat(a)icann.org) Background Mainly as a result of discussions stemming from implementation related issues of the new gTLD program, there is increased focus on which topics call for policy and which call for implementation work, including which processes should be used, at what time and how diverging opinions should be acted upon. In order to facilitate these discussions, ICANN Staff developed a draft framework for community discussion that identifies a number of steps and criteria that might facilitate dealing with similar questions in the future. The paper identifies a number of questions that the community may want to consider further in this context, as well as a couple of suggested improvements that could be considered in the short term. While developing a bright-line rule as to what is policy or implementation may not be possible, the hope is that by developing clear processes and identifying clear roles and responsibilities for the different stakeholders, it will become easier to deal with these issues going forward and allow for broad participation and involvement. Following several discussions by the GNSO Council on this topic, the GNSO Council has now decided to form a drafting team to draft a Charter for a Working Group which will be tasked to provide concrete recommendations on how to address some of these issues from a GNSO perspective. -- Kind Regards, Benedetta Rossi BC Secretariat bc-secretariat(a)icann.org <https://community.icann.org/display/gnsobc/Home> https://community.icann.org/display/gnsobc/Home www.bizconst.org

1 0

RE: [bc-gnso] RE: Outline for discussion of RAA comments today
by Elisa Cooper 03 May '13

03 May '13

Thanks Stephane – this wasn’t discussed on the call, so thank you for contributing. Best, Elisa Elisa Cooper Director of Product Marketing MarkMonitor Elisa Cooper Chair ICANN Business Constituency 208 389-5779 PH From: Stéphane Van Gelder [mailto:stephvg@gmail.com] Sent: Friday, May 03, 2013 1:26 AM To: Elisa Cooper Cc: Steve DelBianco; bc - GNSO list Subject: Re: [bc-gnso] RE: Outline for discussion of RAA comments today Elisa, Both excellent points. Your point 2 brings to mind a similar need for registrants, who would certainly gain from having a better understanding of the RAA. I'm sure Icann can help in this regard as well. Sorry if this was already covered in the call. Best, Stéphane Envoyé de mon iPhone4 Le 2 mai 2013 à 22:11, Elisa Cooper <Elisa.Cooper(a)markmonitor.com<mailto:Elisa.Cooper@markmonitor.com>> a écrit : Steve, Once again, great job in leading the discussion covering the Registrar Accreditation Agreement (RAA). Two additional overarching points I think we should also consider adding to our RAA comments are as follows: 1) With so many new registrar obligations, we are hopeful that ICANN Compliance is properly staffed to enforce the new agreement. 2) We would encourage ICANN to proactively educate all registrars of the new requirements, so that they all understand the new obligations and can comply with the new agreement. Thanks again. Best, Elisa Elisa Cooper Director of Product Marketing MarkMonitor Elisa Cooper Chair ICANN Business Constituency 208 389-5779 PH From: owner-bc-gnso(a)icann.org<mailto:owner-bc-gnso@icann.org> [mailto:owner-bc-gnso@icann.org] On Behalf Of Steve DelBianco Sent: Thursday, May 02, 2013 8:26 AM To: 'bc - GNSO list' Subject: [bc-gnso] Outline for discussion of RAA comments today Here's an outline for today's member discussion of BC comments on the RAA. (11am eastern US time) Public Comment page is here<http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm>. The proposed final RAA is here<http://www.icann.org/en/resources/registrars/raa/proposed-agreement-22apr13…>. Initial comments due 13-May Outline: 1. Privacy/Proxy Specification (link<http://www.icann.org/en/resources/registrars/raa/proposed-registrant-rights…>) There is no Service level specified for timing and methods to relay communications and reveal data to complainant. 2. Whois Maintain bulk access to Whois (port 43) "Willful provision of inaccurate or unreliable whois information" as basis to suspend a registration (3.7.7.2) If Registrant data isn't validated in 15 days, should registrations be suspended during manual validation? Should same accuracy requirement apply to Account Holder data as well? 3. Enforcement of Registrant Rights (link<http://www.icann.org/en/resources/registrars/raa/proposed-registrant-rights…>), in particular: "You shall not be subject to false advertising or deceptive practices by your Registrar or though any proxy or privacy services made available by your Registrar. This includes deceptive notices, hidden fees, and any practices that are illegal under the consumer protection law of your residence." Do we need additional clarity in order to enforce Registrar obligations? Proposed RAA says: RAA 3.7.10 Registrar shall publish on its website(s) and/or provide a link to the Registrants’ Rights and Responsibilities Specification attached hereto and shall not take any action inconsistent with the corresponding provisions of this Agreement or applicable law. Note: during the Beijing meeting, ICANN attorney Samantha Eisner told the BC that Public comment would be particularly valuable in these areas: Registrant rights & responsibilities. This was drafted by registrars. Validation of registrant data (registrant and account holder?) Penalties for inaccurate data Registrars want to drop Port 43 access for thick registries Unilateral amendment by ICANN. -- Steve DelBianco Executive Director NetChoice http://www.NetChoice.org and http://blog.netchoice.org +1.202.420.7482

1 0

Fwd: ICANN’s Noncommercial Users Request Board Review of Staff Decision to Expand Scope of Trademark Clearinghouse in Violation of ICANN’s Bylaws
by Stéphane Van Gelder Consulting 03 May '13

03 May '13

Colleagues, FYI. An interesting read. > > https://community.icann.org/display/gnsononcomstake/NCSG+Request+for+Recons… > > ICANN’s Noncommercial Users Request Board Review of Staff Decision to Expand Scope of Trademark Clearinghouse in Violation of ICANN’s Bylaws > > ICANN’s Non-Commercial Stakeholders Group (NCSG) has filed a Request for Reconsideration with ICANN’s Board of Directors regarding the staff’s decision to expand the scope of the trademark claims service beyond that provided by community consensus policy and in contradiction to ICANN Bylaws. > > Specifically at issue is ICANN staff’s unilateral decision to adopt the “trademark +50” proposal for new domains, which would provide trademark holders who have previously won a UDRP or court decision with rights to 50 additional derivations of their trademark in ICANN’s Trademark Clearinghouse (TMCH). Under staff’s plan, large trademark holders that register in the clearinghouse will be provided thousands of derivations of their trademarks since each separate country’s registration of the same trademark provides the brand owner with an additional 50 entries in the TMCH.[1] Entries in the TMCH trigger infringement warning notices to domain name registrants which can lead to increased liability for registrants, discourage lawful registrations, and chill speech on the Internet. > > ICANN’s bottom-up community-developed process for creating policy had approved of a TMCH model that allowed “exact matches” of trademarks only to be placed in the TMCH. In 2007, ICANN’s GNSO Policy Council, including representatives from the Intellectual Property and Business Constituencies, approved the GNSO recommendations that created special protections for trademark rights by a supermajority vote.[2] As part of the multi-year consensus process, both the subsequent Special Trademarks Implementation (STI) Team and the Implementation Review Team (IRT) considered the issue of providing rights to exact matches or additional derivations, and both community-developed teams specifically opted for exact matches only to be placed into the TMCH. ICANN’s CEO testified before U.S. Congress in 2012 that expanding the scope of the TMCH further would be inappropriate since it would create new rights that do not exist in law and ICANN should not be creating unprecedented rights.[3] > > Many months after the final TMCH model of exact matches only was published in ICANN’s Applicant Guidebook and new domain businesses relied on it when filing their applications, ICANN’s Intellectual Property and Business Constituencies lobbied ICANN’s new CEO to make drastic changes to the community-developed policy and grant additional trademark rights in the TMCH. > > After the October 2012 Toronto ICANN Meeting, a “strawman solution” was proposed by ICANN’s new CEO which included a number of IPC/BC’s substantive policy proposals to give trademark holders additional privileges in the domain name system, including changing the exact matches only standard approved of by the community. > > Yet ICANN’s CEO recognized that expanding the scope of the trademark claims service was a policy matter requiring GNSO Council guidance, as he stated on his blog[4] in December 2012; and the CEO did write to the GNSO Council to request guidance on this policy proposal. Under ICANN’s Bylaws, staff may not change GNSO-approved policy, except under a strict process that involves consulting with the GNSO and a 2/3 vote of the Board of Directors. > > NCSG filed comments on the proposed policy changes and warned against re-opening previously closed consensus agreements and circumventing ICANN’s stated bottom-up policy development process.[5] In addition to the flawed process for adopting this policy, NCSG also detailed substantive concerns with staff’s proposal to expand trademark rights beyond anything that exists in trademark law. It came as no surprise that only members of the IPC and BC supported the strawman proposals in ICANN’s comment period.[6] > > In the GNSO Council’s February 29, 2013 response to the CEO regarding the proposal to expand the scope of trademark claims, the GNSO Chair wrote, “the majority of the council feels that proposal is best addressed as a policy concern, where the interest of all stakeholders can be considered.”[7] Thus the GNSO Council also determined this specific proposal to be a policy matter, requiring consultation from the entire community before such a change could be made to existing GNSO Council approved policy. > > Yet with only an email sent on 20 March 2013, ICANN staff announced in an attached memorandum that it would expand the scope of the trademark claims service to give trademark holders rights to 50 additional derivations of their trademark, in contradiction to GNSO developed policy of exact matches only and the subsequent requested GNSO Council guidance on the matter.[8] > > Staff’s only explanation for such a drastic shift in the creation of new rights: “this proposal appears to be a reasonable add on to an existing service, rather than a proposed new service”. Thus with a single line of evasive text, years of hard-fought community consensus policy was brushed under the rug and the new era of policy development via ICANN staff edict was solidified. > > On 19 April 2013 NCSG filed this Request for Reconsideration of the staff decision because ICANN did not follow its stated process for changing GNSO-approved policy. If ICANN wants to deviate from Supermajority GNSO-approved policy, it must follow the process outlined in the organization’s Bylaws, Annex A Section 9.[9] As an organization that holds itself out as a champion of the bottom-up policy development process, ICANN is obligated to comply with community-developed policies, unless the Board of Directors can muster the necessary 2/3rd vote to over-turn the community decision. That mandatory process was not followed by ICANN’s staff or Board in over-turning the community-approved policy in favor of staff’s policy to expand the scope of TMCH. > > ICANN’s Board Governance Committee has thirty days in which to make to a recommendation to ICANN’s Board of Directors regarding the NCSG’s Request for Reconsideration or report to the Board on why no final recommendation is available and provide a timeframe for making a final recommendation on the matter. ICANN’s entire Board should consider the recommendation of the Board Governance Committee at its next regularly-scheduled Board meeting. > > Under Article IV Section 2 of ICANN’s Bylaws, the Request for Reconsideration process is a mechanism intended to reinforce ICANN’s accountability to the community for operating in a manner consistent with its Bylaws.[10] Because the staff’s unilateral decision to change GNSO-approved policy was not consistent with ICANN’s Bylaws and contradicted ICANN stated policy, NCSG filed the Request to correct the error and bring ICANN into compliance with its Bylaws and stated policies. > > NCSG requests that the Board reinstate the community-developed policy of giving trademark holders rights to include exact matches of their trademark only in the TMCH, which was the policy stated in ICANN’s Applicant Guidebook when ICANN accepted applications for new domains. > > NCSG’s Request for Reconsideration:http://www.icann.org/en/groups/board/governance/reconsidera… > Attachments to NCSG’s Request for Reconsideration: http://www.icann.org/en/groups/board/governance/reconsideration/request-att… > ICANN Website on Requests for Reconsideration: http://www.icann.org/en/groups/board/governance/reconsideration > [1] http://domainincite.com/12451-loophole-gives-trademark-owners-unlimited-cle… > > [2] http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm > > [3] http://www.internetcommerce.org/ICANN_Amnesia > > [4] http://blog.icann.org/2012/11/a-follow-up-to-our-trademark-clearinghouse-me… > > [5] http://ipjustice.org/wp/2013/01/14/statement-of-icanns-non-commercial-stake… > > [6] http://forum.icann.org/lists/tmch-strawman/msg00096.html See also: > > Comments of Registrar Stakeholder Group: http://forum.icann.org/lists/tmch-strawman/msg00027.html > > Comments from New TLD Applicant Group: http://forum.icann.org/lists/tmch-strawman/msg00014.html > > Comments of Non-Commercial Stakeholder Group: http://forum.icann.org/lists/tmch-strawman/msg00029.html > > Comments of the Internet Service Provider Constituency: http://forum.icann.org/lists/tmch-strawman/msg00011.html > > Comments of Public Interest Registry: http://forum.icann.org/lists/tmch-strawman/msg00024.html > > [7] http://gnso.icann.org/bitcache/d8eaf7ce8d121b69d340d1d14223520fd7d478b3?vid… > > [8] http://newgtlds.icann.org/en/about/trademark-clearinghouse/strawman-solutio… > > [9] http://www.icann.org/en/about/governance/bylaws#AnnexA > > GNSO Policy Development Process > > Section 9. Board Approval Processes. a. Any PDP Recommendations approved by a GNSO Supermajority Vote shall be adopted by the Board unless, by a vote of more than two-thirds (2/3) of the Board, the Board determines that such policy is not in the best interests of the ICANN community or ICANN. If the GNSO Council recommendation was approved by less than a GNSO Supermajority Vote, a majority vote of the Board will be sufficient to determine that such policy is not in the best interests of the ICANN community or ICANN. > > b. In the event that the Board determines, in accordance with paragraph a above, that the policy recommended by a GNSO Supermajority Vote or less than a GNSO Supermajority vote is not in the best interests of the ICANN community or ICANN (the Corporation), the Board shall (i) articulate the reasons for its determination in a report to the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council. > > c. The Council shall review the Board Statement for discussion with the Board as soon as feasible after the Council's receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement. > > d. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for the then-current recommendation. In the event that the Council is able to reach a GNSO Supermajority Vote on the Supplemental Recommendation, the Board shall adopt the recommendation unless more than two-thirds (2/3) of the Board determines that such policy is not in the interests of the ICANN community or ICANN. For any Supplemental Recommendation approved by less than a GNSO Supermajority Vote, a majority vote of the Board shall be sufficient to determine that the policy in the Supplemental Recommendation is not in the best interest of the ICANN community or ICANN. > > [10] http://www.icann.org/en/about/governance/bylaws#IV > >

1 0