<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<blockquote type="cite">
<pre wrap="">"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" <a class="moz-txt-link-freetext" href="http://www.icann.org/en/resources/registrars/registrant-rights-responsibilities">http://www.icann.org/en/resources/registrars/registrant-rights-responsibilities</a> </pre>
</blockquote>
<blockquote type="cite">
<pre wrap="">Does Wendy's list and subsequent discussion provide a basis for responding to this?</pre>
</blockquote>
<br>
Wendy's list + my previous notes are necessary, but not
sufficient. They are incremental to current
understandings/practice, and are hardly comprehensive.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 <abbr title="Registrar Accreditation Agreement">RAA</abbr>
or within those specifications or policy."<br>
<br>
Among the provisions that jumped out at me: <br>
<br>
"As the <abbr title="Registrar Accreditation Agreement">RAA</abbr>
is between <abbr title="Internet Corporation for Assigned Names
and Numbers">ICANN</abbr> and a Registrar, no one else –
including a Registered Name Holder – may sue <abbr
title="Internet Corporation for Assigned Names and Numbers">ICANN</abbr>
or the Registrar to claim a breach of the <abbr title="Registrar
Accreditation Agreement">RAA</abbr>." (Third-party beneficiary
clauses.)<br>
<br>
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.)<br>
<br>
"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." <br>
<br>
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.<br>
<br>
"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." <br>
<br>
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.<br>
<br>
"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'."<br>
<br>
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.<br>
<br>
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.<br>
<br>
I hope these notes are helpful in advancing the discussion. Sorry
that I'm unable to volunteer to do more.<br>
<pre class="moz-signature" cols="72">
Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
</pre>
On 09-Apr-13 19:02, Milton L Mueller wrote:<br>
</div>
<blockquote
cite="mid:855077AC3D7A7147A7570370CA01ECD23A572E@SUEX10-mbx-10.ad.syr.edu"
type="cite">
<pre wrap="">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?
</pre>
<blockquote type="cite">
<pre wrap="">-----Original Message-----
From: ncuc-discuss-bounces@lists.ncuc.org [mailto:ncuc-discuss-
bounces@lists.ncuc.org] On Behalf Of Timothe Litt
Sent: Tuesday, April 09, 2013 8:54 AM
To: ncuc-discuss@lists.ncuc.org
Subject: Re: [NCUC-DISCUSS] Registrants Rights and Responsibilities:
let's propose a real alternative
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">
On Mon, 8 Apr 2013, Timothe Litt wrote:
These are important and great "rights" you propose.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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@lists.ncuc.org
http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Ncuc-discuss mailing list
Ncuc-discuss@lists.ncuc.org
http://lists.ncuc.org/cgi-bin/mailman/listinfo/ncuc-discuss
</pre>
</blockquote>
<br>
</body>
</html>