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

Volker Greimann vgreimann at key-systems.net
Wed Sep 13 14:21:50 UTC 2017


I may be a heretic, but when looking at the escrow requirement, we may 
also look at reducing the frequency of the uploads. I would propose that 
for privacy services, weekly uploads to the excrow service or even 
bi-weekly uploads may be sufficient due to the reduced relevance of 
these services in the registration process compared to that of a registrar.

This would also likely serve to reduce costs.


Am 13.09.2017 um 14:02 schrieb Michele Neylon - Blacknight:
> 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 at icann.org on behalf of gtheo" <gdd-gnso-ppsai-impl-bounces at icann.org on behalf of gtheo at 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 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.
>      _______________________________________________
>      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.





More information about the Gdd-gnso-ppsai-impl mailing list