Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Paul Hoffman]

On Aug 3, 2022, at 8:09 AM, Schanzenbach, Martin  
wrote:

> https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00
> does not seem to be a predecessor of
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

You are correct; this was my mistake. draft-wkumari-dnsop-internal is a 
document that was written around the same time as draft-wkumari-dnsop-alt-tld 
(five years ago). 

> I do not understand what you are trying to tell me?

That reading expired five-year-old drafts, written by an individual, is not 
helpful in this conversation. What is helpful is for you to read the current 
draft  and possibly 
the relevant SSAC document 
.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

> On 3. Aug 2022, at 16:46, Paul Hoffman  wrote:
> 
> On Aug 3, 2022, at 12:36 AM, Schanzenbach, Martin  
> wrote:
>> 
>> Having now read further I am pretty convinced that the advisory is not 
>> useful in the context of this thread discussion.
>> Ist sais at the end that [1] was the "impetus" for the advisory.
> 
> Reading a five-year old version of a draft is not a good way to determine the 
> current state of thinking. You should only be looking at the current version 
> of the WG document: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/
> 

https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00
does not seem to be a predecessor of
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

On the contrary, the first references the second and confirms my analysis:

"
 The [I-D.ietf-dnsop-alt-tld] document reserves a string to be used as
   a pseudo-TLD for non-DNS resolution contexts.  However, it is clear
   that there is a significant use case for a similar string to be used
   for namespaces which are resolved using the DNS protocol, but which
   do not have a meaning in the global DNS context.
"

I do not understand what you are trying to tell me?

BR

> --Paul Hoffman
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Paul Hoffman]

On Aug 3, 2022, at 12:36 AM, Schanzenbach, Martin  
wrote:
> 
> Having now read further I am pretty convinced that the advisory is not useful 
> in the context of this thread discussion.
> Ist sais at the end that [1] was the "impetus" for the advisory.

Reading a five-year old version of a draft is not a good way to determine the 
current state of thinking. You should only be looking at the current version of 
the WG document: https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Schanzenbach, Martin]

Having now read further I am pretty convinced that the advisory is not useful 
in the context of this thread discussion.
Ist sais at the end that [1] was the "impetus" for the advisory.
However, [1] states that

"Why not use .alt?
   The proposed .alt presudo-TLD is specifically only for use as a
   pseudo-TLD for non-DNS resolution contexts.  At one point .alt was
   being considered both for DNS and non-DNS resolution contexts, but,
   after much discussion it was decided that the DNSSEC implications
   (and desired behavior) meant that .alt should be reserved
   specifically for non-DNS resolution."

and

"
Why not use something.arpa?
   This is indeed an interesting idea.  I suspect that it fails the
   semantically desirable / understandable case, but is definitely worth
   further discussion.  It may also cause issues when server operators
   override part of the .arpa domain in order to instantiate
   something.arpa.
"

So, I am pretty sure we are back to square one and this advisory (or rather its 
result) is specifically NOT meant for systems like GNS.
In fact, I would even argue that the advisory itself argues that this work is 
supposed to be done by IETF (see page 5 of the document):
"
In this document, the SSAC limits its discussion to private-use TLDs intended 
for use with the DNS protocol and for private use only. Many private-use TLDs, 
such as .onion and .gnu, do not use the DNS protocol or DNS infrastructure. The 
reservation and usage for such TLDs would require special handling and is not 
discussed in this document; there have been efforts in the IETF to address them.
"

While I must admit that I am a bit ignorant when it comes to what is considered 
official ICANN position, at least the authors of this advisory seem to think 
that private TLDs not meant for DNS resolution should be/can be/are(!) worked 
on by the IETF.

[1] 
https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00#section-3

BR

> On 2. Aug 2022, at 22:09, Martin Schanzenbach  wrote:
> 
> Signed PGP part
> I just read it and on page 5 it specifically excludes .onion and .gnu as
> those do not use the DNS protocol (citing also the alt draft here).
> So this is equivalent to the .alt draft only if the private-use TLD is
> not limited to private-use DNS queries as investigated in the document.
> I find this to be quite odd as I thought this is what .arpa was for
> (RFC8375)!
> .home is even listed in the table of the SAC document and one of the
> motivations.
> 
> So, we would have to see what the actual proposed *use* of this private
> TLD would be. If it is limited to DNS, then it is of no use for
> alternative name systems and we would still need .alt.
> 
> Excerpts from Andrew Sullivan's message of 2022-08-02 15:34:40 -0400:
>> Disclaimer: I work for the Internet Society but I am not speaking for them.
>> 
>> On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:
>>> 
>>> recommends that the ICANN board to pick a string that will never be put 
>>> into the DNS root, and thus is usable for systems like GNS.
>> 
>> This was, of course, the whole point of the .alt draft in the first place, 
>> at least when I was involved in preparing it.  I don't think any of us 
>> involved then cared whether it was alt or one of thousands of other strings 
>> that it could have been.  The main point was to come up with something that 
>> would not pad total length too much and that could be a clear "protocol 
>> switch".  The registration in the IANA sutld registry was suppossed to 
>> ensure the same outcome as what is going through SSAC, but it makes no 
>> difference to me what the characters are.  Note that because of the 
>> old-timey restriction, I suspect the characters must all be alphabetic, 
>> though perhaps that rule has been superseded by IDNA.
>> 
>> A
>> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Martin Schanzenbach]

I just read it and on page 5 it specifically excludes .onion and .gnu as
those do not use the DNS protocol (citing also the alt draft here).
So this is equivalent to the .alt draft only if the private-use TLD is
not limited to private-use DNS queries as investigated in the document.
I find this to be quite odd as I thought this is what .arpa was for
(RFC8375)!
.home is even listed in the table of the SAC document and one of the
motivations.

So, we would have to see what the actual proposed *use* of this private
TLD would be. If it is limited to DNS, then it is of no use for
alternative name systems and we would still need .alt.

Excerpts from Andrew Sullivan's message of 2022-08-02 15:34:40 -0400:
> Disclaimer: I work for the Internet Society but I am not speaking for them.
> 
> On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:
> >
> >recommends that the ICANN board to pick a string that will never be put into 
> >the DNS root, and thus is usable for systems like GNS.
> 
> This was, of course, the whole point of the .alt draft in the first place, at 
> least when I was involved in preparing it.  I don't think any of us involved 
> then cared whether it was alt or one of thousands of other strings that it 
> could have been.  The main point was to come up with something that would not 
> pad total length too much and that could be a clear "protocol switch".  The 
> registration in the IANA sutld registry was suppossed to ensure the same 
> outcome as what is going through SSAC, but it makes no difference to me what 
> the characters are.  Note that because of the old-timey restriction, I 
> suspect the characters must all be alphabetic, though perhaps that rule has 
> been superseded by IDNA.
> 
> A
> 


signature.asc
Description: PGP signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[John R. Levine]

On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:


recommends that the ICANN board to pick a string that will never be put 
into the DNS root, and thus is usable for systems like GNS.


This was, of course, the whole point of the .alt draft in the first place, at 
least when I was involved in preparing it.


Indeed.  If you look at SAC113 and draft-ietf-dns-alt-tld, you'll see a 
lot of the same names.


 I don't think any of us involved then cared whether it was alt or one 
of thousands of other strings that it could have been.


The leadning candidates were .ALT or one of the ISO 3166 User-assigned 
codes like .QZ, but I agree that picking one is more important than which 
one gets picked.


Regards,
John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

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

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Andrew Sullivan]

Disclaimer: I work for the Internet Society but I am not speaking for them.

On Tue, Aug 02, 2022 at 07:11:38PM +, Paul Hoffman wrote:


recommends that the ICANN board to pick a string that will never be put into 
the DNS root, and thus is usable for systems like GNS.


This was, of course, the whole point of the .alt draft in the first place, at least when 
I was involved in preparing it.  I don't think any of us involved then cared whether it 
was alt or one of thousands of other strings that it could have been.  The main point was 
to come up with something that would not pad total length too much and that could be a 
clear "protocol switch".  The registration in the IANA sutld registry was 
suppossed to ensure the same outcome as what is going through SSAC, but it makes no 
difference to me what the characters are.  Note that because of the old-timey 
restriction, I suspect the characters must all be alphabetic, though perhaps that rule 
has been superseded by IDNA.

A

--
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] [Ext] draft-schanzen-gns and draft-ietf-dns-alt-tld

[Paul Hoffman]

The ISE started this thread with a discussion that included "Whether that means 
using TLD labels that begin with _ or whether that means suffixing them with 
".ALT", I leave to you experts to sort." There is another forthcoming option 
that could be used in draft-schanzen-gns, namely the unallocated string that 
may be chosen as part of the process coming out of SAC113.

SAC113 , published 
by ICANN's Security and Stability Advisory Committee, recommends that the ICANN 
board to pick a string that will never be put into the DNS root, and thus is 
usable for systems like GNS. The recommendation is moving forward, as can be 
seen on the SAC113 line on page 10 of 
.
 A string that is guaranteed to never appear in the DNS root can be used as the 
basis of private-use names, even if that guarantee doesn't come from the DNSOP 
Working Group.

(I was not part of the SAC113 work, but am reporting here so that the ISE and 
GNS can see that they will have additional options.)

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop