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 )
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
