Re: [DNSOP] draft-ietf-dnsop-alt-tld-19

[Paul Wouters <[e-mail]>]

On Thu, 15 Dec 2022, Martin Schanzenbach wrote:

> I am not looking for that. What I said that what this sentence
> insinuates is that as a developer I am "wholly responsible" for dealing
> with collisions that may occur.

> Maybe it is because English is my 2nd language but this rubs me the
> wrong way.

Oh, I think perhaps there is a language issue here. I read "wholly responsible"
as "the person whose actions caused this". Eg by choosing a name within
a namespace that offers no uniqueness / sole ownership of entries under
it.

I don't interpret it as "the person responsible for fixing the
conflict". I think if one opts to use a name under .alt, one has to
engineer in how to deal with conflicts in that namespace. It is a
fundamental feature/bug of it.

> That being said I am not even sure if the path you point to (getting a
> TLD)

I did not say you could easilly get a TLD. Also, when using .alt, you
are not (expected) to use the entire .alt and clash with every other
.alt user doing the same. It is expected you pick a subdomain under .alt.

So then the equivalent under the DNS would be like "a subdomain in a
TLD". That is surely easilly achievable. But not in the short string
you would like. And with 8 billion people, unfortunately short strings
have been delegated in a way that helps most people, but cannot satisfy
everyone.

> But if it is, then maybe I can modify my point: IF it is the
> sole responsibility of the developer to do that, at least give some
> examples/hint on what I could do.

If you want to prevent collisions, you need to join the scheme where
people agree not to collide - such as the namespace served by DNS.

> If it is just that the draft considers this issue out of scope but wants
> to mention it then say that, maybe in the security considerations.

I do think it is out of scope, and I don't think it belongs in the
security considerations for .alt. The IETF cannot give security
considerations for the use of .alt, as it is not governed by IETF
protocols or agreements.

Paul