On Sun, Oct 02, 2022 at 10:32 PM, Paul Wouters <p...@nohats.ca> wrote:
> 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. > Just for clarification, "this topic" was the larger issues around RFC6761 / Namespaces and writing a follow up document to *RFC8244 - "Special-Use Domain Names Problem Statement"* <https://datatracker.ietf.org/doc/RFC8244/>. Paul raised this topic as, in his view, this topic is taking up too much DNSOP time. The IESG concluded that those willing to resolve the 6761 issues should > conduct a side meeting at IETF 115 and consider further steps. > Yes, it was suggested that someone may want to form a side meeting - I personally would not have worded it as “The IESG concluded that…” As the chairs’ email also said: “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.” A side meeting to discuss the followup to RFC8244 may provide some energy to work on the problem. > > I also believe a side meeting and possibly a bof and working group > dedicated to this work would be better. > It is very unclear that a different WG would attract sufficient mass - yes, many people in DNSOP are tired of this topic, but it is clearly an important topic (and in the DNSOP charter), and moving it off to a group where it doesn’t get the required review is not helpful. Warren (DNSOP AD) 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" > <https://datatracker.ietf.org/doc/RFC8244/>. > > > > 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") > <https://datatracker.ietf.org/doc/RFC2860/> 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> > 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> > 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: > > > > > > 1. 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). > 2. 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 > <https://www.icann.org/en/system/files/files/sac-113-en.pdf>), and > related issues if necessary. > 3. 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. > 4. 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
