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

[Brian Dickson]

Top-reply (not apologizing for doing so, either):

If I read the actual draft correctly, it is _not_ intended to be a DNS
drop-in replacement.
Instead, it is meant to be an _alternative_ to DNS.

So, why even use DNS-compatible label strings? That is an obviously
conflict-causing choice, which is entirely avoidable.

Most of the references in this thread to IETF documents or ICANN documents,
are within the context of DNS-compatible naming schemes, that themselves
lead to such conflicts.

The obvious choice, to me, would be for GNS to use a DNS-incompatible
suffix, that is short and memorable in some way.

(That rules out .alt  and something.arpa obviously, and probably anything
that starts with underscore or even contains the asterisk character).

So, pretty much pick any other UTF-8 string that is not a potential DNS
label, and is easy to type, short, and unambiguously "NOT DNS".

Choice is left as an exercise to those wanting to paint the bike shed.

The mnemonic of "!" would be clear, meaning "not", or possibly "~",
which is a different kind of "not", or even "^" as another "not".
Other non-shift key candidates ",/=;" or any of "[]\`'" (but less favorable
due to interaction with the unix shell).
Similar one-character shift-key options have various
pros/cons: @#$%&():"{}|<>?"
Basically, pick any of the above, but not any of ".+@-_*", and you are good
to go.
If it makes a DNS resolver complain, it is a good choice.
(Even "**" would be okay, as it is not a legal DNS label.)

At which point, no conflict exists, ISE and DNSOP are all happy, your draft
can be published (with the proviso that this suffix MUST be used always)
and we can stop having this discussion, permanently.

Brian

On Mon, Aug 1, 2022 at 10:11 AM Martin Schanzenbach 
wrote:

> Excerpts from Stephane Bortzmeyer's message of 2022-08-01 17:29:38 +0200:
> > On Mon, Aug 01, 2022 at 02:31:48PM +0200,
> >  Independent Submissions Editor (Eliot Lear) 
> wrote
> >  a message of 89 lines which said:
> >
> > > Whether that means using TLD labels that begin with _ or whether
> > > that means suffixing them with ".ALT", I leave to you experts to
> > > sort.  I do agree with Martin that it would be helpful to have some
> > > registration of names so that conflicts between name spaces can be
> > > avoided.  This would also encourage formal documentation of those
> > > projects.
> >
> > I agree and I think publication of these drafts would be a good idea
> > (may be with status Experimental since, as Joe Abley said, there is
> > clearly no IETF consensus). Note that I am skeptical about their use:
> > most people who "preempt" .eth, .bitcoin, .web3 or .myownprotocol will
> > not read the RFC and, if they do, won't follow it. But at least we
> > will be able to say that we tried and we have a solution (and not a
> > ridiculous one such as "pay ICANN 185 000 US $").
> >
>
> tl;dr:
> I am a bit ambivalent towards the ".alt" approach.
> For alternative name systems that are specified with status
> "Informational"  the use of ".alt" seems highly unattractive as there is
> absolutely no benefit in using it but at the same time there are
> (obvious) disadvantages especially compared to other name systems which
> do not (try to) publish in the RFC series.
>
> ---
>
> Reasons:
>
> With our draft you would have one system which references
> this "solution", as opposed to specifying solution looking for a problem.
> That being said, since our current draft is Informational, I do not
> think the existence of an ".alt"-RFC would significantly alter our protocol
> implementation or deployment for now.
>
> There is just no benefit for a name system in using it. The benefit lies
> solely with DNS and the existing infrastructure.
> After all, a new "Standards Track" name system that could potentially be
> used as
> a DNS-drop-in would not be designed or specified using ".alt", right?
> That would be like requiring DoH servers to only process names under
> ".doh.alt".
> But they do not and never have, because even though the technical
> resolution process is different, it is still the same namespace.
> So what if (yes I know very theoretical) ICANN and TLD-registrars
> publish their zones in GNS? Is it still www.example.com.gns.alt or would
> it be the _same_ namespace managed by the _same_ authorities resolved
> through GNS and become www.example.com?
> If the latter is the case, what is the purpose of ".gns.alt"?
>
> Further, migration becomes more difficult with ".alt".
> For example, is it possible to get X.509 certificates issued for those
> domains?
> Not to mention that users have to deal with (significantly!) longer names
> as you need a
> second-level indicator on which name system is asked for.
> e.g.:
> www.example.com.gns.alt vs
> www.example.com
>
> So unless IESG actually finds a conflict and we have to put it in the
> specification as a requirement, I don't see why we (GNUnet) should use it
> at all in practice for our implementation.
> Since our draft is 

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[John R. Levine]

On Wed, 3 Aug 2022, Dave Crocker wrote:

Original Text
-
  | URI| _acct | [RFC6118] |

Corrected Text
--
  | URI| _acct | [RFC7566] |


In Spring, 2018 and again in Fall, 2018, there was some focused discussion 
(see:  dnsop) about _acct, and related strings, and which citation to use for 
the enum-related values.  The choice bounced around, as I've cited.  This 
includes having what is now being deemed the 'correct' choice in -14...


Note that none of the cited documents refers to the exact string "_acct".  So 
there is a derivation process that seems to be unclear. I believe the 
attrleaf RFC contains no pedagogy about this, but it probably should.


I remember the rather long discussions about the possible collisions in 
URI names between transport and enumservice names, and again about whose 
job it is to keep registries in sync.  Bu in this case we made a clerical 
mistake, and missed the important detail that after the enumservices 
update in RFC 6118, some of the types were added in later RFCs.


Having looked at all of Bernie's errata, I don't think any of them present 
subtle errors.  There was an eye-glazing list of entries in that document 
and we unsurprisingly missed a few details.


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] URI RR labels derived from Enumservices (was: [Editorial Errata Reported] RFC8552 (7064))

[John Levine]

It appears that   said:
>Shouldn't the labels for Subtypes also go to this (initial) URI Registry?

Nope. The intent of this registry is to list all of the _tags that one
might run into when setting up a new thing, so you don't collide with
tags that other things already use. The subtype tags only appear to
the left of a type tag, so there's no collision problem.

It's the same reason that for SRV and URI we included the small set of
transport tags like _tcp and _udp but not the giant list of service
subtags like _smtp and _https.

My recollection is that we had two overlapping dicussions involving
IANA. One was that the names for URI records are the union of
transport names and enumservice type tags, and there is no provision
to keep the tag names from colliding if there are new ones.

The other was the general issue of multiple registries that are
supposed to stay in sync, and is it adquate to ask IANA to tell people
who update one registry that they should think about the other, also.

R's,
John

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

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[Dave Crocker]

On 8/3/2022 9:48 AM, Tim Wicinski wrote:

This seems to be the mail thread which discusses 7566/6118 :

https://mailarchive.ietf.org/arch/msg/dnsop/d5KQEP1Ud1TxQpanNMY2_b0CpL8/


that's the second and more substantial thread.

The first brief one began with:

https://mailarchive.ietf.org/arch/browse/dnsop/?gbt=1=XYijqc1aIwHn_pOLZu0RusE9y0U


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[Tim Wicinski]

This seems to be the mail thread which discusses 7566/6118 :

https://mailarchive.ietf.org/arch/msg/dnsop/d5KQEP1Ud1TxQpanNMY2_b0CpL8/

On Wed, Aug 3, 2022 at 12:13 PM Dave Crocker  wrote:

> On 8/2/2022 8:04 AM, RFC Errata System wrote:
>
> Type: Editorial
> Reported by: Bernie Hoeneisen  
> 
>
> Section: 4.1.2.
>
> Original Text
> -
>  | URI| _acct | [RFC6118] |
>
> Corrected Text
> --
>  | URI| _acct | [RFC7566] |
>
> Notes
> -
> Wrong reference. Note that is also has an impact to the IANA registry: 
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
>
>
> Folks,
>
>1. Bernie, thanks for bringing this up
>2. Using this case as an example, the history in the attrleaf
>development seems concerning.  The RFC cited for this entry changes, over
>the course of a number of I-D versions.  So, in -13 is was RFC 7553, -14 is
>was RFC 7566, and in -15 it went to RFC 6118.
>3. That the published version landed on the wrong choice should raise
>a question possibly about process but especially about understanding.
>
> In Spring, 2018 and again in Fall, 2018, there was some focused discussion
> (see:  dnsop) about _acct, and related strings, and which citation to use
> for the enum-related values.  The choice bounced around, as I've cited.
> This includes having what is now being deemed the 'correct' choice in -14...
>
> Note that none of the cited documents refers to the exact string "_acct".
> So there is a derivation process that seems to be unclear. I believe the
> attrleaf RFC contains no pedagogy about this, but it probably should.
>
> Before doing the simple -- but possibly wrong -- thing of agreeing on a
> new -- or, rather, returning to an old -- better RFC citation, I suggest
> there be some community discussion about the why of the right choice and
> consideration of how to document that, this time, this latest choice is the
> truly correct one.
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorkingbbiw.net
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] URI RR labels derived from Enumservices (was: [Editorial Errata Reported] RFC8552 (7064))

[bernie]

Hi Dave

Not sure there is yet another issue around the Enumservices derived URI 
label registrations.


As I understand this document (RFC 8552) is based on RFC 7553 regarding 
Enumservices, which states:


   The Enumservice Registration [RFC6117] parameters are
   reversed (i.e., subtype(s) before type), prepended with an underscore
   (_), and prepended to the owner name in separate labels.
   [...]
   For example, suppose we are looking for the URI for a service with
   ENUM Service Parameter "A:B:C" for host example.com.  Then we would
   query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").


However, RFC 8552 only lists the Enumservices labels for Types, but not 
for Subtypes: 
https://www.iana.org/assignments/enum-services/enum-services.xhtml


Shouldn't the labels for Subtypes also go to this (initial) URI Registry?

cheers,
 Bernie (Designated Expert for Enum)


--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology


On Wed, 3 Aug 2022, Dave Crocker wrote:


On 8/2/2022 8:04 AM, RFC Errata System wrote:

Type: Editorial
Reported by: Bernie Hoeneisen 

Section: 4.1.2.

Original Text
-
 | URI| _acct | [RFC6118] |

Corrected Text
--
 | URI| _acct | [RFC7566] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA registry: 
https://www.iana.org/assignments/dns-parameters/dns-pa
rameters.xhtml#underscored-globally-scoped-dns-node-names


Folks,

 1. Bernie, thanks for bringing this up
 2. Using this case as an example, the history in the attrleaf development 
seems concerning.  The RFC cited for this entry
changes, over the course of a number of I-D versions.  So, in -13 is was 
RFC 7553, -14 is was RFC 7566, and in -15 it
went to RFC 6118.
 3. That the published version landed on the wrong choice should raise a 
question possibly about process but especially about
understanding.

In Spring, 2018 and again in Fall, 2018, there was some focused discussion 
(see:  dnsop) about _acct, and related strings,
and which citation to use for the enum-related values.  The choice bounced 
around, as I've cited.  This includes having what
is now being deemed the 'correct' choice in -14...

Note that none of the cited documents refers to the exact string "_acct".  So 
there is a derivation process that seems to be
unclear. I believe the attrleaf RFC contains no pedagogy about this, but it 
probably should.

Before doing the simple -- but possibly wrong -- thing of agreeing on a new -- 
or, rather, returning to an old -- better RFC
citation, I suggest there be some community discussion about the why of the 
right choice and consideration of how to document
that, this time, this latest choice is the truly correct one.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] [Editorial Errata Reported] RFC8552 (7064)

[Dave Crocker]

On 8/2/2022 8:04 AM, RFC Errata System wrote:

Type: Editorial
Reported by: Bernie Hoeneisen

Section: 4.1.2.

Original Text
-
  | URI| _acct | [RFC6118] |

Corrected Text
--
  | URI| _acct | [RFC7566] |

Notes
-
Wrong reference. Note that is also has an impact to the IANA 
registry:https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names



Folks,

1. Bernie, thanks for bringing this up
2. Using this case as an example, the history in the attrleaf
   development seems concerning.  The RFC cited for this entry changes,
   over the course of a number of I-D versions.  So, in -13 is was RFC
   7553, -14 is was RFC 7566, and in -15 it went to RFC 6118.
3. That the published version landed on the wrong choice should raise a
   question possibly about process but especially about understanding.

In Spring, 2018 and again in Fall, 2018, there was some focused 
discussion (see:  dnsop) about _acct, and related strings, and which 
citation to use for the enum-related values.  The choice bounced around, 
as I've cited.  This includes having what is now being deemed the 
'correct' choice in -14...


Note that none of the cited documents refers to the exact string 
"_acct".  So there is a derivation process that seems to be unclear. I 
believe the attrleaf RFC contains no pedagogy about this, but it 
probably should.


Before doing the simple -- but possibly wrong -- thing of agreeing on a 
new -- or, rather, returning to an old -- better RFC citation, I suggest 
there be some community discussion about the why of the right choice and 
consideration of how to document that, this time, this latest choice is 
the truly correct one.



d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
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 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] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Gavin McCullagh]

Perfect, thanks Paul.

On Wed, Aug 3, 2022, 07:50 Paul Hoffman  wrote:

> On Aug 3, 2022, at 6:48 AM, Gavin McCullagh  wrote:
> >
> >
> > > Nonetheless, the significant deployment of
> > > DNSSEC within some top-level domains (TLDs), and the near-universal
> > >  deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable
> > >   for implementation by both ordinary and highly sophisticated domain
> > >   owners.
> >
> > Maybe it's my lack of dns inside baseball terminology
>
> Nope; it was just my unclear writing.
>
> > but I found the hard distinction between "within" and "in" a bit
> confusing here and had to re-read to grok what was meant.  It might be
> clearer to contrast e.g. "at the TLDs" with "below/within some TLDs" to
> bring out the distinction.
>
> Proposed fix:
>
> Nonetheless, the significant deployment of DNSSEC beneath some top-level
> domains (TLDs),
> and the near-universal deployment of DNSSEC for the TLDs in the DNS root
> zone,
>
> >
> > >*  [RFC7344] describes using the CDS and CDNSKEY resource records to
> > >  help automate the creation of DS records in the parents of signed
> > >  zones.
> >
> > The term used in the RFC is "maintenance" as opposed to "creation" which
> seems more precise, given that CDS does not directly address initial
> creation of a DS.
>
> Good catch! Fixed.
>
> --Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Paul Hoffman]

On Aug 3, 2022, at 6:48 AM, Gavin McCullagh  wrote:
> 
> 
> > Nonetheless, the significant deployment of
> > DNSSEC within some top-level domains (TLDs), and the near-universal
> >  deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable
> >   for implementation by both ordinary and highly sophisticated domain
> >   owners.
> 
> Maybe it's my lack of dns inside baseball terminology

Nope; it was just my unclear writing.

> but I found the hard distinction between "within" and "in" a bit confusing 
> here and had to re-read to grok what was meant.  It might be clearer to 
> contrast e.g. "at the TLDs" with "below/within some TLDs" to bring out the 
> distinction.

Proposed fix:

Nonetheless, the significant deployment of DNSSEC beneath some top-level 
domains (TLDs),
and the near-universal deployment of DNSSEC for the TLDs in the DNS root zone,

> 
> >*  [RFC7344] describes using the CDS and CDNSKEY resource records to
> >  help automate the creation of DS records in the parents of signed
> >  zones.
> 
> The term used in the RFC is "maintenance" as opposed to "creation" which 
> seems more precise, given that CDS does not directly address initial creation 
> of a DS.

Good catch! Fixed.

--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

[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] Working Group Last Call for aft-ietf-dnsop-dnssec-bcp

[Gavin McCullagh]

> Nonetheless, the significant deployment of
> DNSSEC within some top-level domains (TLDs), and the near-universal
>  deployment of DNSSEC in the TLDs, demonstrate that DNSSEC is suitable
>   for implementation by both ordinary and highly sophisticated domain
>   owners.

Maybe it's my lack of dns inside baseball terminology but I found the hard
distinction between "within" and "in" a bit confusing here and had to
re-read to grok what was meant.  It might be clearer to contrast e.g. "at
the TLDs" with "below/within some TLDs" to bring out the distinction.


>*  [RFC7344] describes using the CDS and CDNSKEY resource records to
>  help automate the creation of DS records in the parents of signed
>  zones.

The term used in the RFC is "maintenance" as opposed to "creation" which
seems more precise, given that CDS does not directly address initial
creation of a DS.

Gavin
___
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