[Gdd-gnso-ppsai-impl] Materials, action items from today's PP IRT meeting

Wed Sep 13 11:40:05 UTC 2017

Ah yes, that would be problematic in that scenario.
Multiple deposits seem to counter balance that issues.

Thanks,

Theo

Volker Greimann schreef op 2017-09-13 01:17 PM:
> Hi Theo,
> 
> this is something where we actually disagree. I do not think a single
> deposit is necessarily the best solution.
> 
> Imagine a non-affiliated service provider that provides the service
> for registrations at multiple registrars. If we demanded a single
> deposit, he would be barred from the ability of escrowing the relevant
> data through the respective registrar deposits. But that provider may
> not even have that data because their business is set up in a way that
> they only provide their address to the registrars for customers that
> and handling, but none of the actual domain management, so the
> underlying data rests with the registrars.
> 
> Therefore, multiple deposits must be possible.
> 
> As long as the provider ensures the underlying data is deposited, we
> should be fine.
> 
> Best,
> 
> Volker
> 
> 
> Am 13.09.2017 um 13:08 schrieb gtheo:
>> One more addition to this to keep it basic and straightforward.
>> 
>> Keep it to a single deposit.
>> 
>> Do not mix registrar deposits with privacy providers in combination 
>> with every scenario that is possible.
>> 
>> 
>> Thanks,
>> 
>> Theo
>> 
>> 
>> 
>> gtheo schreef op 2017-09-13 12:13 PM:
>>> Hello all,
>>> 
>>> Escrow.
>>> 
>>> Privacy providers must escrow data, we all agreed this should be the 
>>> case.
>>> 
>>> The scenarios demonstrated by Francisco yesterday was helpful, and I
>>> hope that the IRT members understand that these scenarios are just a
>>> few scenarios, we can identify much more that are already out there.
>>> 
>>> In my opinion, it will be counter productive to try to flesh out all
>>> these scenarios.
>>> It is a lot of work, and most likely we will not be able to capture
>>> all scenarios.
>>> 
>>> But if every privacy provider has to escrow we do not have to include
>>> all those scenarios.
>>> 
>>> The only issue is here is the non-affiliated provider.
>>> We do not have their data, and we cannot escrow their data as a
>>> Registrar or platform provider. If the non-affiliated provider would
>>> move to our platform, no problem, but this is more of a definitional
>>> issue of what a non-affiliated privacy provider is.
>>> 
>>> Everything else be it affiliated, a reseller, whatever, IF it is on
>>> our platform, we can escrow the data. Be it in one big deposit, a
>>> separate deposit, deposits with different escrow agents, technically
>>> all possible and happening.
>>> 
>>> A non-affiliated privacy provider has no affiliation with a Registrar
>>> or platform provider, not technical nor contractual.
>>> They should take care of their deposits, and there are plenty of
>>> options on how to do this.
>>> They should mention in their deposits at which Registrar the domain
>>> names are located.
>>> I assume everyone in the IRT agrees we do not want to end up with a
>>> deposit that is not usable.
>>> 
>>> As soon a non-affiliated privacy provider would use the service of a
>>> Registrar or platform provider there is a contractual relation, and
>>> the privacy provider is no longer not affiliated.  Does this make
>>> sense?
>>> 
>>> Let me know if there are any questions on this subject.
>>> 
>>> Best,
>>> 
>>> Theo Geurts
>>> 
>>> 
>>> 
>>> Amy Bivins schreef op 2017-09-12 06:26 PM:
>>>> Hello, All,
>>>> 
>>>> Thanks so much for your active participation on today's 
>>>> Privacy/Proxy
>>>> IRT call.
>>>> 
>>>> The call recording, slides and chat transcript are available on the
>>>> wiki, https://community.icann.org/display/IRT/12+September+2017. If
>>>> you couldn't attend, I encourage you to review these, as we covered 
>>>> a
>>>> lot of ground this week.
>>>> 
>>>> In summary, with respect to data escrow, IRT members on the call 
>>>> said
>>>> that in drafting the specification, we should keep the proposed
>>>> requirements as open as possible and not attempt to create
>>>> restrictions with respect to various types of
>>>> provider/registrar/affiliate relationships. With respect to the
>>>> accreditation application process, initial input from many IRT 
>>>> members
>>>> was that the process may need to be simplified. With respect to
>>>> accreditation criteria, some IRT members said that we are still
>>>> requiring too much for affiliated providers; other IRT members said 
>>>> we
>>>> may have cut too much for affiliated providers. WE NEED AS MUCH
>>>> FEEDBACK ON THIS TOPIC AS POSSIBLE, GIVEN THAT THE VIEWS AMONG IRT
>>>> MEMBERS APPEAR TO BE QUITE MIXED. WE WILL CONTINUE DISCUSSING THIS
>>>> TOPIC NEXT WEEK.
>>>> 
>>>> IRT ACTION ITEMS
>>>> 
>>>> Please provide any further input you have on the topics discussed on
>>>> today's call, including (a) the data escrow questions presented by
>>>> Francisco Arias, (b) the "initial application window" process and 
>>>> (c)
>>>> the proposed affiliate categories for accreditation processing
>>>> purposes, NO LATER THAN NEXT MONDAY, 18 SEPTEMBER. Also, please
>>>> continue reviewing the PPAA draft v1 and send any additional topics
>>>> that you would like to discuss to the list (we have several topics 
>>>> to
>>>> revisit, but once we reach the end of the list, we will move on if 
>>>> no
>>>> other topics are raised).
>>>> 
>>>> Next week, we will continue discussing the second draft of the
>>>> applicant guide, including any feedback you have on the topics
>>>> discussed this week, plus the application questions and fees 
>>>> proposal.
>>>> To aid this discussion, I am attaching an editable word version of 
>>>> the
>>>> document, which Volker requested, so that proposed edits can be 
>>>> marked
>>>> on the document. Please mark any proposed edits in track changes
>>>> mode--this is how we will identify proposed changes to discuss with
>>>> the group.
>>>> 
>>>> If you have questions or comments, please don't hesitate to reply to
>>>> the list.
>>>> 
>>>> Best,
>>>> 
>>>> Amy
>>>> 
>>>> 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 [1]
>>>> 
>>>> 
>>>> 
>>>> Links:
>>>> ------
>>>> [1] http://www.icann.org
>>>> _______________________________________________
>>>> Gdd-gnso-ppsai-impl mailing list
>>>> Gdd-gnso-ppsai-impl at icann.org
>>>> https://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
> 
> --
> Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
> 
> Mit freundlichen Grüßen,
> 
> Volker A. Greimann
> - Rechtsabteilung -
> 
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
> 
> Geschäftsführer: Alexander Siffrin
> Handelsregister Nr.: HR B 18835 - Saarbruecken
> Umsatzsteuer ID.: DE211006534
> 
> Member of the KEYDRIVE GROUP
> www.keydrive.lu
> 
> Der Inhalt dieser Nachricht ist vertraulich und nur für den
> angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe,
> Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist
> unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so
> bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung
> zu setzen.
> 
> --------------------------------------------
> 
> Should you have any further questions, please do not hesitate to 
> contact us.
> 
> Best regards,
> 
> Volker A. Greimann
> - legal department -
> 
> Key-Systems GmbH
> Im Oberen Werk 1
> 66386 St. Ingbert
> Tel.: +49 (0) 6894 - 9396 901
> Fax.: +49 (0) 6894 - 9396 851
> Email: vgreimann at key-systems.net
> 
> Web: www.key-systems.net / www.RRPproxy.net
> www.domaindiscount24.com / www.BrandShelter.com
> 
> Follow us on Twitter or join our fan community on Facebook and stay 
> updated:
> www.facebook.com/KeySystems
> www.twitter.com/key_systems
> 
> CEO: Alexander Siffrin
> Registration No.: HR B 18835 - Saarbruecken
> V.A.T. ID.: DE211006534
> 
> Member of the KEYDRIVE GROUP
> www.keydrive.lu
> 
> This e-mail and its attachments is intended only for the person to
> whom it is addressed. Furthermore it is not permitted to publish any
> content of this email. You must not use, disclose, copy, print or rely
> on this e-mail. If an addressing or transmission error has misdirected
> this e-mail, kindly notify the author by replying to this e-mail or
> contacting us by telephone.