RE: [bc-gnso] Also for discussion of BC comment on RAA

[Phil Corwin <psc@xxxxxxxxxxx>]

Bill:

Thanks for your feedback on the RAA, discouraging as it is.

I'd very much appreciate it if you could expand on this statement: "On the down 
side, registrants gain no useful "rights" and in fact will be forced to abandon 
important rights if ICANN and the registrars enter into this agreement." That 
is, what important registrant rights do you believe will be stripped away?

Thanks in advance.

Best regards, Philip


Philip S. Corwin, Founding Principal
Virtualaw LLC
1155 F Street, NW
Suite 1050
Washington, DC 20004
202-559-8597/Direct
202-559-8750/Fax
202-255-6172/cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
Smith, Bill
Sent: Friday, April 26, 2013 8:55 PM
To: Marilyn Cade
Cc: Anjali Hansen; Steve Delbianco; bc - GNSO list
Subject: Re: [bc-gnso] Also for discussion of BC comment on RAA

I have been attempting to review the new RAA and am about to give up. I have 
spent the better part of 12 hours on planes, sleepless nights in hotels, and 
other "down time" trying to make sense of the new RAA missive.

The document is now some 42 pages in length supplemented by nearly 25 pages of 
specifications representing a rough tripling of the volume of information that 
must be reviewed. Various buts of information contained within both the 
agreement and specifications  are intricately worded with numerous cross 
references, exceptions, and other provisos. It may become the quintessential 
example of how not to structure or author a legal agreement.

Registrants need not worry since the changes to section 3.7.7 are relatively 
minor and easy to understand. That section is somewhat out of place in what I 
find an otherwise inscrutable document. On the down side, registrants gain no 
useful "rights" and in fact will be forced to abandon important rights if ICANN 
and the registrars enter into this agreement.

A new concept, The Working Group, has been introduced and will no doubt be 
positioned as an efficiency enhancing mechanisms to effect RAA change. That is 
entirely possible as is the potential disenfranchisement of registrants and 
registries with respect to registrar-related policies. The Working Group will 
consist of representatives of the "Applicable Registrars and other members of 
the community that the Registrar Stakeholder Group appoints from time to time".

This explains why several members of the registrar community have said to me 
that I (and I now suspect no other non-registrar) will ever sit in on a 
discussion/negotiation of the RAA. This is not and can not be considered a 
multi-stakeholder approach.

I have also read, and attempted to understand how the new WHOIS requirements 
will enhance accuracy and consequently mitigate the well-documented issues of 
using WHOIS to seek corrective action for a range of detrimental or malevolent 
actions. At this time, I believe the provisions in the proposed RAA, if 
implemented, may do little to help. I also suspect it may be possible for 
registrars to indefinitely postpone implementation of some of the provisions. 
One way to interpret the language suggest that to be the case. Another reading 
would set a time limit of 1 January 2014.

It also appears that bulk access to WHOIS data will be effectively eliminated.

Much of what I see implemented in the proposed RAA was never discussed within 
the ICANN Community. Provisions, really policy, seems to have been invented out 
of whole cloth with little regard for ICANN's supposed bottoms-up, 
consensus-based, multi-stakeholder model.

I fear we will have this agreement for some time to come. I further fear that 
registrants are losing important rights. Lastly, I am more convinced that ICANN 
is operating not in the public interest but rather in the interest of 
contracted parties - including themselves.

Preparing a well-reasoned response to the proposed RAA would require resources 
beyond those available to the BC or any other member of "the public". Without 
such a review, about all I can recommend is that we propose to start over from 
a blank sheet and attempt to develop a document that is simple, understandable, 
and consistent with the principles of this Community

On Apr 26, 2013, at 8:54 AM, Marilyn Cade 
<marilynscade@xxxxxxxxxxx<mailto:marilynscade@xxxxxxxxxxx>> wrote:


Anjali,
Would it possibly be useful to have a 45 min call with interested members to 
assist? so many of us are drowning in other items that drafting may escape 
us,but I could join a brief call.

I take note that this is now a fairly complex updated document, and that is 
helpful to share views?

Not sure if that is useful to your rapporteur efforts, but I can join a call if 
that is helpful. Probably can't do drafting.

I agree that the 'improved' RAA is quite important for the BC members.  Maybe 
Steve could also tell us what /whether the BC's scorecard issues were met, 
which might help define some input.

Marilyn
________________________________
From: AHansen@xxxxxxxxxxxxxxx<mailto:AHansen@xxxxxxxxxxxxxxx>
To: sdelbianco@xxxxxxxxxxxxx<mailto:sdelbianco@xxxxxxxxxxxxx>; 
bc-gnso@xxxxxxxxx<mailto:bc-gnso@xxxxxxxxx>
Subject: [bc-gnso] Also for discussion of BC comment on RAA
Date: Fri, 26 Apr 2013 14:30:23 +0000
All,


I volunteered to draft comments for the BC on the proposed revisions to the 
RAA.  As Steve noted, ICANN recently released an updated version of the RAA, 
which may address some of the BC members' prior concerns.  See ICANN's issues 
memo (attached) on the latest revisions as a summary.


If any of you have had the chance to look at the latest version and can provide 
input today at our meeting, that would be great.  However, comments are now not 
due until May 13, so I would welcome your written comments by next Thursday.  I 
can then circulate a draft of the comments to everyone by end of next week.


There are a lot of specifications that need to be looked at as well.  Here is 
the link: 
http://www.icann.org/en/news/public-comment/proposed-raa-22apr13-en.htm


I had no idea what I was taking on when I volunteered for this project!  I will 
be greatly relying on everyone's input.


Thank you and talk with you soon,


Anjali


Anjali Karina Hansen  Deputy General Counsel


Tel: 703-247-9340
Fax: 703-276-0634
Email: ahansen@xxxxxxxxxxxxxxx<mailto:ahansen@xxxxxxxxxxxxxxx>
bbb.org<http://www.bbb.org/>  Start With Trust(r)


Council of Better Business Bureaus, Inc.
3033 Wilson Boulevard, Suite 600
Arlington, VA  22201


For consumer tips, scams and alerts: Read our blog
<http://www.bbb.org/blog/>Find us on: Twitter<http://www.twitter.com/bbb_us> | 
Facebook<http://www.facebook.com/pages/Better-Business-Bureau-US/25368131403> | 
LinkedIn<http://www.linkedin.com/groups?about=&gid=1917928&trk=anet_ug_grppro> 
| YouTube<http://www.youtube.com/user/BBBconsumerTips> | 
Flickr<http://www.flickr.com/photos/bbb_us>


This message is a private communication, and may contain confidential and/or 
privileged information. If you have received this message by mistake, please 
notify the sender by reply email and then delete the message from your system 
without printing, copying or forwarding it. Thank you.


From: owner-bc-gnso@xxxxxxxxx<mailto:owner-bc-gnso@xxxxxxxxx> 
[mailto:owner-bc-gnso@xxxxxxxxx<mailto:bc-gnso@xxxxxxxxx>] On Behalf Of Steve 
DelBianco
Sent: Friday, April 26, 2013 9:53 AM
To: 'bc - GNSO list'
Subject: [bc-gnso] for discussion of BC comment on GAC Advice for new gTLDs


This is for discussion during today's BC Member call, during the Policy segment 
of the agenda.


Background for BC comments on Beijing GAC Advice
Full GAC Communique and Advice from Beijing 
here<http://www.icann.org/en/news/correspondence/gac-to-board-18apr13-en.pdf>.  
      Initial public comments due 14-May
1. New gTLDs:
a. GAC objections to specific applications (. africa . gcc . islam . halal)


b. Safeguards for new gTLDs (Annex 1)
Safeguards for all new gTLDs


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, disclsoures
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?

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2013.0.2904 / Virus Database: 3162/6262 - Release Date: 04/21/13