ICANN/GNSO GNSO Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ispcp] Fwd: [Gnso-ppsai-pdp-wg] Proposed language concerning lawyers and P/P services

  • To: "Novoa, Osvaldo" <onovoa@xxxxxxxxxxxx>, "ispcp@xxxxxxxxx" <ispcp@xxxxxxxxx>
  • Subject: Re: [ispcp] Fwd: [Gnso-ppsai-pdp-wg] Proposed language concerning lawyers and P/P services
  • From: Malcolm Hutty <malcolm@xxxxxxxx>
  • Date: Tue, 20 Oct 2015 10:17:18 +0100
  • Authentication-results: platinum.linx.net (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=linx.net
  • Cc: "dawson@xxxxxxxxxxx" <dawson@xxxxxxxxxxx>, "tonyarholmes@xxxxxxxxxxxxxx" <tonyarholmes@xxxxxxxxxxxxxx>
  • Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linx.net; h= in-reply-to:user-agent:date:date:message-id:from:from:references :received:received; s=dkim; t=1445332639; bh=OxZEsRTxl9W7c6ZRnyR WWEJEY5ReLeg6TtRSnbTuUsQ=; b=pBDPQwMsBLroNxXlTOoCMQ07iJMYK9TS+aj pL3Wt5KHrFVYz2cW2+9EOozyXs20O7cxKff6qOPB8Dn7fneEW/KjHX7jsjpkqPBa fcwAAW1bNsi1CagjnnjuCOlMnBiklASU4Yro0xsencLm15nv/s/6aSIMeRQc6yFy V/QMp/ws=
  • In-reply-to: <98BD496D-864E-48C1-BAB7-56CC54E934D3@Antel.com.uy>
  • List-id: ispcp@xxxxxxxxxxxxxx
  • References: <D24ACBD4.19931%mary.wong@icann.org> <98BD496D-864E-48C1-BAB7-56CC54E934D3@Antel.com.uy>
  • Sender: owner-ispcp@xxxxxxxxxxxxxx
  • User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 20/10/2015 08:45, Novoa, Osvaldo wrote:
> All, I don't like this proposal, I think that everybody that supplies
> a service should do it under the same conditions. I am not a lawyer
> so I can't evaluate what would be the consequences of subjecting
> lawyers to this requirements, but if there is no way around I would
> prefer not to regulate anything. What's your opinion? Best regards, 
> Osvaldo

I think the basic P/P proposal is problematic, and this is an attempt to
fix one of the most common instances of the problems with it, but one
that just exposes that there is a more general underlying weakness.

I do think it is unwise (I don't know whether it is impossible) for
ICANN to try to regulate lawyers in this way. I share Osvaldo's dislike
for a special exception for lawyers. Perhaps more importantly, I'm not
at all sure that such an exception would be sufficient. So on balance I
think Osvaldo's suggestion of "prefer not to regulate everything" is all
we're left with.

A more lengthy explanation of my reasoning follows.

The main proosal aims to regulate (or, if you prefer to avoid that word,
set requirements for) "proxy/privacy services". But what is a
"proxy/privacy service"?

In general, it is always possible for one person to authorise another
person to do something on their behalf. This is, when analysed formally,
often called doing that thing "by proxy". You will all be familiar, for
example, with the situation where a person who is unable to attend a
meeting themselves authorises another person to attend and vote on their
behalf; this is commonly referred to giving that nominee "their proxy".

Similarly, it is perfectly possible for a person (A) to authorise
someone else (B) to go out and buy something for them. Again, we would
say that Person B is acting as a proxy for Person A.

In common law jurisdictions at least (and I assume elsewhere too) it is
possible for Person A to give Person B a more generalised authorisation
to act on their behalf. This is sometimes called "power of attorney".
This is useful is Person A anticipates being absent, or incapacitated,
or simply has such complex affairs that they need to rely on
professional advisors. In general, people give such powers to lawyers,
because they have professional skills in exercising them with care and
diligence, and because they're always willing to perform them in return
for a fee. But there is (under the law with which I am familiar at
least) nothing that limits Person A so that he may only give his proxy
or power of attorney to a lawyer: indeed, it is also very common to give
such powers to a close family member.

So having established that there is nothing unique to the domain name
industry about the concept of proxy or power of attorney, let's look at
what this means for this case.

In the domain name industry, certain registrars offer to act as a proxy
for registrants so as to conceal the name of the registrant from the
public record. They call this a "privacy/proxy service". When done by
registrars, it is done on an industrial scale, as a commercial service.
It is, however, no different in principle to asking your lawyer to
register a domain for you. Nor is it different in principle to asking
your brother to register a domain for you.

The P/P policy seeks to regulate (or place requirements on) those
providing such services. Where the people in question are registrars,
they're already part of the domain industry ecosystem, and it is
somewhat practical for ICANN to exercise authority over them. However,
if the policy only covers registrars, it is unlikely to be fully
effective in its aims.

Unfortunately, if ICANN tries to extend this to anyone who registers a
domain on behalf of someone else, they are effectively not only trying
to regulate lawyers/legal services, they are also effectively impinging
on the general legal right to authorise someone else to act on your behalf.

I'm not sure whether this is impossible, but it certainly does look like
overreaching, and it does seem unwise and likely to provoke unforeseen
consequences, risk of policy failure, and create the potential for
litigation. That really doesn't sound like something we should be
supporting. In that light, Osvaldo's suggestion of "prefer not to
regulate anything" seems like the best course.

            Malcolm Hutty | tel: +44 20 7645 3523
   Head of Public Affairs | Read the LINX Public Affairs blog
 London Internet Exchange | http://publicaffairs.linx.net/

                 London Internet Exchange Ltd
           21-27 St Thomas Street, London SE1 9RY

         Company Registered in England No. 3137929
       Trinity Court, Trinity Street, Peterborough PE1 1DA

<<< Chronological Index >>>    <<< Thread Index >>>