On 16 Nov 2023, at 11:20, Rod Rasmussen <rod@rodrasmussen.com> wrote:

Some input on the report from Lixia, with a promise of some more by early next week. I leave this to the WP leadership to determine how to incorporate, but I will thank her for taking the time to respond. She also suggested a conversation that might prove to be an interesting conversation, but isn’t required for us to finish this work.

Cheers,

Rod

Begin forwarded message:

From: Lixia Zhang <lixia@cs.ucla.edu>
Subject: Re: Invitation to review SSAC's current work on the evolution of DNS resolution
Date: November 15, 2023 at 10:09:47 PM PST
To: Rod Rasmussen <rod@rodrasmussen.com>
Cc: Eric Osterweil <eoster@gmu.edu>, Andrew McConachie <andrew.mcconachie@icann.org>

Hi Rod and others,

When I received this draft report, Nov 17 looked very far away, now just noticed that this review deadline is coming in 2 days!

I did read the report on the long flight back after Prague IETF, but yet to find time to put my thought in a structured way. I'm hosting the NDN project team retreat at UCLA for next 2 days. So let me do a quick compromise to partially meet Nov 17th deadline:
- I'm putting down a quick short partial list of bullets below (if just to show I read the draft:)
- I'll find time over weekend to build a full list of my points, hopefully in a better structured way, and hopefully together with more specific comments to the pdf.

Now a quick, short, partial list of points (personal opinion, take with a big grain of salt)

1/ the importance of name uniqueness: I feel this (most) important property of names could be emphasized a lot more than what's in the current draft.
Apps would not work correctly without unique names (at least unique within the usage scope of a name).
Most importantly, certificates are issued to names, i.e. Internet's security relies on unique names (maybe this point could be added to the draft)

The report focuses on Referential Integrity (Section 6) since name uniqueness isn't all that important of a property. For example, mDNS names are not unique. They may be locally unique, but they're certainly not globally unique. Also, even between naming systems name uniqueness isn't always wanted. This is why Microsoft tells admins to have the same name in DNS and Netbios refer to the same computer. GNS intentially doesn't care about uniqueness, which can be seen as either a feature or a bug depending on your opinion.

When we look at efforts to integrate ENS with DNS like what is being done in .ART or .XYZ, uniqueness is not a desired property. Like MS's documentation for DNS/Netbios, the .ART and .XYZ registries promote the same registrant for the DNS and ENS names. Usually we don't want uniqueness, what we usually want is the same name in different systems to refer to the same object.

Historically in the DNS uniqueness has presented some problems. See SAC057: SSAC Advisory on Internal Name Certificates. We don't want two different enterprises to get issued X.509 certs for server.corp. But when we're talking about the 'global DNS' this is not really a problem because we can anchor both internal namespaces in the global DNS root zone. There's a potential problem if someone gets an X.509 cert for example.xyz in DNS, but someone else has example.xyz in ENS. The way to resolve that problem is not to ensure that they are unique, but that they both refer to the same object. Not that we can of course, because there are no protocol police, but referential integrity still presents a better solution path than uniqueness.

2/ It seems to me important to separate out the concepts of namespace governance from name resolution.
DNS first defined a namespace, then how to allocate names on this space, and then provided its resolution system.

To assure name uniqueness, one either has a well defined *coordination* process to assure unique allocations, like the DNS system--it is not so much "centralized", but namespace governance by a democratic coordination process; otherwise one needs solutions for collision avoidance/detection/mitigation, a lot more difficult problems in global scale.

3/ Those "decentralization" name systems replaced coordinated allocation with either centralized control (e.g. ENS 7 people controlling ENS TLD allocations), or "consensus"-- it is consensus in quote, because those anonymous systems vote by resources (proof of work/stake/space), they hide not only who are voting, but more importantly there is no way to determine how many people are voting, a rich person can pretend to be 10, or 100.

The report avoids diving down the rabbit hole of how blockchain naming systems pretend to do governance. There's too much smoke and mirrors to know what's real versus what's marketing BS. Also, it's a moving target and will continually change as proponents come up with new smoke and mirrors to align with current fashions. These two aspects of blockchain governance make it incredibly difficult to research. I really hesitate to talk more about alternatve forms of namespace governance in this report because I don't know what I can believe, what is just lies, and what will change shortly after publication.

4/ Somewhere mid of the draft talked about some people want to change the governance of the DNS (really DNS namespace governance) to different name governance structures. I think we could add here how those different name governance structures do, or do not, assure name uniqueness.
Without coordinated allocations to assure uniqueness, these system need name collision detection solutions, and collision mitigation procedures. As Nick Weaver's report pointed out, none of them offers collision mitigation.

This is not possible as we point out in Section 4.1 "Crossing the Implicit Explicit Boundary". No naming system in use on the Internet can offer collision mitigation between another naming system because there is no possible mechanism for signalling resolution context in situ. It's a mess but there's nothing anyone can do about it.

5/ The executive summary mentioned that the alternative name systems copy DNS syntax, with a primary reason of benefiting from existing software: I feel a big reason here is that DNS names are semantically meaningful, that's why people/apps use them (Zooko triangle called "human memorable", memorable because they are meaningful)
BTW I dont buy Zooko triangle as the truth; wikipedia also lists a few counter examples https://en.wikipedia.org/wiki/Zooko%27s_triangle [en.wikipedia.org]

I disagree. DNS names are not always meaningful to humans. And there are many other syntaxes that could result in semantically meaningful identifiers. This doesn't explain why designers of alternative naming systems continue to use dot delineated labels and LDH. If we replaced the dot with another ASCII character their human semantic value would not change. Yet designers of alternative naming systems continue to use dot delineated labels and LDH because applications support them already.

6/ The summary also mentioned "New technologies such as QR codes and URL shorteners offer great utility to Internet users while also obscuring the underlying domain names used and creating new opportunities for bad behavior."
I need to think more about this: at IETF meetings (other cases may be similar), people use the QR code because they trust the QR code providers, so the trust on DNS name (now they can't see) is moved to trust the offers of QR code. One would not scan a QR code given by a total stranger, right?

Users regularly scan QR codes given by total strangers. I see QR codes on stickers posted on lamp posts and scan them for fun ;)

The primary use case for QR codes is Introduction. You are introducing a user to something new that they know little or nothing about. The user therefore knows little to nothing about the entity that deployed the QR code in their environment. Even in the use case of using QR codes for menu retrieval in restaurants; the user knows little about the restaurant, and their first interaction is directed by the QR code. In the case of a QR code on a business card the user knows even less about the proffered interaction, and when I'm scanning QR codes stuck to lamp posts I know absolutely nothing about the person who put it there.

That's for now, will try to finish before Monday (2 days over your deadline:)
I also feel a conversation might be more effective than email.

Lixia

_______________________________________________
SSAC-Evo-Reso-WP mailing list
SSAC-Evo-Reso-WP@icann.org
https://mm.icann.org/mailman/listinfo/ssac-evo-reso-wp

_______________________________________________
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.