[Gnso-ppsai-pdp-wg] Proposal contactability

Mary Wong mary.wong at icann.org
Mon Aug 18 16:10:25 UTC 2014 

Dear all,

To aid in further discussions on the points several WG members have raised
in response to Volker¹s proposal, the WG Chairs have requested that staff
circulate an updated Category E summary document, containing the fundamental
questions currently being discussed on this list and the WG calls on
Relay/Reveal. Essentially the attached is an update of the summary document
previously circulated on E-1. Attached also are the most recent E-1 and E-2
templates.

In light of the ongoing list discussion, the proposed agenda for the meeting
on Tuesday 19 August is therefore:
1. Roll Call/Updates to SOIs
2. Finalize discussions on Category E
3. Next steps
We will have all the attached documents and Volker¹s proposal on hand in the
Adobe Connect room for the meeting.

Please continue to circulate your suggestions, questions and comments on any
of these to the list prior to the call!

Cheers
Mary



From:  <Williams>, Todd <Todd.Williams at turner.com>
Date:  Monday, August 18, 2014 at 11:19 AM
To:  "James M. Bladel" <jbladel at godaddy.com>, Volker Greimann
<vgreimann at key-systems.net>, "gnso-ppsai-pdp-wg at icann.org"
<gnso-ppsai-pdp-wg at icann.org>
Subject:  Re: [Gnso-ppsai-pdp-wg] Proposal contactability

> Thanks James.  Quick question: if, as you note, most of your P/P customers
> engage the service to avoid being spammed ­ why is that objective/purpose not
> sufficiently protected by a standard that says ³A provider must relay all
> electronic requests received (including emails and via web forms), but may
> implement commercially reasonable safeguards (including CAPTCHA) to filter out
> spam.²?
>  
> By asking the question I don¹t necessarily mean to make a judgment on your
> ³access whitelist² idea.  I¹m just not sure I understand its utility on this
> specific question (relay), where a means to address the problem that it is
> trying to solve (i.e., spam) appears to have already been baked in.
>  
> Thanks.
> 
> TW. 
>  
> 
> From: gnso-ppsai-pdp-wg-bounces at icann.org
> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of James M. Bladel
> Sent: Sunday, August 17, 2014 6:23 PM
> To: Volker Greimann; gnso-ppsai-pdp-wg at icann.org
> Subject: Re: [Gnso-ppsai-pdp-wg] Proposal contactability
>  
> 
> Thanks to Volker for getting this conversation started.  I also share the
> belief that we should define a system that assures reporters their claims will
> be relayed by P/P services.  However, I disagree on some key points raised by
> Volker and others.
> 
>  
> 
> First, I do not believe there should be any attempt to filter submitted
> reports based on content.  That approach does not scale, and simply results in
> an arms race where would-be spammers attempt to circumvent the filters.  Also,
> I do not believe P/P services should relay ‹all‹reports.  This treats the P/P
> email point of contact as an email ³alias² for the beneficial user¹s real
> address, and completely defeats the purpose of the service (most of our P/P
> customers engage the service to avoid being spammed).
> 
>  
> 
> I favor an approach that is modeled after ICANN¹s Invalid WHOIS Reporting
> System, and one that many Registrars have implemented to guard against WHOIS
> harvesting ­ an access whitelist.  Speaking generally, such a system would
> require reporters to identify themselves when submitting a claim for relay.
> Is reporter should also have to designate the email address from which relay
> claims will originate, and the service provider agrees to honor relay request
> from that Address without discriminating on its content.  The P/P service
> provider can then monitor the use of the relay system by each reporter, and
> suspend or terminate access for any reporter that is found to be abusing the
> system.  
> 
>  
> 
> If this sounds familiar, it is blatantly copied from the EWG's proposed RDS
> concept. I think this idea has merit, and regardless of what happens to the
> rest of the EWG's recommendations, we should consider opportunities to
> implement this proposal in existing contexts.
> 
>  
> 
> Look forward to continuing our discussions on this point on Tuesday.
> 
>  
> 
> Thanks‹
> 
>  
> 
> J.
> 
>  
> 
>  
> 
> From: Volker Greimann <vgreimann at key-systems.net>
> Date: Wednesday, August 13, 2014 at 4:27
> To: "gnso-ppsai-pdp-wg at icann.org" <gnso-ppsai-pdp-wg at icann.org>
> Subject: [Gnso-ppsai-pdp-wg] Proposal contactability
> 
>  
> 
> As Susan and Steve have repeatedly asked what my proposal would be to ensure
> contactability of the beneficial owner/registrant.
> 
> As a basis, a spec derivative of the WAP spec to the RAA would have to be
> developed. I took the liberty of modifying the WAP for this purpose as a basis
> for discussion.
> This would bring the obligation of the privacy service provider to validate
> and verify the contact details to the same level of that of the registrar,
> thus ensuring the Service Provider has either accurate details or a duty to
> verify and validate.
> 
> Now, I would agree that some level of a contactibility guarantee is warranted.
> This could be something to this tune, as a basis for discussion:
> 
> "Service Provider are required provide a means for third parties to directly
> or indirectly communicate with the Beneficial Owner. Such means may include
> any of the following:
> a) providing a postal mail forwarding address
> b) providing a collective email point of contact for all domain names under
> the Service (such as abuse at service.provider)
> c) providing an individual email point of contact for each domain name under
> the Service (such as string at domain.name or domain.name at service.provider)
> ...
> ...
> 
> Service Provider must inform potential complainants about the accepted means
> of communication on its website. Service provider may refuse to forward,
> process or even accept communications sent by a non-accepted means of
> communication. In case forwarding of postal communications is offered, Service
> Provider may charge complainant reasonable handling fees and costs for the
> forwarding service and defer the forwarding of communications until payment is
> received. 
> 
> Service Provider may refuse to forward spam, duplicate messages, purchase or
> business inquiries, harrassing communications, anonymous communications and/or
> unwanted communications. Service Provider is authorized to update or modify
> the means of communication from time to time. Service Provider is authorized
> to blacklist complainants with a history of abusing the provided means of
> communication."
> 
> All subject to further discussion, ofc.
> 
> I realize this draft goes into detail more than we should in this WG, but
> having been asked for a proposal, I felt it necessary in order to move the
> discussion ahead.
> Terms:
> Service Provider - Privacy/Proxy Service Provider
> Beneficial Owner - Replaces "Registrant"
> filter - not deliver to Beneficial owner
> Service - the privacy/proxy services
> 
> -- 
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>  
> Mit freundlichen Grüßen,
>  
> Volker A. Greimann
> - Rechtsabteilung -
>  
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
>  
> Web: www.key-systems.net <http://www.key-systems.net>  / www.RRPproxy.net
> <http://www.RRPproxy.net> www.domaindiscount24.com
> <http://www.domaindiscount24.com>  / www.BrandShelter.com
> <http://www.BrandShelter.com>
>  
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>  
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
>  
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
>  
> Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
> Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
> Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
> Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per
> E-Mail oder telefonisch in Verbindung zu setzen.
>  
> --------------------------------------------
>  
> Should you have any further questions, please do not hesitate to contact us.
>  
> Best regards,
>  
> Volker A. Greimann
> - legal department -
>  
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
>  
> Web: www.key-systems.net <http://www.key-systems.net>  / www.RRPproxy.net
> <http://www.RRPproxy.net> www.domaindiscount24.com
> <http://www.domaindiscount24.com>  / www.BrandShelter.com
> <http://www.BrandShelter.com>
>  
> Follow us on Twitter or join our fan community on Facebook and stay updated:
> www.facebook.com/KeySystems <http://www.facebook.com/KeySystems>
> www.twitter.com/key_systems <http://www.twitter.com/key_systems>
>  
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
>  
> Member of the KEYDRIVE GROUP
> www.keydrive.lu <http://www.keydrive.lu>
>  
> This e-mail and its attachments is intended only for the person to whom it is
> addressed. Furthermore it is not permitted to publish any content of this
> email. You must not use, disclose, copy, print or rely on this e-mail. If an
> addressing or transmission error has misdirected this e-mail, kindly notify
> the author by replying to this e-mail or contacting us by telephone.
>  
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140818/ebdcab78/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Summary Status of WG Discussions on Cat E 14 August.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 25379 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140818/ebdcab78/SummaryStatusofWGDiscussionsonCatE14August-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PPSAI ? Category E Question 1 1 August 2014.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 194755 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140818/ebdcab78/PPSAICategoryEQuestion11August2014-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PPSAI - Category E - Question 2 - 14 July 2014.doc
Type: application/msword
Size: 135680 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140818/ebdcab78/PPSAI-CategoryE-Question2-14July2014-0001.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5033 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140818/ebdcab78/smime-0001.p7s>

More information about the Gnso-ppsai-pdp-wg mailing list