On 8/7/2022 9:17 PM, George Michaelson wrote:
Not trying to say you're wrong,

I just observe that if there is an omnibar, and people type names into
it, then there is a latent problem of ordering lookup, and deciding,
in names and more than one namespace. Pretty much all the hard stuff
stems from there IMO.

Names are hard. I think belief in the value of a unitary namespace as
a commons probably always transcended the DNS specifically. We're just
in denial what "it" is that we're fighting to defend.  DNSSEC made
this perhaps more focally clear: the specific value here is (in my
opinion) in "which TA do you respect" and how that goes to "which name
do you believe" which in this case goes to "which namespace do you
prefer, deciding which names to accept"

The name space is "almost" unitary. People deploy things like domain suffix search lists so that users can type "mailserver" and arrive at "mailserver.corp.example.com" -- or something else, depending where they started for. Which, if you squint really hard, is not all that different from the "pet names" scenario.

The unitary namespace belief, goes pretty rapidly to "how many
distinct, independently managed TA do you want to respect proving
names" as a cross product with "when, in which order, and why, and
what do you do if they collide or disagree"

If GNS is glued into DNS as a sub-arc over a label we understand, the
possibility of some unity, fusion of purpose exists. If it squats, or
is pushed aside, then that possibility disappears.

To me, thats the problem. Not that we're finding this is ugly, or we
like or dislike a reserved label like this, or want to never invoke
the method we documented to do this thing, or hate ICANN or a hundred
other things: its the loss of fusion of behaviour, if we don't come to
some sense of agreement in what names are, respecting locators (and
addresses)

If users could be trained to type "!example.pet" or "..example.pet" to explicitly require resolution of a GNS name, then John's proposal would work. I am not sure that this can such training would work. I observe that when DNS and NetBIOS were used in parallel, the same hostname was typically used in both cases. It would have been good if users could be trained to type "mailserver.corp.example.com" instead of "MAILSERVER", but such evolution took a very long time.

Now, it may well be that training users to type "example.pet.arpa" or "example.test" is just as hard. Design proper user interactions is hard. I would much rather let the GNS developers make these decisions rather than have the IETF try to engineer user interactions on their behalf. If they have concluded that they just need a name suffix, I think we should take that at face value.

But then, the GNS interaction design should also be based on reality, i.e., a world in which the RFC 6761 process is not available.

-- Christian Huitema

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to