Hi Alex, Let me reword this better. RDE Deposit Registrars. You can match the deposit with the amount the of domain names under management. Registrars are also required to provide the real registrant data within the deposit and the data as mentioned in the whois. So this can be verified. But you do not have that authoritative information with a non-affiliated third party provider. Unless I am missing something? Or do we require NA-TPPP customers to provide to the NA-TPPP wich Registrar they are using and this will be escrowed? I did not consider as I came up with the following issues. -Transfers -Ownership Changes -How would you track this all? -Risk of incorrect Registrar being supplied by the Registrant will reflect in escrow and as such faulty escrow records Again, I think it all boils down to the verifiable authoritative data right? If you cannot verify it, the escrow deposit will have no value and provide a false sense of security for registrants. Best regards, Theo Geurts Deacon, Alex schreef op 2017-05-31 02:31 AM:
Hi Theo,
Can you expand on your comment that “RDE Deposit does not include Registrars, they are not affiliated.”? I don’t have quick access to the final report but is it not the case that all accredited P/P services data will be escrowed? Even those that are non-affiliated? I’m sure the interim policy in the RAA has an escrow requirement. If this is the case then ICANN should have access to the data from the RDE deposit.
Regarding the scenario that email relay is not working or the website is not functional - what policies are in place if this happens when a registrar goes out of biz? Putting aside for now the P/P use case and thinking about a similar scenario where a Registrar goes out of biz and the email to the registrant fails, is there policy/implementation that we can leverage/reuse/reference? (I understand the scale is different – but am hoping this kind of issue has been addressed/solved before.)
Thanks.
Alex
Alex Deacon Senior VP, Internet Technology Motion Picture Association of America alex_deacon@mpaa.org +1.415.802.9776 Twitter: @_AlexDeacon
-----Original Message----- From: <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of theo geurts <gtheo@xs4all.nl> Reply-To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Date: Tuesday, May 30, 2017 at 11:37 AM To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org>, Amy Bivins <amy.bivins@icann.org> Subject: Re: [Gdd-gnso-ppsai-impl] Materials, IRT Action Items from 30 May PP Call, “unaffiliated provider” issue
Thanks Amy,
The problem scope of non-affiliated third party privacy providers (NA-TPPP) is as follows.
Using the law firm that as mentioned in the chat during the call as an example. There are many more examples.
Imagine a law firm with a lot of clients providing privacy services. The law firm is accredited for this service and not affiliated with a Registrar.
* Total domain names 100.000 * Scattered over 100 Registrars for whatever reason
Now the law firm goes under for some reason. ICANN starts the de-accreditation process and obtains the RDE deposit from the escrow provider.
Operational issues:
* The RDE Deposit does not include Registrars, they are not affiliated. * Email, email forward, email alias, website forms with a relay, most likely will not be operational
* If email is down, IRTP-C will prevent domain name update, Registrars cannot fix this in a simple manner.
Who is going to fix this? I think that is the first question, or perhaps the first question is, do we want to be in a situation that is a huge can of worms and eventually the registrant will take a hit at some point?
Best regards,
Theo Geurts
On 30-5-2017 18:57, Amy Bivins wrote:
Dear Colleagues,
Thanks so much for your active participation on today’s Privacy/Proxy IRT call. If you were unable to attend, I encourage you to listen to the recording because we covered a lot of ground today. The recording is available on the wiki, https://participate.icann.org/p6bxagpwaq9/
IRT Action Items (1) Please submit any additional feedback you have on the draft v1 applicant guide (attached) by Friday. We will be discussing again and there will be more opportunities for discussion, but the more feedback we have now the better, as we will use the feedback received this week in drafting v2. A summary of your feedback received to date on the applicant guide is attached. I am also attaching the results of the IRT survey of initial operational questions that you completed back in February—this came up briefly on today’s call. I apologize that I over-stated the point referenced today on the call—I said that the majority of the IRT said in the poll that the existence of a PP Provider application and/or the contents of an application for accreditation should not be made public. This is true—there was a slight majority of the IRT for this point on each of the questions, but it was a very close result for both questions and the number of participants was relatively low for this poll. (2) Please submit your feedback on the RDDS labeling proposals discussed on today’s call no later than Friday. For those not on the call, the Registrar Subteam has developed two possible solutions to implementing the recommendation that registrations involving privacy and/or proxy services should be clearly labeled as such in WHOIS. The first solution would be to (a) require that the privacy/proxy service provider name and ICANN ID appear in the registrant name and/or the registrant organization field (the “or” is to accommodate privacy services where the customer’s name appears in the Registrant Name field--this was discussed further on the call). The second solution was (b) require that the privacy/proxy service provider’s name, ICANN ID and a URL to the ICANN webpage listing of all accredited providers and contact information.
The IRT was roughly split on these proposals. Some IRT members saw an added benefit to the URL (which would provide an easily-identifiable source of Provider contact information that may not be visible in WHOIS), while others thought the URL was unnecessary and could complicate automated uses of the label. If no clear consensus is reached on the list on the path forward on this one, we will take this to a poll.
(3) Please submit any additional feedback you have regarding the “unaffiliated provider” issue raised by the registrar subteam today on the call. In summary, members of the registrar subteam have suggested that certain operational issues may make the accreditation of providers that are not affiliated with a registrar highly undesirable or impossible.
There have been challenges noted by IRT members and staff throughout this IRT related to unaffiliated providers (particularly in the area of de-accreditation). However, as noted on the call, the Final Report does clearly reference unaffiliated providers, which seems to indicate an intent that unaffiliated providers should be permitted to become accredited. As a result, any potential question/action that would limit eligibility for accreditation by providers that are not affiliated with a registrar would likely need to be taken to the GNSO Council for guidance. At this stage, we are hoping to gather as much IRT input as possible on this so that we can determine how best to proceed. Please send your feedback to the list on this topic this week. As any changes on this point would have a substantial impact on the overall implementation of this program, any action on this should be taken as soon as practicable.
Thanks so much for your attention to these matters. Please don’t hesitate to contact me or write to the list directly if you have additional comments or questions.
Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org www.icann.org <http://www.icann.org>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list
Gdd-gnso-ppsai-impl@icann.orghttps://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl