I: [bc-gnso] For use in 8-May-2013 member call regarding BC comments on GAC Advice

Wed May 8 14:47:29 UTC 2013

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 at 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 at 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 at 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.htm.

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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/bc-gnso/attachments/20130508/d7bb029a/attachment.html>