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@mpaa.org" <Alex_Deacon@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of James M. Bladel Sent: Saturday, July 19, 2014 1:53 AM To: Alex_Deacon@mpaa.org; gnso-ppsai-pdp-wg@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@mpaa.org" <Alex_Deacon@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
_______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
Hi Todd and Alex, According to my reading of the 2013 RRA, the use of a P/P provider service should be seen as a subcontracting of the registrant obligation to provide accurate details where they can be reached at for the whois database. Like any domain name registrant, the user of a P/P service must provide accurate details where they are reachable at. The fact that the P/P provider substitutes to those details a set of generic ones for the whois database has no impact. In any case, registrants will need to be able to verify that the email address registered in the whois database allows to reach them. Thus, Alex you should still receive this bounce-email if the address registered in the whois is invalid. Instead of receiving an error message from a meaningful address such as registrant@domain.email, you will receive one from 146HGF3569JG35@ppprovider.com but it should have the same value in the eyes of ICANN compliance or any court (if that’s the kind of value you were referring to). Luc On Jul 21, 2014, at 16:20, Williams, Todd <Todd.Williams@turner.com> wrote:
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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of James M. Bladel Sent: Saturday, July 19, 2014 1:53 AM To: Alex_Deacon@mpaa.org; gnso-ppsai-pdp-wg@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@mpaa.org" <Alex_Deacon@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
_______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
________________________________ -------------------------------------------------------- This e-mail and any attached files are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail by mistake, please notify the sender immediately and delete it from your system. You must not copy the message or disclose its contents to anyone. Think of the environment: don't print this e-mail unless you really need to. --------------------------------------------------------
Thanks Luc, I think we are in agreement. Regarding your last paragraph I just want to clarify that email error messages should be returned to the originator no matter how the P/P implements the email relay (forwarding, web form, manual process or something else) and that this should be the case for all communications (phone or postal). Regards, Alex On Jul 21, 2014, at 9:41 AM, Luc SEUFER <lseufer@dclgroup.eu> wrote:
Hi Todd and Alex,
According to my reading of the 2013 RRA, the use of a P/P provider service should be seen as a subcontracting of the registrant obligation to provide accurate details where they can be reached at for the whois database.
Like any domain name registrant, the user of a P/P service must provide accurate details where they are reachable at. The fact that the P/P provider substitutes to those details a set of generic ones for the whois database has no impact. In any case, registrants will need to be able to verify that the email address registered in the whois database allows to reach them.
Thus, Alex you should still receive this bounce-email if the address registered in the whois is invalid. Instead of receiving an error message from a meaningful address such as registrant@domain.email, you will receive one from 146HGF3569JG35@ppprovider.com but it should have the same value in the eyes of ICANN compliance or any court (if that’s the kind of value you were referring to).
Luc
On Jul 21, 2014, at 16:20, Williams, Todd <Todd.Williams@turner.com> wrote:
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@icann.org [mailto:gnso-ppsai-pdp-wg-bounces@icann.org] On Behalf Of James M. Bladel Sent: Saturday, July 19, 2014 1:53 AM To: Alex_Deacon@mpaa.org; gnso-ppsai-pdp-wg@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@mpaa.org" <Alex_Deacon@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
_______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg _______________________________________________ Gnso-ppsai-pdp-wg mailing list Gnso-ppsai-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg
________________________________
--------------------------------------------------------
This e-mail and any attached files are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail by mistake, please notify the sender immediately and delete it from your system. You must not copy the message or disclose its contents to anyone.
Think of the environment: don't print this e-mail unless you really need to.
--------------------------------------------------------
participants (4)
-
Alex_Deacon＠mpaa.org -
James M. Bladel -
Luc SEUFER -
Williams, Todd