We all agree that the providers need to escrow We also probably agree that the current setup for escrow would be problematic due to its lack of flexibility However, as I mentioned on the call yesterday, we’ve no way of knowing about all possible scenarios, so whatever is done needs to be flexible enough to ensure that the data is escrowed -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ http://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 On 13/09/2017, 12:41, "gdd-gnso-ppsai-impl-bounces@icann.org on behalf of gtheo" <gdd-gnso-ppsai-impl-bounces@icann.org on behalf of gtheo@xs4all.nl> wrote: Ah yes, that would be problematic in that scenario. Multiple deposits seem to counter balance that issue. 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. _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl