[Gdd-gnso-ppsai-impl] [Ext] Re: Updated PP De-Accreditation Procedure Document Attached for IRT review

Darcy Southwell darcy.southwell at endurance.com
Mon Aug 6 19:37:00 UTC 2018


Thanks for the follow up, Amy.  The PPSAI PDP was clear that P/P customers
should be notified in advance of de-accreditation.  I don't see where the
PDP proposed a bulk "transition" option.  Can you shed further light on the
policy recommendation since I'm not finding it?

>From an operational perspective, inserting a bulk "transition" piece really
over complicates this.  Registrars of record have to collaborate with or
implement a P/P service (whether the registrar operates it or the registrar
contracts with a third party).  Just like any other service a registrar
offers to a registrant in conjunction with domain name registration (e.g.,
hosting or email), the registrar will handle the decision of what to offer,
how, etc.  Inserting ICANN into managing the so-called "transition" isn't
necessary.

Thanks,
Darcy

On Mon, Aug 6, 2018 at 11:51 AM Amy Bivins <amy.bivins at icann.org> wrote:

> Apologies, I should have finished that thought before hitting send.
>
> The reference to an inter-registrar bulk transfer would be in the
> circumstance where a PP provider is terminated, and the registrar elects
> not to contract with any new PP provider (so that a customer could not use
> a PP provider at that registrar at all). In that instance, the draft
> procedure would require a notice to the customer alerting the customer that
> they would have the option to initiate an inter-registrar transfer if they
> do not wish to continue to have their name with a registrar where PP is not
> an option. I hope this makes sense. I hope to have this document ready for
> the group to review this week.
>
> Best,
> Amy
>
> -----Original Message-----
> From: Gdd-gnso-ppsai-impl [mailto:gdd-gnso-ppsai-impl-bounces at icann.org]
> On Behalf Of Amy Bivins
> Sent: Monday, August 6, 2018 2:48 PM
> To: gdd-gnso-ppsai-impl at icann.org
> Subject: Re: [Gdd-gnso-ppsai-impl] [Ext] Re: Updated PP De-Accreditation
> Procedure Document Attached for IRT review
>
> Hi Sara and Volker (and all),
>
> I believe the summary of where we are proceeding based on your feedback
> was misunderstood--we are looking at a bulk transition to a new provider,
> as you recommend here, in cases where the registrar will cooperate and
> wishes to contract with a new PP provider. We are not talking about an
> inter-registrar bulk transfer. I think this will be more clear once the
> group is able to review proposed revisions to the document.
>
> Best,
> Amy
>
> -----Original Message-----
> From: Gdd-gnso-ppsai-impl [mailto:gdd-gnso-ppsai-impl-bounces at icann.org]
> On Behalf Of Sara Bockey
> Sent: Monday, August 6, 2018 2:44 PM
> To: gdd-gnso-ppsai-impl at icann.org
> Subject: Re: [Gdd-gnso-ppsai-impl] [Ext] Re: Updated PP De-Accreditation
> Procedure Document Attached for IRT review
>
> Agree with Volker.  I don't think using the word "transition" helps and
> the idea that changing PP Provider requires a change of registrar is just
> wrong.  The Provider is a separate entity from the registrar.  Registrars
> need the ability to contract with a new PP Provider should a Provider's
> service be terminated.
>
> Sara Bockey
> GoDaddy | Senior Policy Manager
> +1 480-366-3616
> sbockey at godaddy.com
>
> This email message and any attachments hereto is intended for use only by
> the addressee(s) named herein and may contain confidential information. If
> you have received this email in error, please immediately notify the sender
> and permanently delete the original and any copy of this message and its
> attachments.
>
>
>
> On 8/6/18, 3:54 AM, "Gdd-gnso-ppsai-impl on behalf of Volker Greimann" <
> gdd-gnso-ppsai-impl-bounces at icann.org on behalf of
> vgreimann at key-systems.net> wrote:
>
>     Hi Amy,
>
>     transition is just as bad. There simply is no reason why a termination
>     of a privacy service provider would necessitate or even justify a
>     registrar transfer. Requiring registrar coordination does not help
>     either. The registrant expects to find the domain names he owns in the
>     user account with the provider he chose, not with another registrar he
>     has no agreement with, has not provided payment details to. etc.
>
>     You are creating a nightmare for registrars and registrants alike,
> with
>     no justification from anything the WG decided.
>
>     Oh, and the fees need to go!
>
>     Best,
>
>     Volker
>
>
>     Am 06.08.2018 um 09:53 schrieb gtheo:
>     > Hi Amy,
>     >
>     > Correct me if I am wrong, but does that imply the proposed fees are
>     > based on the onboarding, but there are no details regarding the
>     > operational costs?
>     >
>     > Thanks,
>     >
>     > Theo
>     >
>     >
>     > Amy Bivins schreef op 2018-08-03 07:34 PM:
>     >> Thanks, Sara and Theo for your feedback on this.
>     >>
>     >> I'm working on some proposed edits to this document based on your
>     >> feedback--once I can discuss with Legal I'll have an updated draft
> for
>     >> you. I hope to be able to send a draft to the list next week.
>     >>
>     >> To start, we're planning to change the word "transfer" to
> "transition"
>     >> and to explicitly require coordination with the registrar as a
>     >> necessary step for a bulk transition. We're also taking another look
>     >> at notice requirements where a registrar is not involved in the
>     >> facilitation of a bulk transfer, in which case a customer might need
>     >> to transfer out if the customer wishes to transition to a new PP
>     >> service provider.
>     >>
>     >> Theo, regarding your comments on the fees proposal, the activities
>     >> listed as contributors to ongoing expected program costs (one of
> the 3
>     >> elements that fed into the proposed fees determination) were not
>     >> itemized the way they were for the application phase (this would
>     >> require a broader analysis).
>     >>
>     >> Thanks, all, and have a great weekend.
>     >>
>     >> Amy
>     >>
>     >>
>     >>
>     >> -----Original Message-----
>     >> From: Gdd-gnso-ppsai-impl
>     >> [mailto:gdd-gnso-ppsai-impl-bounces at icann.org] On Behalf Of Sara
>     >> Bockey
>     >> Sent: Tuesday, July 31, 2018 8:31 AM
>     >> To: gdd-gnso-ppsai-impl at icann.org
>     >> Subject: Re: [Gdd-gnso-ppsai-impl] [Ext] Re: Updated PP
>     >> De-Accreditation Procedure Document Attached for IRT review
>     >>
>     >> Again. Agree with Theo.  Use of the word “transfer” is confusing and
>     >> problematic.  We need to be able to reassign the service, contract
>     >> with a new provider.  Actual transfers would seem to be a dead last
>     >> option. We don’t want to penalize the customer just because the P/P
>     >> service changes.
>     >>
>     >> Sara
>     >>
>     >> Sent from my iPhone. Apologies for typos and/or brevity.
>     >>
>     >>> On Jul 31, 2018, at 1:39 AM, gtheo <gtheo at xs4all.nl> wrote:
>     >>>
>     >>> I think the word transfer is somewhat confusing or does not meet
> the
>     >>> objective or can cause results that are not wanted.
>     >>>
>     >>> I can imagine a reseller using privacy provider X.
>     >>> Privacy Provider X merges or hands over the business to Privacy
>     >>> Provider ABC.
>     >>>
>     >>> The most logical path is that the reseller updates the domain
> names
>     >>> to the details of Privacy Provider ABC.
>     >>>
>     >>> Transfering the domain names in bulk or through an inter-registrar
>     >>> transfer to the registrar of privacy provider ABC could be not
>     >>> wanted for various reasons.
>     >>> Reseller has to implement a new API with the new registrar.
>     >>> Billing issues.
>     >>> The new registrar may lack features key critical to the reseller
> at
>     >>> the current registrar.
>     >>> Etc the list is long.
>     >>>
>     >>> A bulk transfer at a registry level, poorly communicated could
>     >>> create chaos.
>     >>>
>     >>> Regarding the fees. The fee document seems to have two major
>     >>> components.
>     >>> Program Startup and Application Processing Here are all the costs
>     >>> listed.
>     >>>
>     >>> Then there is the; Ongoing Accreditation Program Maintenance Here
> are
>     >>> no fees listed.
>     >>> Are the fees of the ongoing program maintenance listed in the
>     >>> program startup and application processing?
>     >>>
>     >>> For example, Complaint processing is listed as ongoing. What are
>     >>> those costs? Or can I simply exclude them as those costs are not
>     >>> taken into account? How does that work?
>     >>> I think it is relevant as I expect complaint processing cannot be
>     >>> compared to the current situation in case of a registrar.
>     >>>
>     >>> Thanks!
>     >>> Theo
>     >>>
>     >>>
>     >>> Sara Bockey schreef op 2018-07-30 10:31 PM:
>     >>>> Apologies for weighing in late here, but I agree with Theo.  I'm
> not
>     >>>> understanding why the registrar would need to change per se.  I
> also
>     >>>> can imagine a scenario where a privacy provider (or registrar)
>     >>>> reaches an agreement with another privacy provider to provide
>     >>>> privacy.  In fact, I think this would be the most likely option we
>     >>>> would want - allow the registrar to contract with a new provider.
>     >>>> Sara
>     >>>> sara bockey
>     >>>> sr. policy manager | GoDaddy™
>     >>>> sbockey at godaddy.com  480-366-3616
>     >>>> skype: sbockey
>     >>>> This email message and any attachments hereto is intended for use
>     >>>> only by the addressee(s) named herein and may contain confidential
>     >>>> information. If you have received this email in error, please
>     >>>> immediately notify the sender and permanently delete the original
> and
>     >>>> any copy of this message and its attachments.
>     >>>> On 7/26/18, 10:23 AM, "Gdd-gnso-ppsai-impl on behalf of Theo
> Geurts"
>     >>>> <gdd-gnso-ppsai-impl-bounces at icann.org on behalf of
> gtheo at xs4all.nl>
>     >>>> wrote:
>     >>>>    Hi Amy,
>     >>>>    If it is supposed to address both situations, isn't it
> somewhat
>     >>>> odd a
>     >>>>    privacy provider can order a bulk transfer to another privacy
>     >>>> provider
>     >>>>    at another registrar?
>     >>>>    I can imagine a scenario where a privacy provider reaches an
>     >>>> agreement
>     >>>>    with another privacy provider to update all the domain names
> to one
>     >>>>    privacy provider. But to transfer domain names in bulk in the
> above
>     >>>>    scenario, does that benefit the registrant? I think it could
> create
>     >>>>    total chaos and disruption of services.  Or is the above
> scenario
>     >>>>    unthinkable and am I chasing ghosts here?
>     >>>>    Thanks,
>     >>>>    Theo
>     >>>>    On 26-7-2018 15:03, Amy Bivins wrote:
>     >>>>    > Hi Theo,
>     >>>>    >
>     >>>>    > Thanks for your feedback.
>     >>>>    >
>     >>>>    > This was drafted to try to accommodate both types of
> situations,
>     >>>> though, practically speaking, it seems probable that in most cases
>     >>>> this would often involve an inter-registrar transfer.
>     >>>>    >
>     >>>>    > There's nothing explicit in the document that would require
>     >>>> obtaining consent from the registrar to a provider-provider bulk
>     >>>> transfer under the same registrar. Do you (and others) think this
>     >>>> should be an explicit requirement?
>     >>>>    >
>     >>>>    > Best,
>     >>>>    > Amy
>     >>>>    >
>     >>>>    > -----Original Message-----
>     >>>>    > From: gtheo [mailto:gtheo at xs4all.nl]
>     >>>>    > Sent: Thursday, July 26, 2018 4:54 AM
>     >>>>    > To: gdd-gnso-ppsai-impl at icann.org
>     >>>>    > Cc: Amy Bivins <amy.bivins at icann.org>
>     >>>>    > Subject: [Ext] Re: [Gdd-gnso-ppsai-impl] Updated PP
>     >>>> De-Accreditation Procedure Document Attached for IRT review
>     >>>>    >
>     >>>>    > Hi Any, et al,
>     >>>>    >
>     >>>>    > 4.4  Voluntary Bulk Transfers, are we talking "transfers"
> from
>     >>>> one privacy provider to another, or can a privacy provider
> request a
>     >>>> transfer of all the domain names that are being used by a privacy
>     >>>> provider at a registrar to another privacy provider at another
>     >>>> registrar?
>     >>>>    > I am somewhat struggling here with what we want to achieve
> and
>     >>>> what a privacy provider can do here.
>     >>>>    >
>     >>>>    > I think in all cases when a privacy provider requests a bulk
>     >>>> transfer the sponsoring registrar has to agree also?
>     >>>>    >
>     >>>>    > Thanks,
>     >>>>    >
>     >>>>    > Theo
>     >>>>    >
>     >>>>    >
>     >>>>    >
>     >>>>    > Amy Bivins schreef op 2018-07-25 03:37 PM:
>     >>>>    >> Dear Colleagues,
>     >>>>    >>
>     >>>>    >> Attached you will find a new draft of the PP
> De-accreditation
>     >>>> and
>     >>>>    >> transition procedure, updated based on IRT feedback and our
>     >>>> final
>     >>>>    >> (prior to public comment) internal review. If you have any
>     >>>> further
>     >>>>    >> questions or comments on this document, please send them to
>     >>>> the list.
>     >>>>    >>
>     >>>>    >> We're nearly finished with the final editing/review process
>     >>>> for the
>     >>>>    >> applicant guide and fees document, as well (there will be
>     >>>> copy edits
>     >>>>    >> but no significant substantive changes). I'll send those to
>     >>>> the list
>     >>>>    >> as soon as they are complete, likely before the end of this
>     >>>> week.
>     >>>>    >>
>     >>>>    >> 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]
>     >>>>    >>
>     >>>>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=Dw
>     >>>>    >>
>     >>>>
> ICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=uerz4ckt1v4Qhbv-T
>     >>>>    >>
>     >>>>
> plkjKTey9bgtdWrvLyZDu0mXuk&m=hoLHeBVkfOcUxl26F4OYnebcOzy-XUfRDXDSvGv8A
>     >>>>    >> vg&s=5TMUWmSpDbgeDaUkHtpmsyqhRhCEwWEKZSzPLqkJfwE&e=
>     >>>>    >> _______________________________________________
>     >>>>    >> 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
>     >>>> _______________________________________________
>     >>>> 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
>     >> _______________________________________________
>     >> 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
>     > _______________________________________________
>     > 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
>
> _______________________________________________
> 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
> _______________________________________________
> Gdd-gnso-ppsai-impl mailing list
> Gdd-gnso-ppsai-impl at icann.org
> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gdd-gnso-ppsai-impl/attachments/20180806/4185f114/attachment-0001.html>


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