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 <dnsop-boun...@ietf.org> On Behalf Of Suzanne Woolf
Sent: 16 October 2022 16:03
To: dnsop@ietf.org
Cc: Rob Wilton (rwilton) <rwil...@cisco.com>; DNSOP-Chairs Chairs
<dnsop-cha...@ietf.org>
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)
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
