Summary

  • India's 14 July letter asks for pre-activation email and phone validation, mandatory and centralized DNS-abuse reporting, and operational law-enforcement authentication for urgent registration-data requests.
  • ICANN's President and CEO says the first two matters warrant further consideration and are being discussed in GNSO prioritization, but he cannot direct GNSO priorities or policy outcomes.
  • The authentication input group has meetings and milestones from June 2026 to March 2027. It is expressly not a policy-development body, and its proof of concept will not by itself activate the 24-hour requirement.
  • A public request-route receipt would show the competent body, current state, governing process, next authorized decision and what that state does not yet mean for each request.

Three requests, not one urgency claim

On 14 July 2026, S. Krishnan, Secretary of India's Ministry of Electronics and Information Technology, wrote to ICANN President and CEO Kurt Erik Lindqvist. The letter describes three issues as long pending and asks that they receive immediate priority. Their common frame is DNS safety, but they are different governance objects.

The first request concerns contact verification. India wants email addresses and telephone numbers validated before a domain is activated, rather than leaving the current post-inquiry response period in place. It presents the change as achievable through minor contractual amendments. ICANN's published materials on the Whois Accuracy Program explain the existing 15-calendar-day response consequence after an accuracy inquiry. They do not say that India's proposed redesign has been adopted.

The second request concerns reporting. India wants registrars and registries to publish periodic statistics on DNS-abuse complaints, the type of abuse, mitigation action and response time. It also asks ICANN for a centralized reporting mechanism. That request combines at least two decisions: whether to impose a reporting duty and whether a common system should collect or publish the result. A central table is not automatically comparable evidence. It would still need common definitions, coverage, denominators, correction rules and a way to distinguish a complaint from a confirmed event.

The third request concerns urgent access to nonpublic registration data. The Registration Data Policy now contains a two-hour acknowledgment and a response within 24 hours, subject to a bounded exception. But its implementation note says section 10.7 becomes effective only when ICANN fully implements a Consensus Policy establishing requester authentication. India therefore asks for the law-enforcement authentication mechanism to become operational promptly.

The letter is a legitimate statement of governmental policy preference. It is not a decision by the GNSO, an amendment to a registrar agreement or proof that any proposed intervention will work. Keeping those categories apart does not diminish the request. It tells readers which institution can act on it.

The reply draws an authority map

Lindqvist's 11 August reply, published the next day, accepts the security objective while declining to borrow authority from it. The distinction is unusually explicit.

The response points first to GAC consensus advice from ICANN83 and to the GNSO Council's DNS Abuse Mitigation PDP 1 on associated-domain checks. That is evidence that one narrow subject has entered a policy process. It is not evidence that pre-activation contact validation or centralized reporting has entered the same process. Associated-domain checks ask what a registrar should do about other domains connected to an account associated with an actionable abuse report. They are not a substitute name for India's first two proposals.

For registration-data verification and reporting transparency, the reply uses more limited language. ICANN org has identified them as matters warranting further consideration and understands that the GNSO Council is discussing them in its prioritization work. Those words establish attention. They do not establish rank, charter, working group, contract negotiation, recommendation or delivery date.

The reason is institutional, not merely procedural. ICANN's own policy page assigns development and recommendation of substantive gTLD policy to the GNSO. The GAC advises on government and public-policy concerns. The CEO can ensure that ICANN org supplies data and operational expertise and implements policies once adopted. He cannot set the GNSO Council's priorities or determine the result of a PDP.

That boundary protects both sides. A government does not acquire policy power merely because its concern is urgent. The GNSO cannot treat consultation as proof that the concern has been resolved. ICANN org cannot turn implementation support into policy authorship. Contracted parties receive a new binding duty only through the applicable policy or contractual path.

The public record shows three different states

The three requests can now be placed in a simple state table.

Requested measure Public state at 31 August Next authorized step visible in the checked record
Pre-activation email and phone validation Received, acknowledged and identified for further consideration and GNSO prioritization discussion No scheduled GNSO priority decision, charter, PDP or contractual step is identified
Mandatory and centralized DNS-abuse reporting Received, acknowledged and identified for further consideration and GNSO prioritization discussion No scheduled decision on a duty, data model, central mechanism or process is identified
Law-enforcement authentication for urgent requests Input group formed; meetings underway; proof-of-concept milestones published RDRS wireframe changes in October 2026, testing in December 2026 and findings in March 2027, followed by whatever valid policy action is required

This is not a ranking of substantive importance. It is a comparison of public process evidence.

The 13 August GNSO Council minutes reinforce the distinction. The Council was working through a charter-drafting process for DNS Abuse Mitigation PDP 2. Participants disagreed about scope, whether the questions presumed binding outcomes and which draft should be the starting point. Staff was to organize weekly drafting meetings from the week of 24 August.

Those minutes do not place India's first two requests inside PDP 2. They do record the GNSO-GAC liaison saying that questions about the registrant verification timeline at ICANN86 arrived too late for the Council to consult its groups adequately. That is valuable evidence of a communication state. It is not a policy disposition.

The minutes also state a constitutional point in practical terms. GAC input may travel through the liaison, but chartering remains a Council responsibility. The liaison said his role was not to advocate a GAC position before the Council unless the role itself were changed. Communication can carry an issue without transferring the power to decide it.

Dated work is still not policy

The authentication route is more developed. ICANN's public input-group page lists formation in June, meetings from July, presentation of RDRS wireframe changes in October, proof-of-concept testing in December and a findings summary in March 2027. Recordings for 22 July and 12 August are linked.

Yet the same page says the group is not a policy-development body. Its task is to provide operational and technical input. The page still lists a charter as “coming soon.” Those caveats matter because a working authentication prototype is not an adopted Consensus Policy. It can test identity-provider interoperability and workflow design. It cannot decide by itself who is legally entitled to data, whether a request is truly urgent, whether disclosure is necessary or how competing rights should be weighed.

This is why “has milestones” must not become “has been delivered.” The dated route is more accountable because it can be monitored. It is not more authoritative than the instrument that must eventually give it effect.

A receipt between acknowledgment and outcome

ICANN already publishes the letters. The missing record sits after publication. A reader should not have to reconstruct the status of each requested measure from a CEO reply, a policy page, Council minutes, an input-group page and several separate implementation notes.

A request-route receipt would remain deliberately narrow. It would record the exact requested outcome; the submitting body's authority class; the competent decision body; the current state; the governing process and public docket; the ICANN-org support owner; material dependencies; the next authorized act and date, or “not scheduled”; the latest evidence; and a correction trail.

Its most useful field would be a non-decision statement. “Acknowledged” would say that no priority has been assigned. “Under prioritization” would say that no charter or policy exists. “Chartering” would say that the questions do not determine their answers. “Proof of concept” would say that no binding obligation or entitlement has been created. “Implemented” would point to the instrument that authorizes enforcement.

The receipt should be per measure, not per letter. One letter can contain three requests with three competent actors, three dependencies and three clocks. A single status such as “engaging with India” conceals that structure.

This proposal also answers a common objection. Publishing a route does not let the requester set the outcome. It lets governments, contracted parties, civil society and other participants see which body actually owns the next decision. Delay becomes reviewable without being treated as consent to the requested policy.

Keep urgency and authority in the same record

India's concern is not answered by pointing only to process. ICANN's governance is not protected by treating urgency as a transfer of power. Both errors arise when the public record cannot show the path between them.

The 11 August reply gets the authority boundary right. The next accountability step is to expose the route states with equal precision. The public should be able to see that one request has dated technical milestones, two remain at consideration and prioritization, and none should be described as an adopted outcome before the competent process says so.

That is a thinner and more honest account of multistakeholder governance. Stakeholders provide evidence and demands. Advisory bodies advise. The GNSO decides how gTLD policy work proceeds. ICANN org supports and implements. Contracts and Consensus Policies carry obligations. A public receipt should show every handoff without pretending that attendance, correspondence or urgency created a mandate.

Sources

  1. ICANN correspondence index
  2. S. Krishnan to Kurt Erik Lindqvist, 14 July 2026
  3. Kurt Erik Lindqvist to S. Krishnan, 11 August 2026
  4. ICANN — Developing Policy at ICANN
  5. GNSO Council minutes, 13 August 2026
  6. ICANN — Input Group: Law Enforcement Agency Authentication Mechanisms
  7. GNSO — DNS Abuse Mitigation PDP 1
  8. ICANN — Registration Data Policy
  9. ICANN — 2013 Registrar Accreditation Agreement and Whois Accuracy Program Specification
  10. Lu Heng — The Multi-Stakeholder Mirage