[bc-gnso] Also for discussion of BC comment on RAA
bill.smith at paypal-inc.com
Sat Apr 27 00:55:18 UTC 2013
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
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bc-gnso