29 July 2014

The next  Privacy & Proxy Services Accreditation Issues PDP WG teleconference is scheduled for Tuesday 29 July 2014 at 1400 UTC (07:00 PDT, 10:00 EDT, 15:00 London, 16:00 CET).

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

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

Agenda:

1. Roll Call/Updates to SOI
2. Continue discussions on E-1 (incorporating latest mailing list discussion initiated by Alex)
3. Commence discussions on E-2 (if time permits)
4. Next steps/next meeting

Documents for Review:

PPSAI – Category E Question 1 (updated 23 July)

PPSAI - Category E - Question 2 - 14 July 2014

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

Meeting Transcript: http://gnso.icann.org/en/meetings/transcript-ppsa-29jul14-en.pdf

Attendees: 

Steve Metalitz - IPC

Justin Macy – BC

Sarah Wyld - RrSG

Chris Pelling – RrSG

Darcy Southwell - RrSG

Graeme Bunton – RrSG

Val Sherman – IPC

Griffin Barnett – IPC

Susan Kawaguchi – BC

Kathy Kleiman – NCUC

Alex Deacon - IPC

Kristina Rosette – IPC

Paul McGrady – IPC

Carlton Samuels – ALAC

Todd Williams – IPC

Michele Neylon – RrSG

Tatiana Khramtsova – RrSG

Roy Balleste – NCUC

Frank Michlick – Individual

Phil Marano-IPC

Luc Seufer- RrSG

Volker Greimann-RrSG

Don Blumenthal – RySG

James Bladel – RrSG

Osvaldo Novoa – ISPCP

Libby Baney-BC

Susan Prosser-RrSG

David Cake-NCSG

David Hughes-IPC

Apologies:

Holly Raiche – ALAC

Stephanie Perrin – NCSG

Tobias Sattler-RrSG

Lindsay Hamilton-Reid-RrSG

Tim Ruiz  - RrSG

ICANN staff:

Mary Wong

Amy Bivins

Terri Agnew

Adobe Connect chat transcript for Tuesday 29 July 2014:

Terri Agnew:Welcome to the PPSAI WG Meeting of 29 July 2014

  Chris Pelling:afternoon all :)

  Osvaldo Novoa:Hello all, morning for me :)

  Kathy:Hi All!

  Paul McGrady:Good morning!

  Volker Greimann:top of the afternoon to you all

  Volker Greimann:Don, you are coming through clearly and without noise

  steve metalitz:@Don, correct, failed message to p/p customer. 

  Terri Agnew:David Cake has joined

  Terri Agnew:Carlton Samuels has joined

  Carlton Samuels:Howdy do everybody

  steve metalitz:@James, in the non-roxy situation, the third party already knows about the bounce back.  Not comparable situation.

  Chris Pelling:they have a box trapper service etc

  Kathy:Hi Carlton!

  Carlton Samuels:Hi Kathy

  steve metalitz:I meant non-proxy of course. 

  Terri Agnew:Luc Seufer has joined

  Kathy:How technically difficult is it to get the bounce back to the original requestor?

  Alex Deacon:@kathy - its not difficult at all.

  Chris Pelling:@Kathy, it would mean stripping of technical data etc

  Kathy:I think we heard last week that sorting through the bouncebacks might be difficult, even impossible, to find, sort and distribute

  Chris Pelling:so could be potentially hard to do

  David Cake:Michele is right. Bounce messages can include IP of mail servers.

  Terri Agnew:Kristina Rosette has joined

  kristina rosette:Hi. apologies for being late. another call ran long.

  Volker Greimann:Kathy: Some can be identified, some cannot.

  Luc Seufer:SM Tee Pee is that some kind of Irish linguo?

  Volker Greimann:I would not want a general "you must do X if bounce!"

  Michele Neylon:Luc - behave

  Michele Neylon:Luc - I'll remove your geek points

  Michele Neylon:a soft bounce is not a hard bounce

  Michele Neylon:and I'd view a soft bounce as a temporary issue

  Volker Greimann:Can I jump in?

  Michele Neylon:and I'd ignore it

  Kathy:I'm happy to wait.... good discussion

  Terri Agnew:David Hughes has joined audio

  Alex Deacon:@kathy - its that email/SMPT was designed to do .  Its not difficult.

  Alex Deacon:s/SMPT/SMTP

  Michele Neylon:SMTP is far from perfect

  Michele Neylon:people assume it is

  Alex Deacon:nothing is perfect

  Chris Pelling:many of the MTA's have different responses for bounce messages so it is not the simplest thing to strip personal info from a bounce and relay it.  I agree with what James mentioned though

  David Cake:SMTP is so very far from perfect. No one who has ever run a mail server would describe SMTP as perfect.

  Kathy:Tx for the input, James, more to think aobut!

  Kathy:about!

  David Cake:As an aside - a bunch of my friends own rcpt.to as their email domain. One of them has RFC 822 as his cars numberplate.

  Don Blumenthal:David, I'm not sure if that's sad or not. :)

  steve metalitz:For reference here is the obligation in 2013 RAA Whois Accuracy Spocification:

  steve metalitz:4.If Registrar has any information suggesting that the contact information specified in Section 1(a) through 1(f) above is incorrect (such as Registrar receiving a bounced email notification or non-delivery notification message in connection with compliance with ICANN's Whois Data Reminder Policy or otherwise) for any Registered Name sponsored by Registrar (whether or not Registrar was previously required to perform the validation and verification requirements set forth in this Specification in respect of such Registered Name), Registrar must verify or re-verify, as applicable, the email address(es) as described in Section 1.f

  Chris Pelling:@Alex with forwarding MTA we are not gauranteed to to get a response

  Volker Greimann:Steve, isn't that what I said? If the information is not identifiable, it is not sufficient

  Alex Deacon:@Chris  -  sure there is always a chance that may happen.

  Volker Greimann:If the information cannot be tied to a specific registration, that information is not sugggesting anything

  Chris Pelling:@Don, that was down to the privacy service

  Chris Pelling:some do offer it some dont

  steve metalitz:So should the requirement be that the requester be notified when provider receives "a bounced email notification or non-delivery notification message" on the relay. 

  Luc Seufer:the registrar I would say, not the requester

  Alex Deacon:@volker - life is hard being a p/p provider :)

  Volker Greimann:can I respond?

  Michele Neylon:huh?

  Michele Neylon:Now I'm confused

  Michele Neylon:so registrant / user pays for privacy / proxy

  Luc Seufer:same logic applies to phone books

  Michele Neylon:so that their real details aren't revealed

  Michele Neylon:why on earth would the real details be revealed ?

  Michele Neylon:am I missing something?

  Luc Seufer:it's not because they are rlisted that you can "get to them"

  Don Blumenthal:Let's not get into the Whois purpose mess. :)

  Kathy:Steve: how would a p/p provider know that an email has bounced, and the snail mail is follow-up?

  Michele Neylon:But you have the provider's contact details

  Carlton Samuels:Can we agree the P/P provider is bound to relay all messaging pertinent for compliance with the RAA. I would not wish to define the messaging channel. That is left to the P/P provider and client to determine in contract. What that cost should be covered in term of contract. Why is the channel  of such moment to us? Set the rule and refrain from telling the provider what messaging channel is best for his business relationship. to be maintained without sanction.

  steve metalitz:@Kathy, The provider has sent the e-mail so it knows when it has bounced back.  If the requester also knows (see previous discussion), then it can ask for hard copy to be forwarded.  

  Michele Neylon:can't hear him

  Chris Pelling:@david this is why we would make a charge for it

  Carlton Samuels:What we should insist on is a prescribed set of messages are relayed and there is evidence of that

  Chris Pelling:it doesnt happen often enough to worry

  Kathy:@Steve, I remain concerned about the scaling of email bouncebacks. If potentially thousands of messages go out, then the tracing of the bouncebacks of even a fraction of them might be quite difficult.

  Darcy Southwell:David’s comments about a registrant’s failure to respond to a communication do not represent a communication failure and should not necessitate delivery of mail to a mailing address.  I think it’s a more appropriate accreditation standard to require a PP provider to investigate a communication failure with any of its communication methods with its registrants. 

  Kathy:So is this a possibility: that P/P are encouraged to provide bounceback information, but not mandated?

  Alex Deacon:@kathy - if its automoated (as most are) then its not difficult.   

  steve metalitz:@volker, is it more efficient to handle manually as abuse cases or automated notification of bouncebacks?  

  Kathy:@Alex, I send out email to lists all the time, and sorting through bouncebacks for changed emails, full mailboxes, network problems, etc, takes a lot of my time -- and my lists are only dozens (not hundreds or thousands)

  Alex Deacon:@kathy - but there are tools, methods to sort/filter/file/etc.   Same goes in an automated email forward/proxy system. 

  Luc Seufer:aside from allowing to file a complaint with ICANN compliance, I am not sure what the value of a bounce message is

  Volker Greimann:@steve not sure what you mean. My suggestion is that if you do not get a response or get a bounceback (if that is how the service is set up) you can always escalate to abuse@pp -rovider.com or similar.

  steve metalitz:I@Volker, I believe we are talking about situation where the PROVIDER gets the bounce back, not the requester. 

  David Cake:I agree with James here. Location data needs to be protected.

  Terri Agnew:Tim Ruiz sends his apologies for not making this call

  Todd Williams:+1 Steve.  That was the point of the first part of the conversation today: the requestor doesn't have notice of the bounce back (but should).

  Luc Seufer:why should?

  Todd Williams:@Luc: parity point we discussed last week.

  Luc Seufer:so not should, but "may" depending on how the email infrastructure is setup

  David Cake:Not sure if requester needs to have notice of bounce data, but appears that Registrar needs to have it to fulfil RAA obligations?

  Susan kawaguchi:If we cannot contact the end user/licensee via email (the proxy service allows the choice of no relay of email) and we cannot contact via hard copy then the doesn't that leave all liability for the domain name to the proxy service?  If it walks like a duck and quack likes a duck in my mind it is a duck

  Luc Seufer:AFAIC I am fine with relaying registred mail

  Luc Seufer:registered

  Bladel:I am in agreement with Steve.  Which is why the bar for "reveal" should be even higher than"relay".

  Kathy:@Steve - I thought the issue was no so much what gets relayed, but what response the Requestor of the Relay should receive

  Luc Seufer:relay: registered mail / reveal competent LEAs should be the rule IMHO

  Carlton Samuels:I believe an accredited P/P provider is obliged to relay messages pursuant to compliance with all aspects of the RAA. For messages not pertinent to RAA compliance I'm open to hearing an argument for obligation.

  Luc Seufer:@Carlton because you need to receive this email chain, or this great promo on viagra!

  Chris Pelling:@Susan if the registrant does not want to reply to you, they are not required too

  kristina rosette:@Carlton:  Some would say that the P/P provider has to choose - it either relays or it accepts liability as the registrant. 

  Carlton Samuels:If the P/P does not wish to relay messages pertinent to RAA compliance then they cannot be accredited.

  Carlton Samuels:@Luc. I'm open does not mean I will yield.

  Susan kawaguchi:I absolutely agree with that but if I cannot contact the registrant that makes the proxy responsible

  Carlton Samuels::-)

  Mary Wong:Thanks everyone.

  Carlton Samuels:Thanks all

  Darcy Southwell:Thanks.

  David Cake:thank you

  Kathy:Bye all!

  Luc Seufer:bye