July 2014 - Gnso-ppsai-pdp-wg

Question
by Kathy Kleiman Aug. 5, 2014

Aug. 5, 2014

Hi Steve and Alex, Good discussion today - much appreciated. Quick note: I can certainly understand the desire to know if an email went through. Quick question: do you have any idea how many "bouncebacks" we are talking about? In today's environment, with the current forwarding work by proxy/privacy providers, do you have any idea how many messages are undeliverable vs. how many may be received but not responded to? I know each messages is important, but are we talking about a high percentage or a very low percentage? Tx, Kathy

10 12

Leaving the WG
by Tim Ruiz Aug. 1, 2014

Aug. 1, 2014

Hello all, I will no longer be with Go Daddy as of the end of this week. While I could remain in the WG as an individual, I think it would be best not to do that for now. It is disappointing as I have enjoyed the way this WG has worked together and there will clearly be a successful and positive outcome from this group. I'll be taking a break for a while, but likely hanging around ICANN circles here and there (old habits are hard to break). Terri/Mary, would you please remove me from the WG list? Also, I will update my SOI later in case I jump into the mix again somewhere down the line. Best and warmest wishes to you all, Tim

4 3

MP3 PPSAI WG - Tuesday 29 July 2014 at 1400 UTC
by Terri Agnew July 29, 2014

July 29, 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@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

1 0

Apologies...
by Tim Ruiz July 29, 2014

July 29, 2014

Thought I was going to be able to join not too late, but just now freed up. Will catch up with the recording and list disc. Tim

1 0

Agenda for WG call on 29 July
by Mary Wong July 29, 2014

July 29, 2014

Dear WG members, The proposed agenda for the next WG meeting on 29 July is as follows: 1. Roll Call/Updates to SOI 2. Continue discussions on E-1 (updated template sent pm 23 July; attached here again with a minor typo corrected - for your review) 3. Commence discussions on E-2 (if time permits) 4. Next steps/next meeting We will add the updated template for E-1 to the WG wiki, in accordance with the usual practice, as well. Thanks and cheers Mary Mary Wong Senior Policy Director Internet Corporation for Assigned Names & Numbers (ICANN) Telephone: +1 603 574 4892 Email: mary.wong(a)icann.org

8 14

PLEASE RSVP Monthly GNSO WG Newcomer Open House Session
by Terri Agnew July 29, 2014

July 29, 2014

Monthly GNSO WG Newcomer Open House Session These ongoing monthly sessions are for new GNSO WG participants to come together and discuss any questions they may have about GNSO Working Groups, procedures and/or processes. We know there is a lot of information to digest when you join a GNSO Working Group and these monthly meetings are an opportunity for newcomers and more experienced participants to meet in an informal setting without the pressure of "real work" that needs be done. The agenda is flexible. The presenters will be ready with a standard set of materials if people would like to discuss them. Feel free to submit questions, either in advance or at the beginning of the meeting, if there is a topic that you would like to explore in more depth . Providing useful answers to a wide range of questions is part of the reason why these meetings are Thursday 3 July at 20.00 UTC Thursday 7 August at 12.00 UTC Thursday 4 September at 20.00 UTC Thursday 2 October at 12.00 UTC Thursday 6 November at 20.00 UTC Thursday 4 December at 12.00 UTC To convert to your local time zone, please see <http://www.timeanddate.com/worldclock/converter.html> http://www.timeanddate.com/worldclock/converter.html. If you are interested to join the next meeting on 3 July or any of the future meetings, please let the GNSO Secretariat know ( <mailto:gnso-secs@icann.org> gnso-secs(a)icann.org) and we will send you the call details. If there are any specific questions you already have, or any overviews or introductions you think would be helpful (e.g. GNSO Policy Development Process or GNSO Working Group guidelines), please let us know in advance and we will prepare materials accordingly. Feel free to share this invitation with others that you think may be interested. We look forward to welcoming you at the next meeting! Nathalie Peregrine & Terri Agnew GNSO Secretariat

2 1

Updated E-1 template
by Mary Wong July 23, 2014

July 23, 2014

Dear WG members, Attached please find an updated version of the E-1 template. As before, we have attempted to capture the gist of the WG¹s most recent discussions. We look forward to your comments and feedback as you continue your deliberations on this charter question. Cheers Mary Mary Wong Senior Policy Director Internet Corporation for Assigned Names & Numbers (ICANN) Telephone: +1 603 574 4892 Email: mary.wong(a)icann.org

1 0

MP3 PPSAI WG - Tuesday 22 July 2014 at 1400 UTC
by Terri Agnew July 22, 2014

July 22, 2014

Dear All, Please find the MP3 recording for the Privacy and Proxy Services Accreditation Issues PDP Working group call held on Tuesday 22 July 2014 at 14:00 UTC at: <http://audio.icann.org/gnso/gnso-ppsa-20140722-en.mp3> http://audio.icann.org/gnso/gnso-ppsa-20140722-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 Stephanie Perrin – NCSG David Heasley – IPC Alex Deacon - IPC Jim Bikoff – IPC Kristina Rosette – IPC Paul McGrady – IPC Carlton Samuels – ALAC Todd Williams – IPC Tim Ruiz - RrSG Michele Neylon – RrSG Tatiana Khramtsova – RrSG Roy Balleste – NCUC Frank Michlick – Individual Phil Marano-IPC Luc Seufer- RrSG Volker Greimann-RrSG Maria Farrell-NCUC Tobias Sattler-RrSG Sean McInerney - SOI Apologies: Holly Raiche – ALAC Don Blumenthal – RySG James Bladel – RrSG Osvaldo Novoa – ISPCP Christian Dawson – ISPCP Don Moody - IPC ICANN staff: Marika Konings Mary Wong 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 22 July 2014: Terri Agnew:Welcome to the PPSAI WG Meeting of 22 July 2014 Carlton Samuels:Howdy do everybody Terri Agnew:Welcome Carlton Chris Pelling:afternoon all Sarah Wyld - Aplus.net:Hello! Tim Ruiz:Hello all! Graeme Bunton:Good morning all, if you missed it, Don is travelling today and I'll be subbing in as chair today Paul McGrady:Good morning all. I'm having some trouble with hearing the audio, so I may need to switch to dial in rather than Adobe. Terri Agnew:David Heasley and Jim Bikoff have joined Kathy:Hi All! Terri Agnew:Michele Neylon and Kristina Rosette have joined Terri Agnew:Stephanie Perrin has joined Mary Wong:Steve's point has now been added to the E-1 template (see screen), but we have not had the chance to add Kathy's suggestion. Terri Agnew:Luc Seufer has joined Carlton Samuels:FWIW, re Kathy's suggestion: +1. The ALAC's position is that all terms of the RAA remain in force Tim Ruiz:What is bonified? Luc Seufer:4 to 5 years for a Bordeaux Stephanie Perrin:that was my question as well, we never really solved the problem of alleged bad behaviour Terri Agnew:Volker Greimann has joined Chris Pelling:my understanding was no one actually said they would not ? Chris Pelling:that and they cant read michele Terri Agnew:Maria Farrell has joined Luc Seufer:FWIW the French Registry, who is providing a de facto privacy service to every individuals registering a .fr domain name is using the form+captcha available here for their relay http://www.afnic.fr/en/dispute-resolution/tools-and-procedures/reach-a-doma… Maria Farrell:I have seen a Carlow policeman. Agree with Michele - you don't want one turning up on your doorstep!! Carlton Samuels:+1 to Kathy Chris Pelling:thanks Luc Carlton Samuels:@Steve: Yes, so leave the decision to the P/P provider and make that a compliance matter Carlton Samuels:@Graeme: James's explanation is compelling to me Tim Ruiz:As long as we also recognize that the P/P provider is not the begin and end all of the email chain. Email providers themselves may filter beyond the P/P provider's control, as well as in the chain after, as wwith Tim Ruiz:...as with the users software. Alex Deacon:can you hear me? Alex Deacon:ok I need to dial in - just a sec. apologies Michele Neylon:the sound of silence .. Terri Agnew:Alex, your mic isn't active kristina rosette:Graeme, can you walk through how you'd know in 15 days if it failed. I'm not clear on that. (I know the RAA provision, but not sure how it would apply here.) kristina rosette:sorry. need to be on mute b/c of office construction kristina rosette:So, the idea is that the proxy provider would report to the registrar, who would then suspend? Terri Agnew:Alex has activated his mic Tim Ruiz:Are we talking about only the emails that are relayed? Michele Neylon:AFK Chris Pelling:Steve, should the email address work, and your email is passed on but you get no response, then what ? are you going to continue emailing or ? Not trying to create a storm, trying to understand Chris Pelling:@Steve, but the PP wont reply to you or is that what you are trying to request ? Val Sherman:+1 Steve Kathy:What about sales request? If someone is trying to buy a domain name, is that the type of email I (as a customer) should be able to "opt-out" of? Graeme Bunton:You're right Kristina that I was mostly thinking about that in the context of a registrar afiliated service Tim Ruiz:Not all email systems send notice on bounces or non-deliverables, as far as I know. So there is really no way to enforece or check this anyway, as far as I know. Kathy:I hate to say it, but it sounds like a lot of work to check bounces... kristina rosette:@Graeme: That's the gap I'm thinking about - when there proxy/privacy provider is not affiliated with the registrar. Justin Macy:Correect me if I'm wrong, I don't think Steve is talking about spam. An email that lands in a spam folder is still technically delivered. Even though it may be ignored. Tim Ruiz:Again, how would this be verified or enforced? Volker Greimann:parody? steve metalitz:@Volker --parity Marika Konings:Could P/P terms of service require/recommend that P/P provider email address is whitelisted to ensure that communications are received (and it is the responsibility of the registrant to do so)? Chris Pelling:did my hand raise ? Tobias Sattler:Sorry for being late. Graeme Bunton:it did, chris Frank Michlick:Sorry, I have to drop off the meeting. Michele Neylon:Marika - how can we check that? Carlton Samuels:@Steve: The question is what happens beyond the P/P provider's gate. There are several reasons for 'communications failure'. If we make the rule that a provider would have a duty to relay, then response is still required of the P/P as middleman. the responsibility to complete the communications chain Terri Agnew:Tobias Sattler has joined Tim Ruiz:Perhaps it is a best practice instead? Michele Neylon:+1 with Volker's comment Michele Neylon:some MTAs give back really useless errors Marika Konings:@Michele - you cannot check, but you make clear that it is the responsibility of the registrant to ensure that communications from P/P can be delivered. Michele Neylon:Marika - ok, but how does that help anyone? :) Marika Konings:hopefully it helps messages actually being delivered instead of getting stuck in the spam filter ;-) Chris Pelling:ok, well ours last 24 hours Mary Wong:Although not a 100% fail-safe guarantee, is this one place where the "knowingly" phrase from the RAA might come in useful? ie if the P/P providre knows a delivery failed, there's then an obligation to notify teh requestor? kristina rosette:US Postal Service provides delivery confirmation. Justin Macy:US Postal service will also return to sender if undeliverable Michele Neylon:Kristina - assuming they ever deliver :) Carlton Samuels:Why would one ever assume 'communications failure'? I suspect elapsed time from original message? If you get no response then you check? The P/P provider is duty-bound to relay the message . The message may have to be delivered by alternate means. Tim Ruiz:@Kristina, but at a cost to the sender, right? Chris Pelling:@Steve, but what if they simply dont respond Tim Ruiz:Is ther then any reason why P/P provider could not charge a reasonable fee for the bounce back or non-deliverable service? Mary Wong:@Michele, that was my suggestion for the group to consider - "knowingly" Kathy:@Mary: I think we are imposing a huge new obligation on p/p providers Tim Ruiz:Charging would cover P/P costs and discourage abuse of the complaint system. Again, only charging for getting a return confirmation of sorts. Chris Pelling:@alex not for international I would wager Chris Pelling:ie Royal Mail in the uk will not send a letter back to the usa at their cost Kathy:@Steve's idea: that the p/p provider user commercially reasonable means to delivery the email -- that makes sense to me. Michele Neylon:I like "commercially reasonable" and that kind of language Sarah Wyld - Aplus.net:Are we going to require that postal mail be relayed? Right now many P/P providers relay email but not letter mail... Darcy Southwell:I agree with Kathy and Michele about "commercially reasonable" obligations to deliver to the registrant what is submitted to to the p/p provider. Chris Pelling:ok - Ill put out there now, we charge the sender for relaying postal mail as it introduces a "man cost" Carlton Samuels:@Michele: Here we are, getting into the weeds of the protocols, and the meaning the rules of communications. The rule is that messages must be relayed. Failure in this state means 'we didn't hear from somebody in a specified time'. Then, since you have the duty to communicate. The message may take several channels. Given the responsibility to deliver a message, you go for alternate communication channel. Now, what might be reasonable as a channel is a sliding scale, depending on effort and cost. But there will be a consequence for non-communication. Tim Ruiz:Commercially Reasonable would be applied to the parties of the agreement. So, yes, it may be different for different parties. steve metalitz:+1 Mary, these are two separate points -- delivery and known failure Mary Wong:OK thanks! Marika Konings:Please note that some of the P/P providers sampled do seem to relay postal mail (in certain cases they would scan it and send it via email) Chris Pelling:@Marika, yes we do for a charge though Carlton Samuels:The first indication of a likely delivery failure is "no response in the x days set' Tim Ruiz:If it has value to the requestor, the a cost recovery fee seems reasonable. Alex Deacon:@Carlton - failure in this case means that the P/P received a failure message when attempting to communicate with their customer. No resposne may not be a failure. Chris Pelling:@steve, email is free, written comms isnt Chris Pelling:Foe example, the charge we make is for time taken in scanning the document, and then confirming delivery back to the sender Chris Pelling:so that have a signed letter from us of delivery Luc Seufer:the secret business partnership did not lasted too long Carlton Samuels:@Alex. Understood. But I think we're focusing on details. Our interest is a response to a message. The details of delivery mode is less important IMHO. Let the P/P and their customer decide Terri Agnew:Sean McInerney has joined audio Graeme Bunton:You're a bit loud Volker Kathy:+1 Carlton Michele Neylon:at least we can hear him Chris Pelling:Graeme I notice you never said that to Michele :p Chris Pelling:hehe Justin Macy:I tend to think we are talking about two seperate services, a bounce back being forwarded and a certified letter of delivery. I tend to think the bounce back cost should be paid by the customer. I'm not so sure on the certified delivery., I would need to think about it more. steve metalitz:David's suggestion was forwardingmail when electronic communications had failed Volker Greimann:It does actually! Kathy:@Steve, tx for the clarification -- useful to know Chris Pelling:or they simply dont wish to respond for example Chris Pelling:so you want to hear from me again ? Chris Pelling:I dont mind answering that Michele Neylon:lack of response doesn't equate with lack of functionality Mary Wong:Go ahead, Chris Michele Neylon:I get a LOT of snail mail that I bin Luc Seufer:I think you meant "recycle" Michele Kathy:Tx you, Chris! Chris Pelling:sorry vlubt and to the point Chris Pelling:blunt * Tim Ruiz:I think a best practice is the way to go with this. Making it a requirement would only create yet another unverifiable, unenforceable policy Michele Neylon:I have a very large recycling bin by my desk Chris Pelling:but they dont confirm back to you Chris Pelling:that was @Steve Luc Seufer:here you go! blacknight.com even our complaint management system is green Chris Pelling:hehe Luc Chris Pelling:absolutely correct Michele Kathy:+1 to Michele: it's true in the real world,and it's true in the electronic world: there is no obligation to respond to a request to purchase, to a mere allegation of concern, etc Carlton Samuels:I do not believe we should be prescriptive about how a message is sent. The rule must outline a duty to respond and in a certain time. After that time has elapsed make the reaction to non-response sure and effective Carlton Samuels:@Michele: I agree, no duty to respond but there must be a clear outcome from non-response. Mary Wong:We'll send around an updated E-1 template in the next day or so. Chris Pelling:Thanks you all :) Kathy:Great moderating, Graeme, much appreciated! Paul McGrady:Thanks! Darcy Southwell:Thank you! Val Sherman:thanks! Maria Farrell:Thanks graeme Luc Seufer:thx Tim Ruiz:Bye Carlton Samuels:Thanks all. An interesting discussion Maria Farrell:+1 kathy

1 0

Re: [Gnso-ppsai-pdp-wg] Relay failure notification
by James M. Bladel July 22, 2014

July 22, 2014

Alex and team: Thinking about the points Alex has made below, here are my observations: * I agree that the P/P service should be reliably contactable. To this end, I believe any comms failure (email or telephone) should be treated equivalently to a failure of a registrar¹s required contact information under the 2013 RAA. Meaning Compliance would open a ticket and the P/P service would be obligated to correct or face breach. * Similarly, any comms failure between the P/P service and its customer in a _verified field_ (email/telephone) would trigger a re-verification of that data, and potentially result in the suspension of P/P service or perhaps even the domain. This is also analogous to the WHOIS verification requirements under the 2013 RAA. * However, in the second scenario, I do not agree that the P/P service should be required to notify a 3rd party that their communication attempt has failed and that they are re-verifying their customer¹s contact data. There is no parallel requirement to do so under the current RAA (for example, when a WHOIS reminder email ³bounces²), so I am not unclear why we would want add new obligations to notify third parties. Of course, if the P/P service or domain name was later suspended, it would serve as a de facto notification to all outsiders that the P/P service took action against the nameŠ Thanks- J. On 7/18/14, 23:35 , "Alex_Deacon(a)mpaa.org" <Alex_Deacon(a)mpaa.org> wrote: >Hi all, > >Thinking about relay i¹m curious to hear people views on what happens if >there is a relay failure between the P/P service and their customer. > >For example, in a scenario where no P/P is in use, when I attempt to >communicate with the registrant using info in WHOIS and there is some >kind of failure, (be it a bounce-o-gram for email, a call "can¹t be >completed² or "number not in service" error for phone and a undeliverable >indication for postal mail) the failure indication is returned to me and >I am aware of it. > >Would this be true when a P/P is in the middle of me and the registrant >using the P/P service? I suspect that if there is an automated process >in place (email for example) I may. But if a manual process is in place >(for email, phone or snail mail) there is a possibility that I (as the >original requestor) may not always know if a failure has occurred between >the P/P service and their customer. > >There should be parity between the P/P world and the non-P/P world in >this regard and the original requestor should be aware of any failures >that may occur between the P/P service and the customer. > >To be clear I¹m not talking about not getting a response (i get it) - I¹m >only interested in the failure scenario. > >Thanks and have a great weekend. > >Alex > > > >_______________________________________________ >Gnso-ppsai-pdp-wg mailing list >Gnso-ppsai-pdp-wg(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

4 3

Updated E-1 template
by Mary Wong July 22, 2014

July 22, 2014

Dear all, The attached updated template for E-1 is an attempt to capture the flavor of the WG discussion that took place this week. Hopefully it will be helpful to you in further thinking through the question and the group in coming to preliminary conclusions over the next week or so. Please feel free to continue discussions on any of the points and on the question via email on this list prior to the next WG call on Tuesday. Thanks and cheers Mary Mary Wong Senior Policy Director Internet Corporation for Assigned Names & Numbers (ICANN) Telephone: +1 603 574 4892 Email: mary.wong(a)icann.org

4 4