Speaking as AD, This topic came up at the last IESG telechat, partially in response to Paul Hoffman’s https://datatracker.ietf.org/doc/draft-hoffman-rfc6761bis/ and my concerns about the infinite amount of time this issue has cost and is still costing dnsop at the expense of protocol work.
The IESG concluded that those willing to resolve the 6761 issues should conduct a side meeting at IETF 115 and consider further steps. I also believe a side meeting and possibly a bof and working group dedicated to this work would be better. At least that way, DNSOP can continue doing DNS protocol work. Reviving it for another round in dnsop seems wrong. Paul Wouters > > On Oct 2, 2022, at 20:56, Suzanne Woolf <swo...@pir.org> wrote: > > > Dear colleagues, > > The chairs have been working for some time on a plan to address the ongoing > issues around special use domain names (described in RFC 6761) and the domain > namespace. These issues are described in RFC8244 - "Special-Use Domain Names > Problem Statement". > > WHAT, THIS AGAIN? > > (TL;DR: skip to “WHAT NOW?” below.) > > First what we need: a plan for the WG that will ensure, as best we can, that > the WG has weighed in on domain namespace issues that affect the integrity > and usefulness of the DNS, without getting entangled in issues that belong to > other bodies (or to the users and developers of the Internet more generally). > As our charter says, we agreed to “Publish documents that attempt to better > define the overlapping area among the public DNS root, DNS-like names as used > in local or restricted naming scopes, and the 'special names' registry that > IETF manages, perhaps including how they might interact. This work must take > into consideration issues that are strictly beyond the operation of the DNS > itself, and the working group will consult with IETF liaisons to other > organizations as appropriate.” (This language dates back to at least 2014.) > > Why we need it: In addition to the commitment to the community from our > charter, this area has continued to provide new drafts, new concerns, and new > questions. As painful as it may be to attempt to deal with them, it does seem > better for the WG to try than to ignore the questions and hope they’ll go > away. At the very least, the IETF needs some guidance on how protocols > developed within the IETF can implement special use names. > > There is no requirement that a special use domain name be a single-label (or > “TLD”) name, but as they have significant policy issues (as noted in RFC2860 > - "Memorandum of Understanding Concerning the Technical Work of the Internet > Assigned Numbers Authority") they generate the most discussion and get the > most attention. > > The primary value of the DNS protocol and naming conventions is serving as a > useful and interoperable default for Internet naming. Ambiguity for > applications in how to resolve domain names undermines interoperability > across the namespace. The risks include not only explicit collisions but also > a general erosion of confidence. > > Protecting the usefulness of the DNS may require some kind of coordination > mechanism so that future developers can avoid ambiguity of resolution for > Internet names. > > RFC 6761 establishes a registry for special use names, but its direct > guidance on how to determine a name is appropriate to treat as “special use” > is unscalable and potentially incomplete. At one point we had six or seven > different drafts, requesting a total of more than 40 single-label names, > submitted for adoption by the WG, and any one of them seemed likely to result > in controversy. > > The .onion case (RFC 7686) was resolved by making the draft a standards-track > work item in the WG, but this exposed the difficulty in applying RFC 6761 as > written. As the IETF Chair wrote about the .onion special use registration, > “However, subsequent to this action, the IESG believes RFC 6761 needs action, > and substantial community input. It needs to be open for review and > modification because the current process is unscalable. Several other names > had also been submitted for consideration as special names, and the RFC may > not give adequate guidance about when names should be identified as special > names. Special names should also be, as the name implies – special and rare. > The DNSOP working group is chartered to address this RFC 6761 review.” > (https://www.ietf.org/blog/onion/) > > We paused consideration of additional special-use names drafts until we could > tackle an update to RFC 6761. RFC 8244 provided a survey of issues that had > come up; however, attempts to address those issues haven’t been supported by > the WG. > > We understand that some WG participants are certain that anything touching on > the use or the integrity of the domain namespace is ICANN’s problem and not > the IETF’s. However, neither the IESG, nor the IAB, nor ICANN seem to agree > (see > https://www.icann.org/en/system/files/correspondence/marby-to-cooper-kuhlewind-22oct20-en.pdf, > from the CEO of ICANN, and the reply from the IETF chair and IAB chair at > https://www.icann.org/en/system/files/correspondence/cooper-kuhlewind-to-marby-12nov20-en.pdf). > This correspondence leaves details undefined (which seems entirely > appropriate) but both parties explicitly state they see the domain namespace > as a shared responsibility. When ICANN received a recommendation involving a > reserved name for private use from an internal technical advisory body, they > reached out to the IETF for its views. This is a normal use of the liaison > relationship the IETF and ICANN instituted more than 15 years ago. > > > NOW WHAT? > > For the above reasons, it seems we have to make a final (we believe) attempt > to engage on special use naming issues. We propose: > > The alt-tld draft was parked some time ago, primarily because it stood alone > as an attempt to reserve a potential DNS TLD without either WG consensus on a > few issues, or any prospect of the WG taking up an update to RFC 6761. > However, it also hasn’t gone away, and recent discussion appears to provide a > specific problem it could solve. We propose to revive it and invite > discussion, subject to the constraints above (primarily, that it doesn’t seem > to us we can continue to argue about whether it’s part of the remit of DNSOP > or the IETF). > The correspondence referenced above suggests that the IETF’s liaison > relationship with ICANN could be used to coordinate guidance on the use of > .alt, any names ICANN wants to reserve as advised in SAC113 > (https://www.icann.org/en/system/files/files/sac-113-en.pdf), and related > issues if necessary. > At least twice in the last few years we’ve made attempts to update RFC6761 > with guidance for the IETF, and potentially others, on how to safely > incorporate special use names into their protocols when necessary. These too > have gotten bogged down in discussions of whether we should be doing such > work at all, but (as above) it seems clear there’s a use case for it. > We’re well aware not everyone is interested in this work and that the WG has > a chronic issue of a full pipeline of documents to consider. We’ll separate > special use names work from other WG activities as much as we can. > > > > Suzanne, Tim, and Benno > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
