Dear Colleagues,
The chairs have gotten a couple of requests, off-list and on, for a WGLC on draft-ietf-dnsop-alt-tld. We’ve reviewed the current draft closely and have some concerns that we feel need to be resolved before any effort to move the draft forward. (Suzanne wrote this but it’s been discussed among all of the co-chairs.) 1. As far as I can tell, this draft does not comply with RFC 6761. This is a problem for two reasons. First, this creates a process problem in that RFC 6761 is the standards-track document that specifies how the SUDN registry is to be administered, so a request that doesn’t meet the requirements in 6761 can’t (or at least shouldn’t) go into the registry. RFC 6761 section 4 asserts: The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied. The alt-tld draft ignores this MUST, without explanation (unless I missed it). The substantive issue is that the questions in Section 5 are there to make sure there’s a full description of the expected handling of a proposed name by the assorted components that take part in DNS operations and protocol. The draft answers at least some of the Section 5 questions, but the answers are largely implied. For example, the draft says that DNS resolvers seeing .alt names "do not need to look them up in the DNS context”, but a big part of the point of codifying these names is the assumption that queries will leak and DNS servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is simply not in the public DNS root zone and the root servers (or better yet, any intermediate resolver) should answer “name error”/NXDOMAIN for such queries. But this should probably be said explicitly, because people who configure DNS servers and services shouldn’t have to guess what’s being implied here. (The WG discussed the possibility that such queries should be blackholed and not answered at all, which is in some ways an obvious answer. Clarification of why this was discarded might also be helpful.) So, the current draft isn’t meeting the requirements for the registry, and also doesn’t clearly answer substantive questions about what DNS operators are expected to do. This makes me uncomfortable doing a WGLC without a new rev. It would be Rob Wilton’s call of course (as AD for this draft, substituting for Warren) but I’m really uneasy with a WGLC without those changes— they seem rather too large to punt for a post-WGLC version. 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the basis that having the IETF “recognize” (if only by recording) such pseudo-delegations may serve to attract unwanted attention to the IETF’s supposed recognition of alternate (non-DNS) namespaces as reservations of the namespace from the shared, common DNS root. We’re still being denounced in certain corners for .onion. It might be good to have a paragraph calling out specifically why .alt is not a delegation of a TLD from the DNS root by the IETF, even though it looks like one. (We didn’t invent this problem, because we didn’t make the decision that top-level domain labels should be used by other protocols in a way that led to confusion. But let’s not propagate it.) 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term “registered” differently than common usage. Judging from searches on RFC 6761 and RFC 8499, it’s ambiguous for DNS naming and resolution, and “registered” can definitely mean something different to a registry or registrar than it does to a DNS operator. To people who operate TLD registries, a name can be “registered” and still may or may not be delegated. (“Label” is defined in 8499, “register” and “delegate” are not.) And, in the reference to “TLD,” it feels strange to expand the acronym to “Top-level label” even if “label” is the right word for what you’re talking about. Thanks to the editors and the WG for considering these comments. Best, Suzanne (For the chairs)
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
