[gnso-whois-wg] Comments on WWG report draft 1.5 -- Sections 1-4

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

Here are some comments on Part 1 of the report.  - Dan


 * Procedure for determining agreement levels:  As there seems to be some
disagreement as to whether points are agreed or not, I wonder if we could
have an explication in more detail of the definitions in the introduction,
lines 68-74.  For example, what is the quantitative definition of "broad
agreement" and how exactly is it determined by the "ultimate authority"?
Does it draw off of the email list postings or only from whoever happens to
be able to show up for the live conference calls?  If the judgment seems to
be mistaken, can we require the judge to explain the judgment, referring to
transcripts (and emails on the list)?  Exactly what form of accountability
is available to ensure genuine consensus in case the ultimate authority
seems to be in error?


 * Section 1, Line 81:  Protecting personal privacy systematically is a
clear "public interest" issue, so I would strongly object to the framing of
this topic as "privacy versus public interest."  Also, combatting fraud is
of strong interest to non-consumers such as banks and other institutions
that bear significant liability for such fraud.  I would suggest instead:

"Balancing personal privacy against harmful use of domains"

In the second paragraph of section 1, there are references to "exceptions".
It is not explained what the exceptions refer to.  I think we ought to
preface these comments with a statement that protecting personal privacy of
natural persons is the default stance, and that exceptions to this default
need to be carefully considered and limited to explicitly confirmed
legitimate circumstances.


 * Proportionality of costs, lines 97-101:  We should add that the
"implicit burden" of costs needs to be evaluated in context of the
resources of those who would bear those costs.  (Fifty dollars makes a
bigger difference to me than to Bill Gates, to use an extreme case.)


 * Section 2.3, verification of OPoC:  Ross has voiced concerns about a
non-real-time registration process.  So what if we require all information
(including OPoC email verification) to be completed before the registration
can be fully *initiated*?  If this step is left out, then there would be no
"hold" on the domain name, and the registration process would be entirely
aborted.  Given that there will likely be some considerable demand for
"on-demand OPoC services" to enable quick registration, I would expect that
there would be supply emerging naturally to serve that demand.


 * OPoC as agenct to registrant, line 156:  I agree in part with Ross'
statement that "agency law can be used" to govern liabilities of the OPoC.
I would suggest that the OPoC need have no direct liability to the
registrar, but rather the registrant would be responsible for ensuring that
the OPoC confirms the email address in order to complete the registration.
The OPoC must only confirm to the registrant that the OPoC consents to
being the registrant's OPoC.


 * Proxy services, lines 176-196:  I think I understand Ross' comments
here, and I would suggest that the intent of the agreement here is that
proxies should not be able to hide their contact info by designating an
OPoC, since they are essentially a sort of OPoC to begin with.

In order to make the data collection and user interface consistent, the
requirement that proxies must designate themselves as an OPoC if they
designate any OPoCs at all would seem to satisfy that goal.  If there are
more efficient ways to implement this setup, then perhaps the registrars
might suggest an alternative model that accomplishes an equivalent result.


 * Section 3.2, Reveal, line 294 etc.:  If the Reveal function of the OPoC
is to stand, then I suggest we must define the legal standing of requesters
to demand a Reveal.  I would also suggest that self-declaration is not
sufficient to establish standing, but rather some form of legal due process
must be involved to avoid the potential for a sham legal notice to be
accepted for such purposes.


 * Identity of registrant, Line 303:   Identity of a registrant is not
hidden in the OPoC paradigm, only personal contact information.  So I don't
understand in what cases legal notice is prevented from being served
without Reveal.  I assume that ICANN can require the registrant (via its
contracts with registries and registrars, passing through to the
registrants) to legally bind the OPoC to Relay legal notices to the
registrant.  Thus, it is possible to arrange the OPoC liabilities such that
the OPoC acts as a legal representative for the registrant, and any notice
served on the OPoC is binding on the registrant.


 * Authentication, line 309:  Given that the Access function should be
subject to authentication of those who would have access, then Reveal
should also be subject to authentication of requesters of hidden contact
information.  There is utterly no reason that I can see that these two
methods should be treated differently in principle.  If the only reason to
retain a Reveal function for the OPoC is to serve as a loophole when Access
is inconvenient, then we should remove the Reveal function and deal with
Access authentication on its own merits to satisfy legitimate needs on all
sides.  I suspect the alleged "alternate/minority view" in lines 313-314 is
in fact a second supported view, but we need to clarify the process of
determining agreement levels in order to clarify this point.

It should be reiterated that Access is superior to Reveal in that it need
not notify the registrant that personal contact data has been accessed,
when the registrant is indeed involved in fraudulent and/or harmful
activity surrounding the use of the domain.


 * Reveal conditions, line 316 etc.:  I think this overstates the cases,
even if requesters have been properly authenticated.

For example, intellectual property infringement cannot be confirmed by
virtue of a mere claim, even with tangible evidence, because judicial
involvement is required to establish such judgments as fair use in the case
of copyrights, etc.  Again, if legal notice can be served on the OPoC in
such cases (like C&D notices) and those notices can be legally considered
as served on the registrant, then there is no need to reveal.

I also agree with Ross that alleged inaccurate Whois data in and of itself
(in the absence of any other claim of harm) is insufficient to mandate
revealing personal contact information.

I see no way to determine if Relay has failed, other than lack of response
by the registrant.  If there are time-delays to be considered, it seems
more appropriate to consider that in the context of Remedy, not Reveal.

Bottom line:  I still see no specific reasons that Reveal must exist
separate from Access, and I suggest it be removed abjectly from our
recommendations and that the implementation options be removed.


 * Section 3.3, Remedy, lines 334 etc.:  I agree with Vittorio's comments
that the OPoC's actions should be determined/controlled by the registrant.
This is commensurate with my comment above that the OPoC should be legally
bound as an agent for the registrant.


 * Lines 338-340 (OPoC not actor for Remedy):  This makes no sense to me
and I disagree with it.  If there is some remedy that must be taken, either
the registrant or the OPoC may take such remedy as they see fit, but this
would be at the option of the registrant, not mandated by any standing
policy.  There may be other remedies that the registrar may take if legally
appropriate remedies are not taken by the registrant or OPoC.  It may be
advantageous for the registrant to take or direct a narrow remedy in order
to avoid a more comprehensive remedy by the registrar.


 * Lines 341-345:  I agree with Ross' comments here.  This is a matter
between the registrant and the OPoC, with liability for the domain
conferred on the registrant.  If the OPoC fails in anything of interest to
the registrant, the OPoC should be liable to the registrant, and the
registrant is liable for the domain.


 * Implementation time line, lines 348-349:  I would simply strike this.


 * Section 4, compliance/enforcement:  I disagree with the reveal-related
provisions here, in particular in lines 359 and 361.  Also, I see no
relevance to mentioning Relay in this circumstance.  The only case that
seems to be pertinent and enforceable here is with respect to Remedy.

In cases where a requester has made a request for action on the domain by
the registrar, we have yet to determine how such requests are to be
evaluated by the registrar, and whether such action is mandated, and if so
in what cases.