[Gnso-ppsai-pdp-wg] Relay failure notification

[Williams, Todd]

Thanks James, appreciate your thoughts, but not sure that I understand why the RAA is relevant to Alex's point, which I thought was a good one: in the absence of a P/P service, the fact that there has been a delivery failure will be communicated back to the complainant (e.g., bounce-back email; undeliverable notice for postal mail).  Because that undeliverable notice itself can serve as a valuable piece of evidence, if there is a way that we can bake in something analogous for P/P relay standards, I would think we would want to.  

That said, what would be the argument against doing so?  And perhaps I'm missing it, but how is the RAA relevant to that argument?

Thanks.

Todd.      

-----Original Message-----
From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of James M. Bladel
Sent: Saturday, July 19, 2014 1:53 AM
To: Alex_Deacon at mpaa.org; gnso-ppsai-pdp-wg at icann.org
Subject: Re: [Gnso-ppsai-pdp-wg] Relay failure notification

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 at mpaa.org" <Alex_Deacon at 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 at icann.org
>https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

_______________________________________________
Gnso-ppsai-pdp-wg mailing list
Gnso-ppsai-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg