[NCUC-DISCUSS] Registrants Rights and Responsibilities: let's propose a real alternative
Timothe Litt
litt at acm.org
Wed Apr 10 13:25:09 CEST 2013
> "As mentioned there is an existing document on the ICANN website that relates to the 2009 version for the RAA.
>
> "Registrant Rights and Responsibilities Under the 2009 Registrar Accreditation Agreement" http://www.icann.org/en/resources/registrars/registrant-rights-responsibilities
> Does Wendy's list and subsequent discussion provide a basis for responding to this?
Wendy's list + my previous notes are necessary, but not sufficient.
They are incremental to current understandings/practice, and are hardly
comprehensive.
I took a brief look at the referenced URL. The document there is both
large, and to most people, incomprehensible. Its 'rights' for
registrants are limited; its protections for registrars/registries/ICANN
are extensive.
Although it is in English, it's hardly 'Plain Language'. It's not
organized in any way meaningful to the registrant; it's just a jumble of
stuff pulled from other documents to meet the requirement for 'doing
something'. Or perhaps it was a good faith perliminary attempt to
identify what should go into a document that got misinterpreted as a
final product. There are a few concessions to the need to explain legal
jargon - though the end result is hardly clarity.
Also, note that it is not enforceable; "The summarization of terms
within this document do not override or replace the terms set forth in
the RAA or within those specifications or policy."
Among the provisions that jumped out at me:
"As the RAA is between ICANN and a Registrar, no one else -- including a
Registered Name Holder -- may sue ICANN or the Registrar to claim a
breach of the RAA." (Third-party beneficiary clauses.)
OK, so we have rights, but we can't sue to enforce them. (Yes, there
may - or may not - be the ability to sue the registrar under the
registrant-registrar agreement. But if a registrar doesn't insert/live
up to the required language, the registrant has no leverage to obtain
compliance. Hat-in-hand, it can ask ICANN to do something, but there's
no obligatory response.)
"The Registered Name Holder shall "indemnify and hold harmless the
Registry Operator and its directors, officers, employees, and agents
from and against any and all claims, damages, liabilities, costs, and
expenses (including reasonable legal fees and expenses) arising out of
or related to the Registered Name Holder's domain name registration."
So, if the Registry Operator doesn't pay it's electric bill and gets
sued, the RNH pays the bill and their lawyer? In any case, the RNH does
business with the Registrar, not the RO.
"If there is a dispute in connection with the use of the registered
name, the Registered Name Holder must agree to jurisdiction of the
courts in at least one of two places: where the Registrar is located
(often stated on the website or in the Registrar/Registered Name Holder
Agreement) or the "Registered Name Holder's domicile."
What registrar has a single location? As a practical matter, large (US)
enterprises tend to be incorporated in Delaware, and have places of
business in multiple jurisdictions. Speaking as a registrant, I would
want "...the Registrar must agree to the jurisdiction of the courts in
at least the Registered Name Holder's domicile." Why should a resident
of Hawaii be forced to travel to Virginia to sue Verisign? This is a
standard tactic for the convenience of the drafter of a legal agreement
so it doesn't need to maintain representation in more than one place.
And why is this an ICANN matter? It might be if it helped shift the
balance of power from the registrar to the (individual/non-commercial)
registrant. But as is, it's simply assisting the registrar and doing
nothing for the registrant.
"A Registrar has to agree that it will take reasonable precautions to
protect the Registered Name Holder's data from 'loss, misuse,
unauthorized access or disclosure, alteration, or destruction'."
This is hardly exhaustive - I don't have time or expertise to pursue
this matter. But it is clear that there's a lot of work required to
create a registrant-centered document. It's not just the language that
creates a barrier. It's also a question of organization, which should
match the registrants activities. And size; if the key points (or at
least the table of contents) don't fit on a single screen, only the
truly obsessive will read it. The goal ought to be universal compliance,
not just mazes of legal protections.
As a rough benchmark, consider the difference between the laws on
operating a motor vehicle, and the driver's handbook that the states put
out to license applicants. (At least in the US and Europe.) The laws
are thousands of pages of detail, and still interpretations are fought
over in court every day. The handbooks are typically less than 100
pages, written in large print, with pictures and at the reading level of
a young adult...and they are self-contained, not a bunch of references
to other documents. And they are updated as the laws change.
I hope these notes are helpful in advancing the discussion. Sorry that
I'm unable to volunteer to do more.
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 09-Apr-13 19:02, Milton L Mueller wrote:
> In our interactions with the board on Tuesday, we discovered that the current statement of registrant rights and responsibilities was developed by the registrars in connection with their RAA negotiations. In response to our suggestion that maybe registrants ought to be consulted a bit on what their rights should be, Board member Bruce Tonkin wrote the following:
>
> "As mentioned there is an existing document on the ICANN website that relates to the 2009 version for the RAA.
>
> "Registrant Rights and Responsibilities Under the 2009 Registrar Accreditation Agreement" http://www.icann.org/en/resources/registrars/registrant-rights-responsibilities
>
> "As you will see it is more geared towards lawyers than towards a typical registrant.
> The latest version for the 2013 RAA I think was an attempt to simplify for a more general audience.
>
> "I think it would be a good idea for the NCUC to work with ALAC to create a set of principles as it relates to registrant rights, in the same way that the GAC created a set of public policy principles as they related to new gTLDs and WHOIS."
>
> Does Wendy's list and subsequent discussion provide a basis for responding to this? Who wants to take ownership of this process, including involving ALAC?
>
>> -----Original Message-----
>> From: ncuc-discuss-bounces at lists.ncuc.org [mailto:ncuc-discuss-
>> bounces at lists.ncuc.org] On Behalf Of Timothe Litt
>> Sent: Tuesday, April 09, 2013 8:54 AM
>> To: ncuc-discuss at lists.ncuc.org
>> Subject: Re: [NCUC-DISCUSS] Registrants Rights and Responsibilities:
>> let's propose a real alternative
>>
>>> the registrars argued that
>>> uniform rules would interfere with their "competitive" differences as
>>> defined by the contract terms in their individual registration
>>> agreements with customers.
>> That may well be their knee-jerk reaction, but in this case it's wrong.
>>
>> Nothing I suggested prevents vigorous competition on terms. Rather the
>> contrary.
>>
>> All I suggested is that:
>> * Registrant must be pro-actively notified of changes
>> * Changes must be easily determined by the registrant
>> * Changes adverse to the registrant must enable the registrant to
>> change registrars under (at worst) the terms initially agreed-upon.
>>
>> If the initial terms are changed in a way beneficial or neutral to the
>> registrant, everyone is happy.
>>
>> If they are changed in a *materially adverse* way, the registrar can't
>> hold the registrant captive. (Materially adverse is a term of art -
>> usually self-evident, but might provide employment for attorneys.)
>>
>> The initial terms might be what we would consider outrageous, but if
>> clearly disclosed and agreed to, that's not our concern. Registrars are
>> free to compete on price, or what DNS records they'll register, or how
>> fast they'll implement changes, or what language they speak, or how
>> disputes are resolved or what choice of law applies to their contracts.
>> Or anything else.
>>
>> The constraints - which are simply transparency and fairness - are that
>> if the registrar changes those terms, the change needs to be clear and
>> pushed to the registrant. And that if they are bad for the registrant,
>> the new terms (which were unknown at the time the contract was entered
>> into) can't lock the registrant into the worsened situation. (This must
>> also apply to changes pushed to the registrar from the
>> registry/ICANN/legal process - this is why I said "many levels of the
>> registration hierarchy".)
>>
>> This is pro-competition, pro-consumer, pro-registrar - any registrar
>> should welcome these constraints. It ensures that any registrar who
>> behaves ethically and doesn't abuse its customers can solicit the
>> customers of those who are unethical/abusive. Since all registrars are
>> (or want the appearance of being) ethical, transparent actors serving
>> the interests of their customers, who would possibly object?
>>
>> However, they won't be put in place unless they are universally applied.
>> This is one of those cases where "If I do the right thing, but my
>> competitors don't, I'm at a disadvantage." Requiring these as standard
>> terms removes that excuse.
>>
>> And that's what we should argue for.
>>
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views, if
>> any, on the matters discussed.
>>
>> This communication may not represent my employer's views, if any, on the
>> matters discussed.
>>
>> On 08-Apr-13 15:38, Ron Wickersham wrote:
>>>
>>> On Mon, 8 Apr 2013, Timothe Litt wrote:
>>>
>>> These are important and great "rights" you propose.
>>>
>>>> A decent registrar would pro-rate any remaining term - but I don't
>>>> think we can impose that, and a decent registrar wouldn't run afoul
>>>> of the language. Anyhow, that's not the big cost.
>>> Note that when you change registrars the term of registration doesn't
>>> change within the same year, as that date is preserved by the
>>> registry. There is a possiblity that multi-year renewals are held by
>>> your registrar and only forwarded to the registry on the annual
>>> renewal date.
>>>
>>> I spoke in favor of some of these rights in the limited context of
>>> PEDNR (post expiry domain name recovery), and found the registrars
>>> argued that uniform rules would interfere with their "competitive"
>>> differences as defined by the contract terms in their individual
>>> registration agreements with customers.
>>>
>>> I expect that the rights you outline would be even more vigorously
>>> opposed yet we should bring them forward to place on the record that
>>> the current "competitive" practices that are changable without notice
>>> leave registrants powerless to look out on their own for rights.
>>>
>>> -ron
>>> _______________________________________________
>>> Ncuc-discuss mailing list
>>> Ncuc-discuss at lists.ncuc.org
>>> http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
> _______________________________________________
> Ncuc-discuss mailing list
> Ncuc-discuss at lists.ncuc.org
> http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20130410/75520119/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5159 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.ncuc.org/pipermail/ncuc-discuss/attachments/20130410/75520119/attachment-0001.bin>
-------------- next part --------------
_______________________________________________
Ncuc-discuss mailing list
Ncuc-discuss at lists.ncuc.org
http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
More information about the Ncuc-discuss
mailing list