[gnso-whois-wg] comments on report draft 1.8

[Dan Krimm <dan@xxxxxxxxxxxxxxxx>]

Please see the following comments regarding draft 1.8 of the report.  I
will make reference to Milton's email of 7 August commenting on draft 1.6
as "Milton's email" (note that there was support for this email across
several constituencies and solid support within the NCUC itself).

Sorry for the considerable length of this email, this is mainly for
chairman/staff to incorporate into the final-final report.  However, I
welcome discussion of this on-list if anyone has the time.

Without these modifications (many included in Milton's email and
importantly not addressed in draft 1.8) I cannot support the report without
*substantial* reservations as to its accuracy.

Dan

==========

 * Section 1, Objective:

 - Lines 266-267:  The word "improving" (instead of "retaining") is still
perplexing, because legitimate parties already have the ability to act
against fraud etc.  There is no consideration in the OPOC proposal of
*enhancing* these capabilities beyond the status quo; there is only a
principle not to unduly hamper legitimate actors in legitimate efforts
while preventing abuse of access by illegitimate, bad-acting entities
trying to view private data.

This should be changed in the executive summary, lines 82-90, as well.

 - Lines 269-276:  This paragraph is still not accurate (Milton's email
suggested it be simply removed).  The references to public and private
interests are still contested concepts that carry too much political
controversy to remain in the report, and there is no agreement about this
terminology.  The suggestion that the exceptions to privacy laws "over-ride
any ... interest .. not to disclose personal data" is a vast
oversimplification of these laws, which are designed to balance interests
and to be carefully considered and decided in courts of law to determine
such balance.  It would be useful to say explicitly that exceptions are
defined in the context of defaults to protect privacy that begin with the
higher priority, and that burden of proof lies with the exceptions.  (The
executive summary uses the word "allow" on line 87 -- this is closer to the
truth, as there is no disclosure *mandate* as such.)

Or we could avoid this whole controversy by removing the paragraph (and its
paraphrase in the executive summary) as suggested in Milton's email, which
was supported by members of several different constituencies.  Leaving it
in would require us to work through these issues, but as this is merely a
framing point (which is precisely why it is so controversial) it seems
unnecessary to retain it.  Plus, we have insufficient time to do this by
Monday.

 - Lines 291-296:  Once again, Milton's email suggested this be removed.
Instead one word was changed from "many" to "certain".  This is an
inherently confusing passage and again need not be present in the report.

For example, my own position is that protecting privacy does help keep
personal data out of the hands of all sorts of bad actors who could abuse
access to the data (such as entities making false and/or unsubstantiated
claims of IP infringement, or spammers trying to deliver malware or
phishing messages, or mass marketers trying to sell dubious products, or
political agents trying to prevent natural persons from voicing opposition
to their narrow political goals, or others simply aiming to harass
particular natural persons who happen to own domain names).

But this passage alternatively could leave an impression that protection
from crime excuses any exceptions to privacy protection.  If the intent was
to accommodate those with positions similar to mine above, then it is not
clearly worded to accomplish that goal.  There are indeed potential
tradeoffs involved if the OPOC system is not carefully designed to protect
privacy at the same time that it continues to enable effective measures
against bad actors of all types.  But the devil is in the details, and
general statements about what are or are not tradeoffs are impossible to
evaluate without knowing the implementation details.

Bottom line:  The various conflicts and congruities are complicated and any
simple statement of the general context fails to capture a full and nuanced
understanding of the issues as a matter of policy.


 * Section 2, What is an OPOC:

 - Lines 340-385, Verification:  I believe the levels of agreement in this
section were confused by the conflation of mere email-verification and
verification of contractual consent in various discussions along the way.

For example, my own position is reflected in line 371, but *only* for mere
active-email auto-verification, *not* for verification of OPOC contractual
consent with the Registrant, and not even for verification of other OPOC
contact information.

The delineation of *what exactly* is being verified here is still
unacceptably vague and needs clarification.  If "full" OPOC verification is
implied, then certainly the alternative view in lines 364-365 should be
upgraded to "support" as suggested in Milton's email.  As a result, this is
also unclear in the executive summary (lines 122: "verification to ensure
functionality of the OPOC" -- the word "functionality" is too vague here),
and should be corrected.

 - Lines 417-440, Who should obtain consent:  There is a contradiction
between the statement of support in lines 419-420 and the implementation
option in lines 438-439, because when the "process of consent" lies with
the Registrant, then the Registrar does not "obtain" consent from the OPOC.

This appears to be an attempt to reconcile the suggestion in Milton's email
without actually following it:  Add to "Support" [after line 420 in v1.8]:
"The Registrant alone must get consent."

Unfortunately this attempted reconciliation just doesn't work; the last
implementation option does not by itself replace the explicit recording of
support for a policy that only the Registrant should obtain consent from
the OPOC.

In order to avoid this inherent conflict, in line 419 we might replace the
word "obtain" with "require affirmation of".  Nevertheless, the additional
statement of support still needs to be included (if you like, replace "get"
with "obtain").


 * Section 3, roles/responsibilities of OPOC:

 - Lines 602-607, Reveal - Alternate views:

Add:  "There was one user view that it may be possible to determine
features of the mandated Registrant-OPOC contract such that it is not
necessary to know the Registrant contact information in order to serve
legal notices on the Registrant."

(Citations:  Dan Krimm, comments on-list -- 5 July, 6 July, 24 July)

 - Line 605:  This reflects a point I've made several times, and I intended
it to apply to *legal standing* of the Requester *in context of the
requested use*.  Sorry if that was not clear, but it is important that this
detail be retained in order to be accurate.  I would re-word it as follows:

"There was one view in favor of authentication of legal standing of the
Requester to obtain private personal data in context of the purpose of
Reveal request being made."

 - Line 621:  How many views does it take to upgrade an alternative view to
support?  It could be argued that "some" should be enough, and that this
should be done as suggested in Milton's email.  If so, the "agreed" in
lines 611-614 should be downgraded to support as well.  Without these
changes, the full extent of diversity will not be portrayed correctly.


 * Section 5, registrant/display implications:

 - The reference to "sole trader" was removed from the implementation
options, however that now leaves an ambiguity about how to treat natural
persons who are also legal persons.  To resolve this ambiguity a third
bullet point should be added to the working definition after line 724:

"A natural person who also qualifies as a legal person shall be treated as
a natural person for the purposes of display and privacy protection."


 * Section 6, Access:

 - Line 771, type 6.3 access:  The modification of this description still
is not entirely descriptive of the qualification of use and user suggested
in Milton's email.  Perhaps this can be fixed by prepending the word
"Qualified" to yield:

"Qualified regular query-based access to un-displayed data records"

The details of qualification are discussed later in the report.

 - Lines 810-812:  First, insert a comma after the word "domain" at end of
line 810.  Also, this is still missing the qualification of legal standing
of the Accessor, which has been implied all along (even under a weak
self-declaration standard).  I would suggest appending the following clause
to the end of the sentence:

"..., and subject to legal standing of the Accessor to make use of the data
as proposed."

 - Lines 814-815:  Milton's email suggested removing this sentence.  If
this is retained, it has an inherent ambiguity that should be clarified by
replacing the word "when" with "only if".  As I understand it, this
statement is intended as a qualification (i.e., a filter), not a mandate.

If we do not have agreement here, then remaining vagueness will not help
the process, and we should clarify the disagreement.

 - Lines 846-852:  We are still not in agreement, as noted in Milton's
email.  This needs to be changed to reflect the actual levels of agreement
and support.  The version retained here from the last draft may have
support but it does not have agreement.  The version suggested in Milton's
email (6.2, 6.3 for LEAs, 6.2 for private actors, as qualified by use and
user) does have agreement and does not preclude the additional support for
this version.

 - Lines 859-860:  This alternative view still deserves to be upgraded to
support level.  There are enough "some" views across several constituencies
to merit this, otherwise the full extent of diversity will not be portrayed
correctly.

 - Lines 876-877:  This still omits the mention of "signed affidavit" (as
in Milton's email) which was discussed by several people in SGB.  It should
at least be an option.  I suggest appending:

"..., and possibly requiring a signed affidavit)."

This also needs clarification in the executive summary, lines 175-177.

 - Lines 885-887:  This sentence is still unacceptably misleading, in
particular the combination of the words "method" and "scaleable" -- the
*methods* of the existing certification institutions noted in the
consultant's report are quite possibly *scaleable globally* in general
terms, notwithstanding the consultant's summary statement about
currently-existing organizations.

Suggested clarification:  "There was no known instance of a currently
operating third party system able to authenticate Accessors that is
currently globally scaled.  Cost for a globally scaled Accessor
authentication system is unknown at this time and requires further study."

This should also be clarified in the executive summary, lines 177-180.

 - Lines 911-913:  Once again as noted in Milton's email, this deserves to
be upgraded to support.

The executive summary similarly needs to be clarified on this point, lines
164-167.