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

["Benedetta Rossi" <bc-secretariat@xxxxxxxxx>]

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@xxxxxxxxx> bc-secretariat@xxxxxxxxx

 <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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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>