On Oct 2, 2022, at 22:33, Paul Wouters <p...@nohats.ca> wrote: > > Speaking as AD,
I should clarify, as an AD. Not the AD for DNSOP. Paul > > 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
