[Gnso-ppsai-pdp-wg] MP3 PPSAI WG - Tuesday 29 July 2014 at 1400 UTC
Terri Agnew
terri.agnew at icann.org
Tue Jul 29 20:16:20 UTC 2014
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 at pp -rovider.com or similar.
steve metalitz:I at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140729/381521ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5417 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140729/381521ee/smime-0001.p7s>
More information about the Gnso-ppsai-pdp-wg
mailing list