There are 22,000 third-level registrants currently. https://www.icann.org/en/system/files/files/reconsideration-...

(via https://www.icann.org/resources/pages/reconsideration-26-2-s...)

OMG. That is appalling! So the document that Spiridonov submitted clearly shows how Verisign blatantly and repeatedly lied to ICANN on their application. That is absurd. I mean, they are Verisign. To just outright lie like that, about the "life-cycles of domains" and say that there is zero effect, when there are 22,000 customers affected. By Verisign. How can anyone trust them if they blatantly and verifiably lie, in writing, to ICANN? That seems like fraud to me. By Verisign, of all people.

▲

220hertz a day ago | parent | next [-]

By Verisign, you say?

▲

zamadatix 21 hours ago | parent | prev [-]

It's genuinely hard for me to to tell which parts of your comment are supposed to be a sarcastic reaction and which parts are supposed to be serious, which could well be a failure of mine rather than yours, but, taking it all in good faith:

Summary (if you quote anything in response please try to do it from the details section as it's more accurate):

Many of the fields you may have missed explicitly say such entries will be deleted and when. None of the other fields, when interpreted in the way ICANN uses them in this process rather than personal interpretations, state there will be no impact to such registrations. The exact quantity is not really relevant nor does ICANN need that in the request form to know. The links above are about ICANN reviewing and confirming there was no error, lack of information, or false reporting in the process.

Details:

Changes to the life-cycles of domains is a question meant to ask if this seeks to modify the life cycle policy, which is a separate type of change from termination of the service as a whole. I.e. this does not seek to change the life cycle policy, it seeks to terminate the service offering completely - making the life cycle policy irrelevant. It'd be like saying "on the form to scrap the car they said they aren't planning to change the paint. That's fraud because after it's scrapped the paint won't be the same!" - it sounds correct if you feed it through a set of boolean gates but falls apart when you realize the request is one about getting rid of the entire car rather than about requesting to change the paint color.

The links greyface- provided are from a request to ICANN to review this particular concern. The Ombudsman looked at the same material you have seen (and more) to find:

> On the basis of the following substantive evaluation, it is evident that ICANN followed the relevant policies and underlying process thoroughly, had sufficient information, and did not rely on false or inaccurate information in taking action on the relevant RSEP Requests.

Importantly, they further say on this particular subject:

> Approximately, 22,000 domain names may seem material, and it may or may not be—in either case, it was disclosed to ICANN by the Registry Operator as part of the collaborative process before submitting its RSEP Requests.

With the further detail for the fields you're referencing:

> Finally, I consider whether ICANN relied on false and/or inaccurate information: None was relied on the subject matter expert told me, nor does it appear that any such information was provided to ICANN relating to these RSEP Requests and their preceding collaborative processes. While the Requestor is of the view that statements provided by the Registry Operator in the RSEP Requests (“no effect on the lifecycle of domains” “no effect on competition” and “no effect on the domain market”) may be false or inaccurate in light of the discontinuation and termination of the approximately 22,000 registrations,28 as discussed in the preceding sections, the approximately 22,000 registrations are not relevant to ICANN’s determination at hand, and further, as also noted above, this information was disclosed to ICANN in the collaboration phase.

There were also several other issues raised in the reconsideration request, all were similarly found to be rooted in invalid understandings of this form or process.

▲

cxr 20 hours ago | parent [-]

That's not accurate. A valid understanding of the form/process should result in an expectation of a referral to RSTEP to evaluate the impact on security and stability. But that didn't happen.

	▲	zamadatix 18 hours ago \| parent [-]
		Today I feel like some guy who spent 6 years studying the curvature of iguana toes (or something equally random) and finally sees questions about them for the first time in his life :D. Significant effort is spent detailing the relevant parts the RSEP process, confirming and detailing exactly how it was followed correctly. This specifically included whether certain matters were considered for referral (or should have been referred) to RSTEP for review. It's a tragedy to disagree with the well written reconsideration request document without responding to where you feel its analysis was incorrect & why, particularly content from sections: - 4.2.1, designated to contain inquiries related to the RSEP process and if it was accurately followed, including: - 4.2.1.3 referencing the parts of the RSTEP process defining when RSTEP should be engaged - 4.2.2.1 highlighting how voluntary advanced collaboration prior to starting the RSEP process has made the dedicated referral processes referenced in 4.2.1.3 rarely relevant - 4.2.2.2 containing a confirmation by the Ombuds that the preliminary portion of the process was done correctly and with the required info (including the list of 22k domains shared voluntarily before the preliminary phase began, without need to formally refer to RSTEP) - & 4.3 concretely explaining in more plain terms why the Ombuds is sympathetic to the user but believes ICANN correctly followed the RSEP process in not engaging RSTEP for the concerns raised and re-raised About the only thing I think could have been pre-emptively added was a reference to the definitions of Security and Stability concerns, which helps explain why it would have made no sense for RSEP to declare Security or Stability issues in need of referral during preliminary review, let alone "significant" and even ignoring the voluntary early engagement activity: > 1.2 Security - An effect on security by the proposed Registry Service shall mean (A) the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or (B) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards. > 1.3 Stability - An effect on stability shall mean that the proposed Registry Service (A) is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or (B) creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's delegation information or provisioning services. Requesting authorization to terminate a given service & related registrations is clearly neither an unauthorized action/disclosure on registry data as well as clearly not against an IETF RFC. Notably, "Stability" is not defined as "has impact to users" - as well stated towards the end of the reconsideration request: > Second, on the consideration of material information – the loss of approximately 22,000 is important to the individuals–however, this is not relevant to the strictly defined, community-developed policy One can find the source for the material quoted in the reconsideration request response as well as the definitions I I added in above at https://www.icann.org/rsep-en/