On Tue, Dec 13, 2022 at 7:27 AM, Joe Abley <jabley@xxxxxxxxxxx> wrote:
Hi Ralph,
On Monday, December 12th, 2022 at 16:35, Ralph Droms <rdroms.
ietf@ > wrote:gmail. com As a reminder: https:/
/ datatracker. ietf. org/ doc/ html/ rfc8244 Dunno where the conversation has gone since publication of RFC8244
8244 opens with the premise that ICANN and IETF have nominal control over the "domain namespace" -- e.g. 8244's problems 1 through 4. "Domain namespace" is defined as "the set of all possible domain names."
I think neither ICANN nor the IETF have or should have control over the domain namespace; they only have control over that subset of the domain namespace that is used by IETF protocols like the DNS.
I think that the root issue is that there is not a simple way to determine if a name is included in "that subset of the domain namespace that is used by IETF protocols like the DNS". One can tell if a name is **currently** in the set of names that is in the union of the ICANN/IANA root zone and the SUDN registry. If someone starts using a name *currently not* in that set, but still following the semantics of the set (e.g .abley), it *potentially* makes that name unusable in the future in "that subset of the domain namespace that is used by IETF protocols like the DNS."
In an of itself that isn't necessarily an issue; there are 139098011710742195590974259094795403842655842142490330518716727403333474672708595090456576 possible "TLD" type names (26^63-26^2-26) — but if someone is widely using a name (e.g .onion) it will cause an issue *both to that user* as well as to the *DNS user* if the IETF or ICANN were to start using it for something else.
As a party trick, I will attempt to respond with text only from RFC 8244:
"There is a broad diversity of opinion about this set of problems.
Not every participant agrees that each of the problems enumerated in
this document is actually a problem. This document takes no position
on the relative validity of the various problems that have been
enumerated, nor on the organization responsible for addressing each
individual problem, if it is to be addressed. This document only
enumerates the problems, provides the reader with context for
thinking about them, and provides a context for future discussion of
solutions, regardless of whether such solutions may work for IETF,
ICANN, IANA, or some other group."
4. Although the IETF and ICANN nominally have authority over this
namespace, neither organization can enforce that authority over
any third party who wants to just start using a subset of the
namespace. **Such parties may observe that the IETF has never
asserted control or authority over what protocols are "allowed"
on the Internet, and that the principle of "permissionless
innovation" suggests there should be a way for people to include
new uses of domain names in new protocols and applications.** (emphasis added)
5. Organizations do in fact sometimes use subsets of the Domain
Namespace without following established processes. Reasons a
third party might do this include:
1. [...]
2. [...]
3. [...]
4. [...]
5. [...]
6. Lack of knowledge that a name intended to be used only
locally may nevertheless leak.
7. Lack of knowledge that a name used locally with informal
allocation may subsequently be allocated formally, creating
operational problems.
6. There is demand for more than one name resolution protocol for
domain names. Domain names contain no metadata to indicate
which protocol to use to resolve them. Domain name resolution
APIs do not provide a way to specify which protocol to use.
9. There is strong resistance within the IETF to assigning domain
names to resolution systems outside of the DNS, for a variety of
reasons:
1. It requires a mechanism for identifying which set of
resolution processes is required in order to resolve a
particular name.
2. [...]
3. More than one name resolution protocol is bad, in the sense
that a single protocol is less complicated to implement and
deploy.
4. The semantics of alternative resolution protocols may differ
from the DNS protocol; DNS has the concept of RRtypes,
whereas other protocols may not support RRtypes or may
support some entirely different data structuring mechanism.
20. RFC 6761 uses the term "domain name" to describe the thing for
which special uses are registered. This creates a great deal of
confusion because some readers take "domain name" to imply the
use of the DNS protocol.
There is a point, I believe, at which the IETF should step aside and avoid trying to nanny the designers of other parts of the namespace. Many (maybe most) of the problems identified in 8244 are consequences of not acknowleding such a threshold of care.
I don't think that it the IETF is attempting to "nanny the designers of other parts of the namespace", but rather acknowledge that "we have a shared commons; use of the commons should be coordinated so that we don't step on each other's toes". Permissionless innovation is a good thing. I don't think that anyone (well, anyone who has ever tried to actually operate it :-)) believes that the DNS is perfect and that something better might not be created — but I think that most of us agree that uncoordinated stomping on each other is not a great outcome.
Rereading RFC8244, there are places where we could probably have worded some of this better - it does have the "The IETF and ICANN are in charge of *anything* that can be expressed in LDH syntax" vibe…
W
I do agree that narrative around all of this suffers a discontinuity if the points described in 8244 aren't carefully considered as part of any new proposal to scope the limits of the IETF's responsibility.
Joe
