[Gdd-gnso-ppsai-impl] [Ext] Re: Updated PP De-Accreditation Procedure Document Attached for IRT review
Sara Bockey
sbockey at godaddy.com
Tue Jul 31 12:30:40 UTC 2018
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
More information about the Gdd-gnso-ppsai-impl
mailing list