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

Smith, Bill bill.smith at paypal-inc.com
Mon Apr 29 21:41:24 UTC 2013

I am especially concerned with the establishment of The Working Group. Section 6 of the agreement details the makeup of this new group - registrars and anyone else registrars determine are appropriate, including no other participants. Section 6 and 7 of the agreement contain numerous references to the Working Group. In addition, the transition addendum references the same group indicating it, with ICANN will determine an appropriate set of tools to enable cross validation.

Call me a skeptic but I see this as the opening of the door for evermore direct registrar-ICANN policy making and as a consequence will result in registrants having even less say in issue of import.

The version of the agreement distributed to the public on 13 March had ICANN selecting additional participants. The change to Registrars making these decisions is significant, and demonstrates (to me) how much control they wish to exert, independent of other members of the Community. To be clear, regardless of who selects additional members of the group, I think The Working Group is likely a very bad idea.

I think the potential for abuse of the group is significant. Its use in the transition addendum represents perhaps just the first use beyond the limited scope (Section 6) of the agreement. The Working Group is used not only in Section 6, where it is defined with a scope limited to that section, but also is used in Section 7 and in the transition addendum.

>From my perspective, use of the term outside Section 6 is dangerous precedent.

A solution of course is to make The Working Group a defined term at the Agreement level. This would be consistent with its use in Section 7 and the transition addendum. It would also permit its use anywhere else in the agreement, and later within ICANN.

>From my perspective, registrants are being told yet again, you have no rights other than what registrars decide to give you… and they have been generous enough to provide a list of them for you. I'll note that the rights so provided are meager at best and are likely already guaranteed in many jurisdictions throughout the world.

On Apr 29, 2013, at 1:49 PM, Phil Corwin <psc at vlaw-dc.com<mailto:psc at vlaw-dc.com>>


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

Twitter: @VlawDC

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

From: owner-bc-gnso at icann.org<mailto:owner-bc-gnso at icann.org> [mailto:owner-bc-gnso at icann.org<mailto:bc-gnso at icann.org>] 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 at hotmail.com<mailto:marilynscade at hotmail.com>> wrote:

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.

From: AHansen at council.bbb.org<mailto:AHansen at council.bbb.org>
To: sdelbianco at netchoice.org<mailto:sdelbianco at netchoice.org>; bc-gnso at icann.org<mailto:bc-gnso at icann.org>
Subject: [bc-gnso] Also for discussion of BC comment on RAA
Date: Fri, 26 Apr 2013 14:30:23 +0000

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 Karina Hansen  Deputy General Counsel

Tel: 703-247-9340
Fax: 703-276-0634
Email: ahansen at council.bbb.org<mailto:ahansen at council.bbb.org>
bbb.org<http://www.bbb.org/>  Start With Trust®

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 at icann.org<mailto:owner-bc-gnso at icann.org> [mailto:owner-bc-gnso at icann.org<mailto:bc-gnso at icann.org>] 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

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

More information about the Bc-gnso mailing list