[Gdd-gnso-ppsai-impl] [Ext] Re: Updated PP De-Accreditation Procedure Document Attached for IRT review
Michele Neylon - Blacknight
michele at blacknight.com
Tue Aug 7 18:32:06 UTC 2018
Carlton
Sorry, but who is going to send this notice?
If the provider is in breach it’s probably because they haven’t been able to comply with contractual obligations.
Regards
Michele
--
Mr Michele Neylon
Blacknight Solutions
Hosting, Colocation & Domains
https://www.blacknight.com
https://blacknight.blog /
http://ceo.hosting/
Intl. +353 (0) 59 9183072
Direct Dial: +353 (0)59 9183090
-------------------------------
Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
Road,Graiguecullen,Carlow, R93 X265
,Ireland Company No.: 370845
From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of Carlton Samuels <carlton.samuels at gmail.com>
Reply-To: "gdd-gnso-ppsai-impl at icann.org" <gdd-gnso-ppsai-impl at icann.org>
Date: Tuesday 7 August 2018 at 19:14
To: "gdd-gnso-ppsai-impl at icann.org" <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
Dear Amy:
What you have outlined is precisely what should happen.
The licensor - ICANN org - has a duty of care to the licensee's customer. That duty to care is exercised by good faith effort of the licensor to contact and update the licensee's customer from the moment the licensee - the P/P provider is adjudged to be in breach. There is a timeline for breach remediation. Assuming the breach is not mended, then the de-accreditation process kicks in.
In that communique to the P/P customer, the reasons will be outlined, the timeline for remediation and what will happen if not remediated; inaccurate WHOIS-RDS data which makes the domain name subject to suspension. That communique must outline the options available to that P/P customer if they wish to do to avoid that eventuality. I do not believe a registrar-marketing assist - which is what that bulk-transfer matter becomes for a favoured one is! - is ICANN's business.
It is done. Leave it to the registrant to act in their best interest.
-Carlton
==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Process, Governance, Assessment & Turnaround
=============================
On Tue, Aug 7, 2018 at 12:19 PM Amy Bivins <amy.bivins at icann.org<mailto:amy.bivins at icann.org>> wrote:
Thanks, Carlton and all.
For those who recommend that ICANN org drop any reference to a bulk transition procedure from a terminating PP to a new PP, even if the registrar wants and agrees to facilitate this, how do you see this working for customers once the provider is terminated?
As the documents are drafted today, once a provider is terminated, the RDDS contact information is considered “inaccurate” for purposes of the registrar’s WHOIS accuracy program obligations under the RAA. At that stage, following the progression of the WHOIS Accuracy Program, the customers’ names could potentially be suspended by the registrar if the customer does not update the contact information (either their own, or by signing up for a new PP service) to correct the inaccuracy. Is that the intended result?
Best,
Amy
From: Gdd-gnso-ppsai-impl [mailto:gdd-gnso-ppsai-impl-bounces at icann.org<mailto:gdd-gnso-ppsai-impl-bounces at icann.org>] On Behalf Of Carlton Samuels
Sent: Tuesday, August 7, 2018 12:11 PM
To: gdd-gnso-ppsai-impl at icann.org<mailto: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
Seems to me this is a simple case of caveat emptor! The P/P provider covenants that it has sold a service for which it is fully qualified to sell and provide, so far as that is required.
The P/P customer accepts and covenants it has acquired the service in good faith and credit.
P/P is not a baseline requirement pertaining stability and security of the DNS but an add-on choice. If the P/P provider turns out to be a scofflaw then the most that should happen is to take due care the P/P customer be given due notice that they bought a bill of goods and what is coming at them. And if they still need the conservation the service offers then they ought to go find another P/P service provider in good standing.
-Carlton
==============================
Carlton A Samuels
Mobile: 876-818-1799
Strategy, Process, Governance, Assessment & Turnaround
=============================
On Fri, Aug 3, 2018 at 12:34 PM Amy Bivins <amy.bivins at icann.org<mailto:amy.bivins at icann.org>> wrote:
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<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<mailto: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<mailto: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<mailto: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<mailto:gdd-gnso-ppsai-impl-bounces at icann.org> on behalf of gtheo at xs4all.nl<mailto: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<mailto:gtheo at xs4all.nl>]
>> > Sent: Thursday, July 26, 2018 4:54 AM
>> > To: gdd-gnso-ppsai-impl at icann.org<mailto:gdd-gnso-ppsai-impl at icann.org>
>> > Cc: Amy Bivins <amy.bivins at icann.org<mailto: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<mailto:amy.bivins at icann.org>
>> >>
>> >> www.icann.org<http://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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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/20180807/28cf39a1/attachment-0001.html>
More information about the Gdd-gnso-ppsai-impl
mailing list