> On 2. Aug 2022, at 14:39, Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote:
> 
> On 02/08/2022 13.53, Martin Schanzenbach wrote:
>> This is not an oversight (altough I have to admin it did not occur to me
>> that this a valid DNS TLD at the time of writing).  [...]
>> 
> Oh, I understood that this DNSOP thread - notably the first post - originated 
> as an attempt to reduce collisions between GNS pet names and DNS names.  
> Probably by standardizing .alt (or similar) as special in DNS and encouraging 
> that GNS pet names nest under it.
> 
> If I got this wrong, I suspect it might be helpful to restate the 
> DNSOP-related intentions more clearly.
> 

You understand correctly and maybe my comments are a bit too exaggerated at 
times.

The draft as it exists now has obvious collisions with the DNS namespace. A 
direct result from our previous efforts wrt RFC6761; there is just no 
sub-namespace to use for us. (See discussions years ago)
So, we mostly separated the technical protocol design from the namespace issue.
This (understandably) lead to discussions with the ISE (and others) and now 
also to (possible) issues in the IESG conflict review as part of our 
independent submission.
The idea was to connect with dnsop in order to establish if the ".alt"-draft 
could help here.
If there was a consensus over the ".alt" draft or other guidance on how to 
specify alternate name systems (and their namespaces), then I would assume this 
would affect the considerations of the conflict review and potentially require 
us to modify the draft accordingly.
Which is why we consulted with ISE whether it makes sense to participate in 
this discussion and possibly offer draft-schanzen-gns as a possible first 
"customer" of a potential new ".alt"-RFC.
So, you probably need to differentiate between the GNS draft as it is defined 
now and how it could potentially look like.
I think this is also why ISE said in another post that it may be wise to 
consider this as an opportunity to settle this issue. However, it seems quite 
entrenched.

BR
Martin

> --Vladimir | knot-resolver.cz
> 

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to