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@icann.org
www.icann.org [1]
Links: ------ [1] http://www.icann.org _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://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
-- 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@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@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.