[Gdd-gnso-ppsai-impl] Materials, IRT Action Items from 30 May PP Call, “unaffiliated provider” issue

Wed May 31 11:52:21 UTC 2017

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 at mpaa.org
> +1.415.802.9776
> Twitter: @_AlexDeacon
> 
> 
> 
> -----Original Message-----
> From: <gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of theo geurts
> <gtheo at xs4all.nl>
> Reply-To: "gdd-gnso-ppsai-impl at icann.org" 
> <gdd-gnso-ppsai-impl at icann.org>
> Date: Tuesday, May 30, 2017 at 11:37 AM
> To: "gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>,
> Amy Bivins <amy.bivins at 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 at icann.org
>     www.icann.org <http://www.icann.org>
> 
> 
> 
> 
>     _______________________________________________
>     Gdd-gnso-ppsai-impl mailing list
> 
> Gdd-gnso-ppsai-impl at icann.orghttps://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
> 
> 
> 
> 
> _______________________________________________
> Gdd-gnso-ppsai-impl mailing list
> Gdd-gnso-ppsai-impl at icann.org
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl