Re: [Rfc6761bis] New Non-WG Mailing List: rfc6761bis

[Warren Kumari <[e-mail]>]

On Tue, Dec 13, 2022 at 7:27 AM, Joe Abley <[e-mail]> wrote:

> Hi Ralph,
>
> On Monday, December 12th, 2022 at 16:35, Ralph Droms <rdroms.ietf@gmail.
> com> wrote:
>
> 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
>