Versions Compared

Old Version 1

changes.mady.by.user Hope Shafer

Saved on

compared with

New Version Current

changes.mady.by.user Charla K. Shambley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

SAC123 SAC122 was published on 20 12 Dec 2023. All SSAC publications can be found at https://www.icann.org/en/ssac/publications.


View file
namesac-123122-en.pdf
pageSAC122: SSAC Report on Urgent Requests in the gTLD Registration Data Policye Resolution
spaceBA
height400


New technologies are changing how name resolution happens on the Internet. The DNS remains the prominent, or default, naming system for the Internet, but alternative naming systems are in use as well. This is nothing particularly new, as there have always been naming systems besides the DNS in use throughout the Internet’s history. These alternative naming systems use the same syntax as the DNS, dot-separated labels. There are many motivations for copying this syntax, but the primary reason is because designers of these alternative naming systems wish to benefit from the existence of software applications built to receive DNS names as input.
This has the potential to create situations where the same name exists in DNS and in an alternative system, potentially causing name collisions. However, there is only one domain namespace and its referential integrity is important for Internet users and for the stability and security of Internet names. Thus, as alternative naming systems increase in popularity their use threatens to increase ambiguity in the shared single domain namespace. This increased ambiguity in Internet naming threatens to undermine the trust that users have in Internet identifiers and the services that rely on them.Phase 2 | Understand
Recommendation DescriptionCurrent Phase
Recommendation 1

The policy must provide additional structure so that Urgent Requests will be handled in an appropriately expedited fashion.

Specifically, the SSAC recommends that the required structure must include at least the following elements:

  • a. Registrar's and Registry Operator's published mechanism and process must state that Reasonable Requests for Lawful Disclosure and Urgent Requests for Lawful Disclosure are different, and must allow Urgent Requests to be identified as such by a requestor.
  • b. When a requestor submits an Urgent Request, Registrar and Registry Operator must provide an acknowledgment of receipt within 30 minutes. This acknowledgment is separate from the "response" to the disclosure request described in paragraph 10.7.
  • c. Paragraph 10.7.2 must specify that Responses to all Disclosure Requests must be in writing by email to the requestor. A written response is necessary for the information of the Requestor, and for compliance purposes. The requirement for written responses is not intended to prohibit other communication from occurring (e.g., if ongoing telephonic communication is conducted in parallel to the writing of the email response), so long as the written response is also provided.

Status
colourGreen
titleCLOSED

Recommendation 2

The policy must ensure that response times for handling Urgent Requests be fit for purpose.

Specifically, the SSAC recommends that the required response time must have at least the following characteristics:

  • a. Urgent Requests are a matter of imminent danger. The language of the policy should reflect that responses are to be fulfilled as soon as possible, with urgency befitting the situation.
  • b. Paragraphs 10.6.1 and 10.6.2 provide time extensions that are not fit for purpose, and these paragraphs should be deleted. No legitimate Urgent Request should be responded to in more than 24 hours.
  • c. In paragraph 10.6, the word "generally" is imprecise and confusing and should be deleted.

Status
colourGreen
titleCLOSED

Recommendation 3

ICANN org should acquire and document data regarding Urgent Requests and make high-level information available to the community for future consideration.

Specifically, the SSAC recommends the data made available to the community must include at least the following metrics:

  • a. Number of Urgent Requests received at registrars and registry operators;
  • b. Expediency with which Urgent Requests were reviewed, evaluated, and handled;
  • c. Percentage of Urgent Requests classified as spam, not urgent, or otherwise invalid; d. Counts of requests handled and not handled within the contractual requirements (i.e., compliance statistics). The data collected must be comprehensive enough for ICANN org to examine a registrar or registry operator’s handling of Urgent Requests for compliance purposes.
Status
colourGreen
titleCLOSED