9 December 2014

The next  Privacy & Proxy Services Accreditation Issues PDP WG teleconference is scheduled for Tuesday 09 December 2014 at 1500 UTC (07:00 PST, 10:00 EST, 15:00 London, 16:00 CET).

For other times: http://tinyurl.com/p84yzsz

Adobe Connect WITH AUDIO enabled:  https://icann.adobeconnect.com/ppsai/

Agenda:

1. Roll Call/Updates to SOI
2. Finalize preliminary conclusions for Category E - Relay
3. Finalize preliminary conclusions for Category G - Termination
4. Next steps

Documents for Review:

Prelim Conclusions for Cat E - 8 Dec 2014

Discussion Notes & Potential Recommendations for Cat G - 8 Dec 2014

MP3 Recording: http://audio.icann.org/gnso/gnso-ppsa-20141209-en.mp3

Meeting Transcript: http://gnso.icann.org/en/meetings/transcript-ppsa-09dec14-en.pdf 

Attendees: 

Steve Metalitz - IPC

Graeme Bunton – RrSG

Frank Michlick – Individual

Chris Pelling – RrSG

Justin Macy - BC

Susan Kawaguchi – BC

Kristina Rosette – IPC

Val Sherman – IPC

Volker Greimann - RrSG

Theo Geurts - RrSG

Stephanie Perrin - NCSG

James Bladel – RrSG

Griffin Barnett – IPC

Alex Deacon – IPC

Kathy Kleiman – NCSG

Paul McGrady – IPC

Osvaldo Novoa – ISPCP

Phil Corwin – BC

Sarah Wyld – RrSG

Vicky Scheckler – IPC

Kiran Malancharuvil – IPC

Holly Raiche – ALAC

Christian Dawson-ISPCP

Carlton Samuels – ALAC

Michele Neylon – RrSG

Don Blumenthal – RySG

Dick Leaning – no soi

Phil Marano - IPC 

Susan Prosser – RrSG

Keith Kupferschmid – IPC

Todd Williams – IPC

Jim Bikoff – IPC

David Cake – NCSG

Luc Seufer – RrSG

David Heasley - IPC

Apologies:

Lindsay Hamilton-Reid- RrSG

 Darcy Southwell – RrSG

ICANN staff:

Marika Konings

Amy Bivins

Danielle Andela

Nathalie Peregrine

 Adobe Connect chat transcript for Tuesday 09 December 2014:

    Marika Konings:Welcome to the PPSAI WG Meeting of 9 December 2014

  Theo Geurts:good

  Theo Geurts:and good afternoon all.

  Michele Neylon:waiting for the operator

  Bladel:*hold music*

  Nathalie  Peregrine:Operator has been informed of the delay

  Osvaldo Novoa:Hello all

  Bladel:There are a bunch of us waiting to join the bridge.

  Michele Neylon:AFK BRB

  Michele Neylon:Steve's volume is very low

  Don Blumenthal:Stioll neeed too set voice up

  Nathalie  Peregrine:@ Michele, I hear him fine.

  Carlton Samuels:Morning all

  vicky sheckler:hi

  Nathalie  Peregrine:Phil Marano, Kristina Rosette have also joined

  Kathy:Hi All

  Frank Michlick:Hi - sorry for being late.

  Nathalie  Peregrine:Susan Kawaguchi has also joined

  Nathalie  Peregrine:We are dialing out to Don right now

  Don Blumenthal:I'm on

  Christian Dawson:sorry for being late team

  Bladel:Ahh...ok.

  Stephanie Perrin:I think James has raised a very important point....if there is a positive obligation to respond, it should be articulated more clearly than burying it in a reveal process.

  Bladel:SOrry for combining those issues.

  Nathalie  Peregrine:Volker Greimann has joined the call

  Bladel:In that case, the escalation would be Invalid WHOIS?

  Holly Raiche:Can there be a positive reuirement on the registrant to respond!

  Bladel:or equivalent for PP providers.

  Nathalie  Peregrine:Kiran Malancharuvil is on the audio bridge

  Graeme Bunton:hand from Marika

  Stephanie Perrin:@Holly I dont think so, but the reason we keep muddling the two strikes me as the fact that we have not positiviely set out the obligations on all sides...

  Holly Raiche:@ stephanie - agreed

  Kathy:Am I mistaken, that a difference between bullet 1 and 2 on page 2 that the requirement of affirmative notification to the p/p providers is not required (?)

  Bladel:With Mary's enhancements/improvements.

  Kathy:Are there two bullet points intended to be be together or as rep

  Kathy:...as replacements for each other?

  Holly Raiche:@ Kathy - I think that is where we are stuck - but could be wrong

  Kathy:@Holly - tx!

  Holly Raiche:Aren't we assuming that thee may be a requirement on the p/p provider to have two ways to communicte with the customer - email - and what?

  Bladel:@Susan: I think so.

  Michele Neylon:web form => email

  Bladel:email, webform, SMS/text.

  steve metalitz:@Susan, yes.

  Nathalie  Peregrine:Please remember to state your names for the transcript

  Michele Neylon:Some $random technology that doesn't currently exist

  Michele Neylon:fax can be either

  Michele Neylon:fax our main number and we get it via email as a PDF

  Susan Kawaguchi:I agree with you Michele that we should allow for technology that doesn't exist but do not want to have to define the process with each new communication type developed

  Kathy:I'm speaking to a diferent point, so please let Holly go first

  Bladel:Yes, that was "postal relay"  But this is the escalation of failed electronic communication.

  Michele Neylon:Susan - there's wording in some existing policies that caters for that ie. use X, Y or Z or any future tech

  Kathy:As part of an escalation process when the conditions of delivery failure have been met (as defined above), the providers [should][must]...

  Graeme Bunton:Steve, would you mind?

  Holly Raiche:That's my question - IS there an alternative means of delivery that must be in place?

  Holly Raiche:@ James - thanks, that answers my question

  Kristina Rosette:+1 Susan.  

  Bladel:+1 Susan.  But that rasies another question... :)

  Holly Raiche:Are we assuming that there are two different email addresses for the customer?

  Susan Kawaguchi:pp records regarding their customer

  Michele Neylon:Can I respond?

  Graeme Bunton:Yes Paul, I was assuming same address

  Kristina Rosette:Understand where Paul is going here.  We may need a PP equivalent to inaccurate Whois reporting.

  Holly Raiche:@Kristina - if here is a failure to respond - however defined - we need to distinguish between a persistent delivery failure and a non-respond

  Alex Deacon:Also we shouldn't assume P/P is affiliated with the registrar.  

  Kristina Rosette:@Holly.  yes, I know.

  Holly Raiche:@ kristina - maybe that needs to be said somewhere other than the chat

  vicky sheckler:sorry I need to run.

  Kathy:@Holly, good point. That's why I like the language in the first bullet -- timely, afirmative notification of a persistent failure of delivery... that seems to  codify a technical problem . Do you read it the same way?

  Michele Neylon:"Escrow of P/P Customer Information. Registrar shall include P/P Customer contact information in its Registration Data Escrow deposits required by Section 3.6 of the Agreement. P/P Customer Information escrowed pursuant to this Section 2.5 of this Specification may only be accessed by ICANN in the event of the termination of the Agreement or in the event Registrar ceases business operations."

  Marika Konings:As a reminder from Cat B, Question 2: The WG recommends  that proxy and privacy customer data be validated and verified in a manner consistent with the requirements outlined in the Whois Accuracy Specification of the 2013 RAA. Moreover, in the cases where validation and verification of the P/P customer data was carried out by the registrar, re-verification by the P/P service of the same, identical, information should not be required.  

  Holly Raiche:@ Kathy - yes, read the sme way

  Marika Konings:That preliminary recommendation also includes the following: Similar to ICANN’s Whois Data Reminder Policy, P/P providers should be required to inform the P/P customer annually of his/her requirement to provide accurate and up to date contact information to the P/P provider. If the P/P service has any information suggesting that the P/P customer information is incorrect (such as P/P service receiving a bounced email notification or non-delivery notification message in connection with compliance with data reminder notices or otherwise) for any P/P customer, the P/P provider must verify or re-verify, as applicable, the email address(es). If, within fifteen (15) calendar days after receiving any such information, P/P service does not receive an affirmative response from the P/P customer providing the required verification, the P/P service shall verify the applicable contact information manually.

  Volker Greimann:there should not be any difference between a registrar affiliated p/p service and an unaffiliated provider.

  Paul McGrady:Thanks Michele!

  Volker Greimann:It will be safe to assume that the RAA regulation will be phased out once the accreditation program is in place

  Kathy:@Steve - the open question is who pays the cost?

  Volker Greimann:the requestor should be charged for an extra fee for outlandish requests, such as postal forwarding

  Kathy:Thereis a concern on the part of the customer that unlimited requests from a third party could lead to unlimited costs...

  Frank Michlick:Requestor should pay cost. It would need to be paid before the communication is passed on.

  Holly Raiche:@ Kathy - fair point

  Graeme Bunton:There are many, as discussed multiple times, many reasons why an email may not work that are not the fault of the custoemr

  Carlton Samuels:We want to achieve in policy a simple way to ensure that a notice requiring delivery is delivered.  If we make the electronic means the default delivery modality we must pronounce on what happens when the mode tells us it has failed to deliver. Two logiclal responses are available: 1> Try again, you lazy bastard. 2) Ok. Use another necessary means. It appears we are insisting on tying oursleves with those knots we learned as Scouts; they don't amount to much if you know which end of the rope to pull!

  Stephanie Perrin:POint of clarification:  I keep conflating non-delivery and non-response.  If all the electronic communications I recieve are going into an account I never read, but they have not bounced, then if the requestor wants to escalate, it seems obvious that requestor must assume costs

  Kathy:When I wanted to send a certified letter, to ensure delivery, I pay for it (requestor)

  Frank Michlick:nominal in comparison to lawyer costs ;-)

  val sherman:Stephanie -- if it goes to your spam, that would fall into the non-response category, not non-delivery.

  Volker Greimann:route mailqueue to /dev/null/

  Kristina Rosette:Why is non-delivery caused by the requestor?  If it's not, what's the rationale for putting the cost on the requestor?  Why doesn't the P/P just do what some registrars do w/r/t UDRP-required transfers and notify their P/P customers that they'll be charged for delivery failures?

  Kathy:Tx Steve!

  Stephanie Perrin:Exactly.  I choose to not respond, I trust that when I am being summoned to Court, my PP service provider will send me a postcard letting me know.

  Paul McGrady:Great call everyone!  Thanks so much!!

  Michele Neylon:ciao

  Kathy:Bye All

  Volker Greimann:Kristina: Requestor wants something done, requestor pays

  Carlton Samuels:Thanks all. Bye

  Frank Michlick:thank you - bye

  Volker Greimann:he who orders the musicians fays for the music