ICANN ICANN Email List Archives

[bc-gnso]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "'bc - GNSO list'" <bc-gnso@xxxxxxxxx>
  • Subject: [bc-gnso] For use in 10-May-2013 member call regarding BC comments on GAC Advice
  • From: Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>
  • Date: Fri, 10 May 2013 14:09:41 +0000

Here is an updated outline for Today's member discussion of BC comments on GAC 
Advice (below and attached).
Under the red headings I summarized discussion from prior calls.
Also attached are 8-May call minutes taken by Benedetta, our Secretariat.

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 the1-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 registries could 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 ICANNcould 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 and May 10
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.

Proposed BC comment:

q  Registry should be responsible for safeguards 6,7,8 only where the registry 
commits to restricted registration, whether in their application, Public 
Interest Commitment (spec 11), or in TLD’s advertised registration policies.

q  Any government may request a registry add restrictive registration to their 
PICspec.

q  ICANN needs an approval process for registries needing to amend their PIC 
Specs at any time.

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

Proposed BC comment:

q  Agree with 1 above.

q  For 2, the Registry Code of Conduct was written with this in mind, since TLD 
operators must obtain an exemption to the code of conduct to register their own 
names (and avoid use of all registrars).  Now ICANN should clarify the process 
and criteria for a TLD to meet the “public interest” test for the exemption.

q  Process to include public comment?

q  Criteria: The BC has previously proposed a public interest definition: ICANN 
serves the global public interest by maintaining the integrity and availability 
of registrations and resolutions.

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.
Proposed BC Comment: clarify the rule and re-do the independent panel review.

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?

Attachment: Notes for BC comments on Beijing GAC Advice.docx
Description: Notes for BC comments on Beijing GAC Advice.docx

Attachment: Minutes BC Members call MAY 08 2013[1].pdf
Description: Minutes BC Members call MAY 08 2013[1].pdf



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy