Re: [DNSOP] Possible alt-tld last call?

["Rob Wilton (rwilton)" <[e-mail]>]

Hi WG & chairs,

I’m chiming in on this thread with a “responsible AD for the alt-tld draft” hat on.

The reason for my interjection is only because I’ve seen some comments stating that this topic is too hard, we can’t get rough consensus, and hence the WG should give up and declare defeat.  However, from my reading of the thread, I’m not convinced that the WG is necessarily that far away from rough consensus, particularly on the significant (i.e., most important) parts of the draft.  Nor, if the WG declares failure, do I see a better path forward.

I will inject a disclaimer here, that I don’t know that much of the history regarding special use domain names.  I can entirely understand that they are generally icky, and probably not what DNSOP WG wants to spend its time and energies on and have caused previous unfruitful discussions.  I also appreciate that DNSOP WG is more interested in ensuring DNS works properly rather than building, encouraging, or sanctioning entirely alternative naming schemes.  This is all fine and not surprising.

However, there are clearly some organizations that are interested in exploring alternative name services.  In an ideal world we might like these namespaces to be entirely separate from the DNS, but from an end-user perspective I can see how these things can easily get muddled.  As such, I see the alt-tld document as potentially being helpful, particularly for the proponents of proposals such as GDS, where my interpretation is that they are trying to do the right thing, and they are also trying to play nice with the existing DNS infra.

A few comments on specific aspects of this document:


  1.  I think that we should leave considerations of what to do with RFC 6761bis entirely outside the considerations for this draft.  RFC 6761bis seems like a bigger, harder problem to solve problem, than this draft.  As the chairs have suggested, I think that the alt-tld document should probably include the necessary text to conform to RFC 6761, even if it that text isn’t particularly useful. My suggestion would be to put such text in an appendix.

  2.  I think that the WG should put aside concerns about ICANN.  My instinct, from reading some of the previous recent liaison statements between the IETF and ICANN is that what is proposed in this draft is within scope of the IETF’s remit.  However, assuming that we can get to WG rough consensus, i.e., past WGLC, then I would propose that we send a liaison statement to ICANN, highlighting this draft, and asking them if they have concerns or comments with the IETF progressing this document.  I would take on board the reply to that liaison in determining whether and how to progress the document.

  3.  Some participants have indicated that they don’t support this document because they don’t think that it will end up being useful (principally because the other naming systems may still squat on TLDs anyway), but that they are also not opposed to publishing this document because they also see that it won’t cause harm either.  I regard these views as being within rough consensus of publishing this document.

  4.  The main remaining point of contention that I see, is whether IANA should maintain a registry of protocols under .alt, and if it does, whether the entries in the registry must be “unique”, what registration policy should be applied, and if there are any legal implications on the IETF or IANA on maintaining such a registry.  I have two comments on this:
(i) I think that it is reasonable for the WG to defer the issue of whether maintaining such a registry could cause wider problems for the IETF/IANA to both IANA and the IESG, which would naturally happen at IETF LC + IESG review time anyway.  The WG’s concern with the registry would be flagged in the shepherd’s writeup, and as responsible AD for the document, I would also explicitly flag the WG’s concern to the rest of the IESG for consideration during IESG review.  Finally, the IESG have the option of consulting with legal counsel if needed. If we go ahead with the registry, and it turns out to be a problem in practice, then we always have the option of refining the registry rules, or even deprecating the registry entirely.  I.e., nothing is set in stone.
(ii) As has been noted by others, there is always the fallback option of not having any IETF/IANA managed registry for protocols under .alt at all.  Even without the registry, I still think that the rest of the document is potentially useful, and not harmful.  I.e., specifically, if we are unable to get consensus on the registry then I believe that it would be better to publish the document without the registry than not publish at all.


Without any hats, I have some specific suggestions on the text in section 3.2, “Non-DNS Protocols Using the .alt Pseudo-TLD Registry” on version -17.


  1.  The description of the registry could perhaps be more explicit that the registry (i) does not indicate any IETF endorsement of entries in the registry or the referenced specifications (although I think that this is probably generally a given for IANA registries anyway), and (ii) nor does the registry make any guarantees that it is necessary complete.
  2.  I would recommend a registration policy of “Specification required”.  Specifically, the definition of specification required automatically includes expert review, and RFC 8126 already allows appeals to the IESG/IAB for rejected registrations.
  3.  There should be documented guidelines of what the expert review part of the “Specification Required” policy should entail:
     *   The specification needs to be for a name resolution system and be documented in a stable reference (as per RFC 8126).
     *   The expert reviewer may, but is not required, validate the quality or correctness of the specification.  The expert reviewer may reject requests where the specification is insufficient.
     *   Name resolution protocols are expected to only require a single entry, or otherwise a very small number of unique entries, directly under .alt.
     *   Name resolution protocols SHOULD choose a unique name under .alt, but the expert reviewer MAY allow multiple entries under .alt in exceptional circumstances.

Proposed next steps (for authors, WG, and WG chairs to consider):

I think that it would be helpful for the authors to post an updated version of the draft aiming to incorporate the feedback that has been received recently.

I also suggest that it would be helpful to have discussion this draft in DNSOPS in IETF 115, if there is time available.  It is up to the authors & WG chairs, but it may be useful to do a hum or “show of hands” on test consensus (specifically if anyone can’t live with) on the proposals for: 4(i), and 4(iii) above.

I am, of course, happy to receive comments from the DNSOP WG (or chairs, or authors) on the mailing list on any aspect of my comments above, either stating that the proposals are awful/misguided/wrong/etc, or that they could be an acceptable way forward.  But I would really appreciate it if we can try and compromise a little to find a way forward.

Kind regards,
Rob


From: DNSOP <[e-mail]> On Behalf Of Suzanne Woolf
Sent: 16 October 2022 16:03
To: [e-mail]
Cc: Rob Wilton (rwilton) <[e-mail]>; DNSOP-Chairs Chairs <[e-mail]>
Subject: [DNSOP] Possible alt-tld last call?

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)