[DNSOP] Requesting adoption: draft-davies-internal-tld - "A Top-level Domain for Private Use"

[Warren Kumari <[e-mail]>]

Dear DNSOP-Chairs,

The authors of draft-davies-internal-tld - "A Top-level Domain for Private
Use" <https://datatracker.ietf.org/doc/draft-davies-internal-tld/> would
like to request a call for adoption for this document.

I had swapped out all state, and had to go search to swap it in again. Here
are helpful resources to save y'all having to search too:
It was presented at the DNSOP meetings at IETF 121 ([0]) and IETF 122
([1]).
Video from IETF 122: https://youtu.be/CbEVXo07KS8?t=4619
IETF 122 DNSOP Minutes:
https://datatracker.ietf.org/meeting/122/materials/minutes-122-dnsop-00


Some notes / questions from the meeting (potentially over-summarized!):

1: It was suggested (Ted Lemon) that the name should also be listed in the
Locally-Served Zones registry -
https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml
W: This sounds like a perfectly fine suggestion to me, but obviously would
require more discussion with the WG. Also see #4 below.

2: Tommy isn't willing to die on this hill, but suggests considering "MAY"
for allowing resolution libraries to treat this specially (S 5.1, Q3),
because they might have more knowledge.
W: This also sounds like a reasonable suggestion to me, but will require
more text. I'd copied the "7 questions" from RFC6761 S6.1 (reservations for
in-addr.arpa) and made the bare minimum of edits (as suggested by Petr).

3: Stuart Cheshire (author of RFC6761) agrees that this falls within the
anticipated use of the RFC6761  SUDN registry.

4: Jim Reid doesn't think that DNSOP should work on this — ICANN reserved
the string, so they should add it to a registry (very paraphrased).
W: I do not believe that there is a process for ICANN to add this to the
registry, other than by writing an Internet Draft, and having it go through
the regular process.
The ICANN board did "recommends that efforts be undertaken to raise
awareness of its reservation for this purpose through the organization's
technical outreach.”[2]. One author of the document works for ICANN, and
another works for the IANA, so it looks like this is what is happening.
Also, the document does more than just stuff it in a registry - it provides
guidance on how to use the string.

5: Mark Andrews: The Locally Served Zones registry requires that there is
an insecure delegation in the root zone. This is also needed to make the
zone actually work with DNSSEC…
W: I'm not at all sure that the first sentence is true - or, at least I
don't really see why it follows.
I *do* however fully agree that there really should be an insecure
delegation in order to make DNSSEC work, but unfortunately the SSAC
document[3] which asked for this says: "Recommendation 1: The SSAC
recommends that the ICANN Board ensure a string is identified using the
criteria specified in Section 4.1 and reserved at the top level for private
use. This particular string must never be delegated."


W


[0]: Slides:
https://datatracker.ietf.org/meeting/121/materials/slides-121-dnsop-sessb-internal-00.pdf
[1]: Slides:
https://datatracker.ietf.org/meeting/122/materials/slides-122-dnsop-sessa-draft-davies-internal-tld-a-top-level-domain-for-private-use-00
[2]:
https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-special-meeting-of-the-icann-board-29-07-2024-en
[3]: SAC113 - SSAC Advisory on Private-Use TLDs (
https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf
)