comments on ppsai initial report

[Phil Crooker <phil.crooker@xxxxxxxxx>]

*[comments in brackets and bolded]*

Section 1.3.1
Item 20: Regarding de-accreditation of a P/P service provider:

Where feasible, a customer should be able to choose its new P/P service
provider in the
event of de-accreditation of its existing provider *[Separate to the domain
registration itself, there should be a provision that the P/P cannot sell a
customer's info, eg can't sell email addresses to a spammer.]*


Section 1.3.2:

On escalation of relay requests:

“As part of an escalation process, and when the above-mentioned
requirements concerning a
persistent delivery failure of an electronic communication have been met,
the provider [should]
[must] upon request forward a further form of notice to its customer. A
provider should have the
discretion to select the most appropriate means of forwarding such a
request [and to charge a
reasonable fee on a cost-recovery basis]. [Any such reasonable fee is to be
borne by the customer
and not the Requester]. A provider shall have the right to impose
reasonable limits on the
number of such requests made by the same Requester.”

* [I think it is reasonable for the provider to claim reasonable costs to a
recalcitrant domain owner, but the escalation should not be mandatory
without some objective threshold applied as to the validity/significance of
the request (as per Annex E comments below).]*What should be the minimum
mandatory requirements for escalation of relay requests in the
event of a persistent delivery failure of an electronic communication?

*[a court subpoena? require a non-email contact as a backup? what happens
if the failure is not the fault of the domain owner? Escalation must
require the requestor have proof of ownership as per comments on Annex E]*On
Disclosure and Publication in relation to Requests by LEA and other Third
Parties:

Should it be mandatory for accredited P/P service providers to comply with
express requests
from LEA in the provider’s jurisdiction not to notify a customer?

*[unless there is a gag order, no. This is not ICANN's call, it is between
the LEA and the provider.]*Should there be mandatory Publication for
certain types of activity e.g. malware/viruses or
violation of terms of service relating to illegal activity?
*[Not unless there is a consensus amongst those familiar with the art (say
RBL providers) that said domain(s) are conducting such activity]*
What (if any) should the remedies be for unwarranted Publication? *[no
idea. Maybe let the domain owner apply for remedy, demonstrating harm
caused by publication? Can they demonstrate the original request was
vexatious? Was it ICANN's fault it was published? Leave it to the courts?
How would you determine the harm caused by publication?]*

Should a similar framework and/or considerations apply to requests made by
third parties other
than LEA and intellectual property rights-holders? *[Definitely - say for
reporting abuse of terms of service like malware/spam. Again requests
should be vetted by a(n elected) body of experts in the field]*


Section 1.3.3

Should registrants of domain names associated with commercial activities
and which are used
for online financial transactions be prohibited from using, or continuing
to use, P/P
services? If so, why, and if not, why not? *[Should be able to use P/P.
Commercial activity doesn't pre-empt the right of privacy. Criminal
activity or breach of terms of service provide the trigger for the
requests, not mere commercial activity. But for this to work there must be
a robust and fair request mechanism.]*

If you agree with this position, do you think it would be useful to adopt a
definition of
“commercial” or “transactional” to define those domains for which P/P
service registrations
should be disallowed? If so, what should the definition(s) be? *[don't
agree, if you do adopt such a mistaken policy, "commercial" must exclude
small businesses, and must exclude ad revenue or donations from making a
site "commercial".]*

Would it be necessary to make a distinction in the WHOIS data fields to be
displayed as a
result of distinguishing between domain names used for online financial
transactions and
domain names that are not? *[definitely not. useless bureaucracy,
impossible to police, the definition would never cover reality]*

In Section 7, category C question 1:

"However, other WG members disagreed, noting that in the “offline world”
businesses often are required
to register with relevant authorities as well as disclose details about
their identities and locations." *[Exactly, the businesses are already
registered. Use that info, no need for it to be available via whois]*


Section 1.3.4 -General

*[I think this should be expanded to include protection of customer's info
generally, not just for when the customer is Published for breach of
conditions. In addition to the comment in 1.3.1 - 20, there should be a
mechanism for Published whois info to be protected from spidering or other
automated scanning.]*


Annex E

Policy Scope:

Given the balance that this Policy attempts to strikes, evidence of the use
of high volume, automated
electronic processes for sending Requests or responses thereto (without
first being subjected to human
review) to the systems of any of the parties involved (Requesters, Service
Providers, or Customers) by
any of the parties in performing any of the steps in the processes outlined
herein shall create a
rebuttable presumption of non-compliance with this Policy. *[It should not
be the burden or the domain owner to show requests are automated, high
volume, etc. The provider or ICANN ** itself, on request by the domain
owner, needs to determine the validity of each claim (need a way to group
related claims where voluminous claims are warranted), and the
investigation should provide the targeted domain owners a right for
rebuttal prior to execution of the request.]*

Section III:


*[There should be an appeal mechanism to ICANN for the domain holder should
they disagree with the provider, the same as between the provider and the
requestor, prior to the Publication.]*

Annex 1:

*[option 2 otherwise the process is meaningless]*


regards, Phil Crooker.