Michele, Like I said, the licensor aka ICANN org/Compliance. They gave the stamp of approval saying the scofflaw was competent to provide the service. They accepted and ajudicated the complaint as non-complaint. They set the sanctions. They have the duty of care and must exercise the duty to care. -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Process, Governance, Assessment & Turnaround* ============================= On Tue, Aug 7, 2018 at 1:32 PM Michele Neylon - Blacknight < michele@blacknight.com> wrote:
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
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@icann.org> on behalf of Carlton Samuels <carlton.samuels@gmail.com> *Reply-To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org
*Date: *Tuesday 7 August 2018 at 19:14 *To: *"gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@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@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@icann.org] *On Behalf Of *Carlton Samuels *Sent:* Tuesday, August 7, 2018 12:11 PM *To:* gdd-gnso-ppsai-impl@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@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@icann.org] On Behalf Of Sara Bockey Sent: Tuesday, July 31, 2018 8:31 AM To: gdd-gnso-ppsai-impl@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@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@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@icann.org on behalf of gtheo@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@xs4all.nl] Sent: Thursday, July 26, 2018 4:54 AM To: gdd-gnso-ppsai-impl@icann.org Cc: Amy Bivins <amy.bivins@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@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@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 _______________________________________________ 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
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
_______________________________________________ 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