Dear All, Please find the MP3 recording for the Privacy and Proxy Services Accreditation Issues PDP Working group call held on Tuesday 29 July 2014 at 14:00 UTC at: <http://audio.icann.org/gnso/gnso-ppsa-20140729-en.mp3> http://audio.icann.org/gnso/gnso-ppsa-20140729-en.mp3 On page: <http://gnso.icann.org/en/group-activities/calendar#jul> http://gnso.icann.org/en/group-activities/calendar#jul The recordings and transcriptions of the calls are posted on the GNSO Master Calendar page: <http://gnso.icann.org/calendar/> http://gnso.icann.org/calendar/ 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 ** Please let me know if your name has been left off the list ** Mailing list archives: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/> http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/ Wiki page: <https://community.icann.org/x/9iCfAg> https://community.icann.org/x/9iCfAg Thank you. Kind regards, 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