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

Wed Sep 13 11:17:46 UTC 2017

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.