Re: [DNSOP] Possible alt-tld last call?

[Joe Abley]

Hi Rob,

On Oct 19, 2022, at 08:54, Rob Wilton (rwilton) 
 wrote:

> The reason for my interjection is only because I’ve seen some comments 
> stating that this topic is too hard, we can’t get rough consensus, and hence 
> the WG should give up and declare defeat.  However, from my reading of the 
> thread, I’m not convinced that the WG is necessarily that far away from rough 
> consensus, particularly on the significant (i.e., most important) parts of 
> the draft.  Nor, if the WG declares failure, do I see a better path forward.

Another path forward would be for the IETF (in some appropriate guise) to make 
an architectural statement to the effect that

 - the DNS is the principal naming system of Internet architecture, as defined 
and maintained by the IETF
 - the DNS is arguably the most successful global naming system in the history 
of humankind, and consequently is significantly embedded in the minds and 
experience of end-users and in the design of software
 - it is natural that other naming systems be developed from time to time, 
outside the IETF
 - it is natural that such naming systems might emulate particular aspects of 
the DNS, such as the format and presentation of names
 - the design, implementation and operation of such naming systems is not the 
IETF's business
 - the accommodation and interoperability of such naming systems with the DNS 
or other IETF naming systems is not the IETF's business

Then perhaps we could just get on with talking about the DNS and not about 
accommodating other naming systems that may or may not exist today or in the 
future and the speculative union of namespaces that is larger than that of the 
DNS in ways that are not well-defined and not within the IETF's realm of 
control.

It is impossible by definition for the IETF to exert influence or control over 
all other naming systems that are developed and maintained outside the IETF. I 
don't think we should waste more time trying.

That said,

> Some participants have indicated that they don’t support this document 
> because they don’t think that it will end up being useful (principally 
> because the other naming systems may still squat on TLDs anyway), but that 
> they are also not opposed to publishing this document because they also see 
> that it won’t cause harm either.  I regard these views as being within rough 
> consensus of publishing this document.

This is kind of my position, except that the real reason I am not especially 
opposed to this document is that I hope by publishing it we can end this 
conversation and get back to working on the DNS. In other words the reason for 
my lack of objection (my negative monologues notwithstanding) is that what I 
really want is for this to be the final word on the subject.

Perhaps a quick draft outlining the principles embedded in my bullets above 
could be published alongside the alt-tld draft to make it more clear that 
alt-tld really is the final word.

I'll note also that alt-tld being the final word and an IETF registry being 
created to document non-IETF naming systems in the future are inconsistent 
ideas. Creating a registry seems like a terrible idea to me for that reason.

If there is consensus around the idea that alt-tld, if published, could be made 
clearly the final word on accommodating naming systems present and future that 
are not of the IETF, then I am willing to spend time on this.


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

Re: [DNSOP] Possible alt-tld last call?

[Rob Wilton (rwilton)]

does not indicate any IETF endorsement of entries in the registry 
or the referenced specifications (although I think that this is probably 
generally a given for IANA registries anyway), and (ii) nor does the registry 
make any guarantees that it is necessary complete.
  2.  I would recommend a registration policy of “Specification required”.  
Specifically, the definition of specification required automatically includes 
expert review, and RFC 8126 already allows appeals to the IESG/IAB for rejected 
registrations.
  3.  There should be documented guidelines of what the expert review part of 
the “Specification Required” policy should entail:
 *   The specification needs to be for a name resolution system and be 
documented in a stable reference (as per RFC 8126).
 *   The expert reviewer may, but is not required, validate the quality or 
correctness of the specification.  The expert reviewer may reject requests 
where the specification is insufficient.
 *   Name resolution protocols are expected to only require a single entry, 
or otherwise a very small number of unique entries, directly under .alt.
 *   Name resolution protocols SHOULD choose a unique name under .alt, but 
the expert reviewer MAY allow multiple entries under .alt in exceptional 
circumstances.

Proposed next steps (for authors, WG, and WG chairs to consider):

I think that it would be helpful for the authors to post an updated version of 
the draft aiming to incorporate the feedback that has been received recently.

I also suggest that it would be helpful to have discussion this draft in DNSOPS 
in IETF 115, if there is time available.  It is up to the authors & WG chairs, 
but it may be useful to do a hum or “show of hands” on test consensus 
(specifically if anyone can’t live with) on the proposals for: 4(i), and 4(iii) 
above.

I am, of course, happy to receive comments from the DNSOP WG (or chairs, or 
authors) on the mailing list on any aspect of my comments above, either stating 
that the proposals are awful/misguided/wrong/etc, or that they could be an 
acceptable way forward.  But I would really appreciate it if we can try and 
compromise a little to find a way forward.

Kind regards,
Rob


From: DNSOP  On Behalf Of Suzanne Woolf
Sent: 16 October 2022 16:03
To: dnsop@ietf.org
Cc: Rob Wilton (rwilton) ; DNSOP-Chairs Chairs 

Subject: [DNSOP] Possible alt-tld last call?

Dear Colleagues,


The chairs have gotten a couple of requests, off-list and on, for a WGLC on 
draft-ietf-dnsop-alt-tld.

We’ve reviewed the current draft closely and have some concerns that we feel 
need to be resolved before any effort to move the draft forward. (Suzanne wrote 
this but it’s been discussed among all of the co-chairs.)

1. As far as I can tell, this draft does not comply with RFC 6761. This is a 
problem for two reasons.

First, this creates a process problem in that RFC 6761 is the standards-track 
document that specifies how the SUDN registry is to be administered, so a 
request that doesn’t meet the requirements in 6761 can’t (or at least 
shouldn’t) go into the registry.

RFC 6761 section 4 asserts:

The specification also MUST state, in each of the seven "Domain Name 
Reservation Considerations" categories
below, what special treatment, if any, is to be applied.

The alt-tld draft ignores this MUST, without explanation (unless I missed it).

The substantive issue is that the questions in Section 5 are there to make sure 
there’s a full description of the expected handling of a proposed name by the 
assorted components that take part in DNS operations and protocol. The draft 
answers at least some of the Section 5 questions, but the answers are largely 
implied.

For example, the draft says that DNS resolvers seeing .alt names "do not need 
to look them up in the DNS context”, but a big part of the point of codifying 
these names is the assumption that queries will leak and DNS servers will see 
them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is 
simply not in the public DNS root zone and the root servers (or better yet, any 
intermediate resolver) should answer “name error”/NXDOMAIN for such queries. 
But this should probably be said explicitly, because people who configure DNS 
servers and services shouldn’t have to guess what’s being implied here. (The WG 
discussed the possibility that such queries should be blackholed and not 
answered at all, which is in some ways an obvious answer. Clarification of why 
this was discarded might also be helpful.)

So, the current draft isn’t meeting the requirements for the registry, and also 
doesn’t clearly answer substantive questions about what DNS operators are 
expected to do. This makes me uncomfortable doing a WGLC without a new rev. It 
would be Rob Wilton’s call of course (as AD for this draft, substituting for 
Warren) but I’m really uneasy with a WGLC without those changes— they seem 
rather too large to punt for a post-WGLC versi

Re: [DNSOP] Possible alt-tld last call?

[Wes Hardaker]

Warren Kumari  writes:

> 1: as we've already seen, nothing stops people from just using whatever names
> they want[0], and so there is no guarantee that registry would be complete and
> correct.

So the interesting side-point is that what happens with people that
don't want to go through the process of registering?  IE, if the burden
is high or they're simply lazy, they'll still end up squatting.  So we
need an alt.alt that isn't registered at all?  Do we make the burden so
low that it attracts hopefully everyone?  Do we not have a registry so
this problem goes away?  ...

-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Possible alt-tld last call?

[Wes Hardaker]

Martin Schanzenbach  writes:

> Wouldn't such a WG need the .alt as a prerequisite to any actual work or
> at least have .alt as its first work item?

Actually, that's only one solution.  It's the easiest and hence the
reason it's being preferred.

The probably *right* solution is to fix all the documents specifying
implementation with respect to naming that assumes the DNS is the only
system (URLs) [1], and all the APIs that make use of it (getaddrinfo).
The list of RFCs to update to allow namespace selection is far from short.

[1] note that this statement is both right and wrong in many ways.  I'm
avoiding the more complex aspects.
-- 
Wes Hardaker
USC/ISI

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

Re: [DNSOP] Possible alt-tld last call?

[Martin Schanzenbach]

On OCT17@11:53, Paul Wouters wrote:
> On Mon, 17 Oct 2022, Eliot Lear wrote:
> 
> > Let's please leave Internet lawyering to lawyers.  If people want a
> > legal opinion on this draft, the IETF does have resources for that.
> 
> But it is to the core of the ICANN / IETF divide, so IETF shouldn't wade
> into ICANN territory.
> 
> > We cannot assume that DNS will forever be the only Good approach and
> > that all others will forever be Bad. Given that, we as a community are
> > obligated to search for better, and to try new things.
> 
> Sure. The IETF method is to start a BoF, form a WG, do your thing. See
> Speedy/QUIC. See SSL/TLS, See PGP/OpenPGP.
> 

I am a bit confused now. Let's say there is BoF and, eventually, a WG.
How is that WG supposed to "do it's thing" with respect to alternative
name spaces if there is literally no way to safely use and test it's
results alongside DNS?
Wouldn't such a WG need the .alt as a prerequisite to any actual work or
at least have .alt as its first work item?
Would especially dnsop not care if another WG starts defining a protocol
that is able to resolve names that look like/are DNS names because it is
designed to possibly replace it in the future?

BR

> > There exist many registries for things the IETF doesn't recommend.  One
> > need look no further than TLS 1.3 crypto-suites as an example.
> 
> These are not equivalent. For TLS to interop with non-IETF stuff, they
> need codepoints for within the IETF defined TLS protocol. They are not
> replacing TLS with something else on port 443. (and on top, non-TLS WG
> entries are marked as NOT RECOMMENDED)
> 
> > No matter what we say in the ALT draft, someone could burden the IETF
> > with a new draft.  People do so every day.  If it gains sufficient
> > support, it would have to be at least considered, no matter the topic.
> 
> Sure, but "replacing DNS with something else", would definitely not be
> in dnsop, or the ISE, but via BoF and a new WG. I dout any of the
> alternatives would follow that approach, especially as I cannot see us
> starting a new (replacement or not) naming scheme where there is a new
> landrush for domain names with all of its ICANNlike associated problems.
> 
> I can see DNS 2.0 that replaces all of DNS, but would still hook into
> the existing EPP and RRR ICANN model though. Again, that would not go
> via the ISE path.
> 
> Paul
> 
> ___
> 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

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

On Sun, Oct 16, 2022 at 8:03 AM Suzanne Woolf  wrote:

> Dear Colleagues,
>
>
> The chairs have gotten a couple of requests, off-list and on, for a WGLC
> on draft-ietf-dnsop-alt-tld.
>
> We’ve reviewed the current draft closely and have some concerns that we
> feel need to be resolved before any effort to move the draft forward.
> (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>

Having re-read this draft, and having re-read 6761, I think that "alt"
should NOT be added to the SUDN.
The logic is that the SUDN is for DNS domain names only, and "alt" is
explicitly for non-DNS names.
(Even though it is tempting to include "alt" to give information to those
wanting to do non-DNS names, it's still probably best to not do that, IMHO.)


>
> First, this creates a process problem in that RFC 6761 is the
> standards-track document that specifies how the SUDN registry is to be
> administered, so a request that doesn’t meet the requirements in 6761 can’t
> (or at least shouldn’t) go into the registry.
>
> RFC 6761 section 4 asserts:
>
> The specification also MUST state, in each of the seven "Domain Name
> Reservation Considerations" categories
> below, what special treatment, if any, is to be applied.
>
>
> The alt-tld draft ignores this MUST, without explanation (unless I missed
> it).
>
> The substantive issue is that the questions in Section 5 are there to make
> sure there’s a full description of the expected handling of a proposed name
> by the assorted components that take part in DNS operations and protocol.
> The draft answers at least some of the Section 5 questions, but the answers
> are largely implied.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>

I think there should be some instructions to parties wanting to implement
non-DNS name systems on additional requirements or anti-requirements, to
further reduce the likelihood of queries reaching DNS servers.
Specifically, I think having words to the effect of, "Alternative
namespaces SHOULD NOT (or MUST NOT) use the port numbers reserved for DNS
(including but not limited to 53 and 853)."

If they are not DNS they need to not be DNS. Private DNS is still DNS,
which is semantically different from alternative namespaces.
DNS resolvers are expected to be able to handle public and private DNS
names. Alternative namespaces have the potential to collide with DNS names.
As such, resolvers should be DNS or not-DNS, but never both.


>
> So, the current draft isn’t meeting the requirements for the registry, and
> also doesn’t clearly answer substantive questions about what DNS operators
> are expected to do. This makes me uncomfortable doing a WGLC without a new
> rev. It would be Rob Wilton’s call of course (as AD for this draft,
> substituting for Warren) but I’m really uneasy with a WGLC without those
> changes— they seem rather too large to punt for a post-WGLC version.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> basis that having the IETF “recognize” (if only by recording) such
> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> supposed recognition of alternate (non-DNS) namespaces as reservations of
> the namespace from the shared, common DNS root. We’re still being denounced
> in certain corners for .onion. It might be good to have a paragraph calling
> out specifically why .alt is not a delegation of a TLD from the DNS root by
> the IETF, even though it looks like one. (We didn’t invent this problem,
> because we didn’t make the decision that top-level domain labels should be
> used by other protocols in a way that led to confusion. But let’s not
> propagate it.)
>

If each alternate namespace uses its own port numbers, there would not even
be a need for any SLD for any such namespace.
Using the "alt" RML (rightmost label) would still be a good thing to
recommend so DNS has some ability to recognize and reject lookups for other
namespaces.
(I.e. use a belt and suspenders philosophy)


>
> 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term
> “registered” differ

Re: [DNSOP] Possible alt-tld last call?

[Ben Schwartz]

While we're talking about this draft, I would like to suggest that the
draft discuss the interpretation of URIs containing ".alt" hostnames.  I
have great difficulty understanding what "https://example.foo.alt/"; means
... but most of the interest in alternative naming systems seems to be
based on the idea that this sort of URI is meaningful.

Personally, my intuition is that there is a big difference between naming
systems that essentially reuse the DNS RR types, and perhaps can thereby
reuse DNS-bound URI schemes (via a new "virtual DNS interface"), and those
that do not and cannot.  For the latter, new URI schemes would be needed.
This seems to be the essential logic behind the W3C DID effort, which
starts from a new URI scheme.


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

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

Speaking only for myself (and definitely not for my employer, GoDaddy)...

On Sun, Oct 16, 2022 at 11:45 PM Eliot Lear  wrote:

>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> > Basically, .alt is what IETF recommends you should not do, and we
> > should not keep
> > a registry of entries within it.
>
> We cannot assume that DNS will forever be the only Good approach and
> that all others will forever be Bad. Given that, we as a community are
> obligated to search for better, and to try new things.  As I wrote
> earlier, I do not know that GNS will succeed. I do hope and expect that
> the community will learn something from some deployment experience of
> that protocol so that the next one can be better.
>
>
I think that the concerns of namespace and root(s) is essentially this:

   - The Domain Name System has the ICANN Root as its source of legitimacy,
   and the IETF as its standards body.
   - Other namespaces need to be effectively "ships in the night" with
   respect to The Domain Name System
  - This means no interoperation between "not-DNS" and "DNS" at a name
  space layer.
  - Specifically, as long as any other name resolution scheme has no
  overlap with any portion of the DNS tree, what names that other system
  contains is a moot point (even if they superficially appear to collide)
   - The alternative (allowing non-DNS services to also directly
   incorporate the DNS tree) has a high likelihood of causing user confusion
   or worse.
  - Any alternative systems should stand entirely on their own, and
  their success or failure would be possible to objectively assess.
  - The only place where multiple systems (DNS and any non-DNS) should
  be combined is the same place they have always been,
/etc/nsswitch.conf (or
  equivalent)
   - Experimentation and development of standards can only happen safely
   when unrelated systems don't overlap or conflict.
   - This suggestion would be the antithesis of the "Good vs Bad"
   viewpoint, and IMNSHO consistent with what DNSOP does already.

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

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

On Mon, Oct 17, 2022 at 7:12 AM Joe Abley  wrote:

>
> My goal is certainly not to put any brakes on if the effect of that is to
> make things move more slowly. I apologise if that's what I have done in
> suggesting to Brian that semantic-free labels do not fit the problem space.
>
>
And I, in return, apologise for my idea. Clearly, not a good idea, although
maybe useful for discussing concepts, and reaching conclusions about such a
registry.

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

Re: [DNSOP] Possible alt-tld last call?

[Warren Kumari]

On Sun, Oct 16, 2022 at 7:20 PM, Paul Wouters  wrote:

> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> One could advance the 6761bis proposal document first, which would remove
> these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>
> I think it draft would be better if it said something along the lines of:
>
> No code changes are required to properly handle leaked queries for .alt
> into the DNS, but:
>
> 1) Implementations MAY handle .alt specially by (pre)fetching the proofs
> of non-existence of .alt and serve these for all .alt queries.
> 2) implementations MAY rely on their query minimalization to accomplish 1)
> 3) or MAY do nothing special, which should work fine but might leak SLD
> queries to the root if the implementation and its querier didn't do query
> minimalization)
> 4) MAY return FORMERR on .alt queries that in some ways violate the DNS
> specification (so that no code changes are mandatory to support the madness
> .alt queries could bring in, eg >63 SLD names)
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD. Basically,
> .alt is what IETF recommends you should not do, and we should not keep a
> registry of entries within it.
>
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems. The whole idea of the ICANN/IETF split is
> that ICANN does money and legal stuff, and IETF does codepoints and running
> code (with no money) :P
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>



#include 

I'll note that I was one of the people initially pushing for a registry - I
wanted to be able to lookup 'foo.alt' and see that I should read the
specifications "The foo naming system", available on GitHub at  (and
possibly also "foo-names - the protocol" available at ).

But:
1: as we've already seen, nothing stops people from just using whatever
names they want[0], and so there is no guarantee that registry would be
complete and correct.
2: if this happens to be widely used, we might end up with lots and lots of
names using this, and having e.g the IANA maintain this has costs - even if
they just note "FooNet says that they use foo.alt and their specification
is at https://www.the-foo-project.example/foo-names.html";, this has costs.
I really don't want us to end up with a "success failure".

Having something like a list of what to read to understand how to resolve
bar.foo.alt still seems useful, but it could (IMO) just be a list on GitHub
that someone is willing to manage (similar to the PSL (
https://github.com/publicsuffix/list), but purely informational, and with
no real validation/work. And, no, I'm not volunteering to run this).

W
[0]: I just changed the hostname on my laptop bar.foozle.wobble.alt, and
there is nothing you can do to stop me… (actually I didn't, but I could
have)




> 3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term
> “registered” differently than common usage. Judging from searches on RFC
> 6761 and RFC 8499, it’s ambiguous for DNS naming and resolution, and
> “registered” can definitely mean something different to a registry or
> registrar than it does to a DNS operator. To people who operate TLD
> registries, a name can be “registered” and still may or may not be
> delegated. (“Label” is defined in 8499,
> “register” and “delegate” are not.) And, in the reference to “TLD,” it
> feels strange to expand the acronym to
> “Top-level label” even if “label” is the ri

Re: [DNSOP] Possible alt-tld last call?

[Warren Kumari]

On Sun, Oct 16, 2022 at 11:44 PM, Eliot Lear  wrote:

> Hi Paul!
>
> Good conversation!  I hope we can discuss some of this "in person"
> (whatever that means these days) at IETF 115.
>
> On 17.10.22 04:20, Paul Wouters wrote:
>
> On Sun, 16 Oct 2022, Suzanne Woolf wrote:
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> One could advance the 6761bis proposal document first, which would remove
> these non-compliance items as those would be no longer needed
> (as the bis document proposal removes it as these were not consistently
> required in the past). Alternatively, ignoring it wouldn't be the first
> time these are ignored, so I guess there is a precedence of ignoring it.
>
> If what you are saying is that we shouldn't get hung up on 6761, then I
> agree.  There are, I think, many ways to deal with the issue that Suzanne
> raised.  One possibility not mentioned was to simply slap an
> "Updates" header on this draft if we think it's necessary, but that
> wouldn't be my first choice.
>

Note: I'm at NANOG this week (and also dealing with dayjob and some other
issues), and so I'm likely to be distracted and not able to focus on this
discussion as much as I'd like. Apologies in advance if I'm replying to
threads midway though / am terser than usual...



I really really don't think that "slap an "Updates" header on this draft"
is a good idea — the WG put a large amount of work into RFC 8244
("Special-Use Domain Names Problem Statement"). RFC 8244 lists 21 top level
issues and includes:
"This document has two goals: enumerate all of the problems that have been
identified to which Special-Use Domain Names are a solution and enumerate
all of the problems that have been raised in the process of trying to use
RFC 6761 as it was intended."

The document also notes that there have been cases where we've messed up
the process:
" 11.  In some cases where the IETF has made assignments through the
process defined in RFC 6761, technical mistakes have been made
due to misunderstandings as to the actual process that RFC 6761
specifies (e.g., treating the list of suggested considerations
for assigning a name as a set of requirements, all of which must
be met).  In other cases, the IETF has made de facto assignments
of Special-Use Domain Names without following the process in RFC
6761 (see [RFC7050] and [RFC7788])."
Some of these process issue have included places where the IETF/IESG/IANA
missed that the fact that documents which added to the registry didn't
include the RFC6761 required bits ("The specification also MUST state, in
each of the seven "Domain Name Reservation Considerations" categories
below, what special treatment, if any, is to be applied.")

However, just because we screwed up in the past and added things to the
registry without following the process (and just because we think that some
of the questions are sub-optimal / inconvenient) doesn't mean that the
right thing to do is to just rip-em-out with an Updates tag. This is
especially true because of how much work the WG put into the "Problem
Statement" document - if there had been clear consensus that that was a
good idea we could have done it then.

I'll also note that while I personally think that some of the questions
could be worded better, the very act of filling them out focuses the
discussions and helps frame the answers in a manner which is useful.

Yes, my life as an author would have been easier not having to try and
figure out the answers to things like:
"  4: Are developers of caching domain name servers expected to make
   their implementations recognize these names as special and treat
   them differently?"
(See earlier discussion - differently to what? If the names are in the
Locally Served Zones registry does that count? Is it specifically
"developers" or "operators" (is this a "code vs configuration" question?)

But, the fact that I had to think about and answer them was really useful,
even if the questions themselves could have been better worded.

W

> The bigger issue is below.  IMHO if we can kink that out, we have
> ourselves a ballgame.
>
> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me
>
> Me too, I really do believe that the IETF should not do this. It is an
> anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
> Some alternative sysytems might even use .alt without SLD.
> [...]
> But also, IETF maintaining a list might open it up for legal liabilities
> with alternative naming systems.
>
> Let's please leave Internet lawyering to lawyers.  If people want a legal
> opinion on this draft, the IETF does have resources for that.
>
> So I disagree with Eliot who prefered some kind of FCFS registry that
> requires RFCs to get an entry. We do not want alternative naming systems to
> require (and burden) the IETF with RFCs.
>
> I am struggling to parse that sentence, but tak

Re: [DNSOP] Possible alt-tld last call?

[Rob Wilton (rwilton)]

Hi Joe,

> -Original Message-
> From: Joe Abley 
> Sent: 16 October 2022 20:30
> To: Brian Dickson 
> Cc: Eliot Lear ; Rob Wilton (rwilton) ;
> Suzanne Woolf ; dnsop@ietf.org; DNSOP-Chairs Chairs
> 
> Subject: Re: [DNSOP] Possible alt-tld last call?
> 
> Op 16 okt. 2022 om 15:03 heeft Brian Dickson
>  het volgende geschreven:
> 
> > For example, using a hash function, such as sha2-256, with output encoded
> as base32hex.
> > (This is just an example; any suitable function that takes URI as input and
> produces an ASCII DNS-compatible label as output would suffice.)
> 
> If we start from the position that names in this shared namespace don't need
> to be semantically meaningful to humans then this whole problem space
> becomes a whole lot easier, or perhaps doesn't even rise to the level of
> "problem". See also 98% of the work done by the ICANN community and
> arguably the entire business models of registries and registrars.
> 
> However, I don't think we are starting from that position. For example we
> hear there is demand for .giraffe for the giraffe naming system described at
> https://giraffe.org/ because using giraffe.org as an anchor for that naming
> system in the namespace is not acceptable to anybody who cares about GNS.
> 
> If giraffe.org doesn't cut the mustard then I have my doubts that
> jduxbenebrnjxudnxznbrnr.alt will satisfy anybody either.
> 
> (If giraffe.org can't be tolerated then I also don't see why giraffe.alt is an
> obvious solution, but I sense people are tired of hearing me say that so I'll
> leave it this parenthetical cloak of invisibility and continue whistling
> innocently.)

You may be right, but I don't think that we can really know this unless we try. 
 And at least if we did standardize .alt then we are offering a sanctioned 
mechanism for supporting alternative domain resolution systems.

I think that we know that gns is willing to use .alt, so we have at least one 
taker.

Rob
// No hats.

> 
> 
> Joe

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

Re: [DNSOP] Possible alt-tld last call?

[Andrew Sullivan]

Dear colleagues,

I work for the Internet Society but this is emphatically not the position of 
the Internet Society.

On Sun, Oct 16, 2022 at 03:03:10PM +, Suzanne Woolf wrote:


2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the basis 
that having the IETF “recognize” (if only by recording) such pseudo-delegations 
may serve to attract unwanted attention to the IETF’s supposed recognition of 
alternate (non-DNS) namespaces as reservations of the namespace from the 
shared, common DNS root. We’re still being denounced in certain corners for 
.onion. It might be good to have a paragraph calling out specifically why .alt 
is not a delegation of a TLD from the DNS root by the IETF, even though it 
looks like one. (We didn’t invent this problem, because we didn’t make the 
decision that top-level domain labels should be used by other protocols in a 
way that led to confusion. But let’s not propagate it.)



I think I might not entirely agree with the reasoning above, but I very 
strongly agree that it would be a bad idea to create a registry for this 
innovation with any change control either held or delegated by the IETF.

The point of the alt namespace, if it has any point at all, is to create a protocol-switch in the 
DNS using in-band signalling via a label.  That protocol switch is there to say, "You are now 
outside the DNS."  It is a mechanism by which someone could in principle put these alternative 
identifiers into what may be thought of as "domain name slots" and hope that somehow 
there is the appropriate handler for such identifiers to work.

Attempting to police or advise about such a chaotic namespace is a doomed venture.  There 
is little reason to suppose it won't be polluted with entries that do not work or that 
cease to work over time.  There is little reason to suppose that any exclusivity rule 
could be enforced, so any protocol wishing to use one of these identifiers needs to be 
prepared to deal with another, conflicting use of the same name anyway.  (To show why 
this is true, consider the use of labels like .home and .lan that were not registered in 
the DNS but that were in wide use by various independent operators in not-very-consistent 
ways.  At least in that case, they all used the DNS wire format.)  And, since alt is 
explicitly saying, "You're not in the DNS," there's not even a single protocol 
that will want these kinds of identifiers.

Anyone who has been through a corporate renumbering that resulted from 
corporate merger and the discovery of awkward RFC 1918 number collisions knows 
that there are basically two kinds of registries for identifiers on the 
Internet: globally-unique registries, and everything else.  There is no way to 
make this a globally unique registry, and yet someone will surely think that by 
getting their label in it they have some claim on that label.  This puts 
whoever is maintaining the registry squarely in the crosshairs of litigious 
people for whom technical reality is no barrier to argument.

Finally, it seems to me that the creation of such a registry presents a serious 
problem for IANA.  IANA, recall, is in part subject to a Customer Standing 
Committee with representation from three operational communities.  If I came 
from the names operational community and saw IANA setting up a registry for 
something that at first glance will look like an end run around names community 
processes (however justified such processes might be), I would ask some pretty 
pointed questions about what IANA is doing.

So, to my mind, creating a registry that won't have any real effect, that won't 
scale, that will almost certainly hold useless registrations, and that presents 
both political and legal risks for the Internet, is something a document 
shouldn't do.

Best regards,

A

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

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

Re: [DNSOP] Possible alt-tld last call?

[Paul Wouters]

On Mon, 17 Oct 2022, Eliot Lear wrote:

Let's please leave Internet lawyering to lawyers.  If people want a legal 
opinion on this draft, the IETF does have resources for that.


But it is to the core of the ICANN / IETF divide, so IETF shouldn't wade
into ICANN territory.

We cannot assume that DNS will forever be the only Good approach and that all 
others will forever be Bad. Given that, we as a community are obligated to 
search for better, and to try new things.


Sure. The IETF method is to start a BoF, form a WG, do your thing. See
Speedy/QUIC. See SSL/TLS, See PGP/OpenPGP.

There exist many registries for things the IETF doesn't recommend.  One need 
look no further than TLS 1.3 crypto-suites as an example.


These are not equivalent. For TLS to interop with non-IETF stuff, they
need codepoints for within the IETF defined TLS protocol. They are not
replacing TLS with something else on port 443. (and on top, non-TLS WG
entries are marked as NOT RECOMMENDED)

No matter what we say in the ALT draft, someone could burden the IETF with a 
new draft.  People do so every day.  If it gains sufficient support, it would 
have to be at least considered, no matter the topic.


Sure, but "replacing DNS with something else", would definitely not be
in dnsop, or the ISE, but via BoF and a new WG. I dout any of the
alternatives would follow that approach, especially as I cannot see us
starting a new (replacement or not) naming scheme where there is a new
landrush for domain names with all of its ICANNlike associated problems.

I can see DNS 2.0 that replaces all of DNS, but would still hook into
the existing EPP and RRR ICANN model though. Again, that would not go
via the ISE path.

Paul

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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

On 17.10.22 17:16, Paul Wouters wrote:


But does the IETF, when running a FCFS registry, want to take the legal
liability of your adjudicating? 


Again, Paul, if you want to ask counsel for advice and have them provide 
it here, great.  Otherwise we end up Internet-lawyering, which is also 
when we end up making bad decisions.  Also, my preferred policy would be 
"RFC Required".


Eliot

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

Re: [DNSOP] Possible alt-tld last call?

[Paul Wouters]

On Mon, 17 Oct 2022, Independent Submissions Editor (Eliot Lear) wrote:


On 17.10.22 12:37, Vittorio Bertola wrote:

 Well, I'm just waiting for the request to register amazon.alt.

 (or xxx.alt, or ru[ssia].alt, or .alt, which some
 people will do just for fun)

 Unless, of course, you mean that the ISE will adjudicate trademarks,
 define which strings are offensive and determine whether an applicant has
 the right to use the name of a country or geographical entity, thus
 deciding whether a proposal is "trivial or bad" or not.


I don't want to adjudicate names, but I have no problem adjudicating naming 
systems, including transparent attempts to get vanity names.  Since none of 
those are naming systems, they would all get the official "bubye".


But does the IETF, when running a FCFS registry, want to take the legal
liability of your adjudicating? As the IETF will be seen as the sponsor
behind it, as it will have created the procedure that you will use to
say yes or no.

Paul

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

Re: [DNSOP] Possible alt-tld last call?

[Jim Reid]

> On 17 Oct 2022, at 15:12, Joe Abley  wrote:
> 
> Since it's not clear, my favoured approach to this entire subject is to do 
> whatever is the quickest way to resolve the conversation so that this working 
> group can get on with work that, in my opinion, no disrespect intended, is 
> less pointless. I do not believe this proposal does any harm, since I think 
> it will have a practical effect that is the same as doing nothing at all.

I agree with Joe. The WG’s spent too much time on this issue. It has been 
unable to make useful progress. The prospects of reaching an approximation of 
rough consensus are no closer than they were when this was first discussed. I 
think it’s time for the WG to declare defeat and give up.

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

Re: [DNSOP] Possible alt-tld last call?

[Joe Abley]

On 17 Oct 2022, at 10:06, Martin Schanzenbach  wrote:

> Technically, GNS celebrated its 10th birthday in 2022 ;)

:-)

> But back to business: You cannot think both that alternative name systems are
> fleeting trends and at the same time are a serious threat to DNS namespace
> consistency.
> That does not make sense.

I don't think they are serious threats to DNS namespace consistency.

Since it's not clear, my favoured approach to this entire subject is to do 
whatever is the quickest way to resolve the conversation so that this working 
group can get on with work that, in my opinion, no disrespect intended, is less 
pointless. I do not believe this proposal does any harm, since I think it will 
have a practical effect that is the same as doing nothing at all.

My goal is certainly not to put any brakes on if the effect of that is to make 
things move more slowly. I apologise if that's what I have done in suggesting 
to Brian that semantic-free labels do not fit the problem space.


Joe

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

Re: [DNSOP] Possible alt-tld last call?

[Martin Schanzenbach]

On OCT17@07:11, Joe Abley wrote:
> On Oct 16, 2022, at 23:03, Christian Huitema  wrote:
> 
> > The main problem with "giraffe.org" and similar is that the subdomains are 
> > leased, not owned. A glitch in the renewal, and they are grabbed by some 
> > domain catcher and redirected to "my sexy giraffe" or some such.
> 
> On the face of it that seems like a compelling endorsement of the idea, that 
> the biggest risk is one that has proven not to be a significant problem in 
> aggregate for other lesser-known and marginal uses of the DNS such as, oh I 
> don't know, the web or e-mail.
> 
> The risks in this case are even lower than in those use-cases, since a 
> one-time payment secures a renewable ten year lease which is enough to exceed 
> the effective lifetime of any alternative naming scheme seen to date by quite 
> some margin,

Technically, GNS celebrated its 10th birthday in 2022 ;)
But back to business: You cannot think both that alternative name systems are
fleeting trends and at the same time are a serious threat to DNS namespace
consistency.
That does not make sense.

> 
> Despite your endorsement, however, I suspect people will continue to ignore 
> this approach in favour of squatting on top-level labels, a fate that seems 
> likely to be replicated faithfully with alt. That was the point I was 
> apparently not able to refrain from repeating, really.
> 

I know that is a valid opinion to hold and is difficult to refute
without epiric evidence. However, such a PoV also requires a lucid conclusion 
as consequence.
For example, if it is consensus that .alt is a pointless endeavour because
all/most/a lot of alternative name systems will squat TLDs, the question
becomes: Why do you they squat a TLD?

I think that most alternative name systems squat a specific TLD as a
unique identification. They do not try to squat and replace DNS on purpose.
At the same time I can think of no alternative name system that
could not technically squat on the whole DNS namespace in theory.
In conclusion (and I am repeating myself): You have the unique chance
here to funnel this phenomenon in safe and manageable bounds using .alt.
For that you need to understand why the squatting is happening.

What would you rather have? A document you can point to where you can
tell sqatting name systems that they are "doing it wrong" or a document
that cannot hope to have any effect whatsoever on alternative name systems
because it simply reserves a TLD and tells DNS implementations to "don't
go there".

BR
Martin


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

Re: [DNSOP] Possible alt-tld last call?

[Jim Reid]

> On 17 Oct 2022, at 13:00, Independent Submissions Editor (Eliot Lear) 
>  wrote:
> 
> I don't want to adjudicate names, but I have no problem adjudicating naming 
> systems, including transparent attempts to get vanity names.  Since none of 
> those are naming systems, they would all get the official "bubye".

Eliot, I have no doubt you’d always do The Right Thing here. That might not be 
the case for the next ISE. Or the one after. Or... Besides, decisions that 
depend on subjective judgements, no matter how clueful, are likely to cause 
inconsistencies and controversy. That’s best avoided IMO - more so for 
something as icky as ad-hoc TLDs. 

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

Re: [DNSOP] Possible alt-tld last call?

[Independent Submissions Editor (Eliot Lear)]

Hi Vittorio,

On 17.10.22 12:37, Vittorio Bertola wrote:

Well, I'm just waiting for the request to register amazon.alt.

(or xxx.alt, or ru[ssia].alt, or .alt, which some people 
will do just for fun)

Unless, of course, you mean that the ISE will adjudicate trademarks, define which strings 
are offensive and determine whether an applicant has the right to use the name of a 
country or geographical entity, thus deciding whether a proposal is "trivial or 
bad" or not.


I don't want to adjudicate names, but I have no problem adjudicating 
naming systems, including transparent attempts to get vanity names.  
Since none of those are naming systems, they would all get the official 
"bubye".


Eliot

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

Re: [DNSOP] Possible alt-tld last call?

[Joe Abley]

On Oct 16, 2022, at 23:03, Christian Huitema  wrote:

> The main problem with "giraffe.org" and similar is that the subdomains are 
> leased, not owned. A glitch in the renewal, and they are grabbed by some 
> domain catcher and redirected to "my sexy giraffe" or some such.

On the face of it that seems like a compelling endorsement of the idea, that 
the biggest risk is one that has proven not to be a significant problem in 
aggregate for other lesser-known and marginal uses of the DNS such as, oh I 
don't know, the web or e-mail.

The risks in this case are even lower than in those use-cases, since a one-time 
payment secures a renewable ten year lease which is enough to exceed the 
effective lifetime of any alternative naming scheme seen to date by quite some 
margin, and the effect of not renewing presumably only presents risks to 
queries leaked to the DNS which were those that didn't give the user the result 
they were expecting in the first place, anyway.

Despite your endorsement, however, I suspect people will continue to ignore 
this approach in favour of squatting on top-level labels, a fate that seems 
likely to be replicated faithfully with alt. That was the point I was 
apparently not able to refrain from repeating, really.


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

Re: [DNSOP] Possible alt-tld last call?

[Vittorio Bertola]

> Il 17/10/2022 08:44 CEST Eliot Lear  ha scritto:
> 
> Let's please leave Internet lawyering to lawyers.  If people want a 
> legal opinion on this draft, the IETF does have resources for that.
>
> [...]
> 
> No matter what we say in the ALT draft, someone could burden the IETF 
> with a new draft.  People do so every day.  If it gains sufficient 
> support, it would have to be at least considered, no matter the topic.  
> And again, I suspect most of these sorts of documents are more likely to 
> flow to the ISE or perhaps a future IRTF RG.  As the current ISE, that 
> is a burden I would gladly bear, because there is the opportunity to 
> help the Internet community, including the IETF and ICANN.
> 
> I also have no problem rejecting trivial or bad proposals.

Well, I'm just waiting for the request to register amazon.alt.

(or xxx.alt, or ru[ssia].alt, or .alt, which some people 
will do just for fun)

Unless, of course, you mean that the ISE will adjudicate trademarks, define 
which strings are offensive and determine whether an applicant has the right to 
use the name of a country or geographical entity, thus deciding whether a 
proposal is "trivial or bad" or not.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

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

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

Hi Paul!

Good conversation!  I hope we can discuss some of this "in person" 
(whatever that means these days) at IETF 115.


On 17.10.22 04:20, Paul Wouters wrote:

On Sun, 16 Oct 2022, Suzanne Woolf wrote:

1. As far as I can tell, this draft does not comply with RFC 6761. 
This is a problem for two reasons.


One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.


If what you are saying is that we shouldn't get hung up on 6761, then I 
agree.  There are, I think, many ways to deal with the issue that 
Suzanne raised.  One possibility not mentioned was to simply slap an 
"Updates" header on this draft if we think it's necessary, but that 
wouldn't be my first choice.  The bigger issue is below.  IMHO if we can 
kink that out, we have ourselves a ballgame.



2. Having the IETF maintain a registry of pseudo-SLDs concerns me


Me too, I really do believe that the IETF should not do this. It is an
anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
Some alternative sysytems might even use .alt without SLD.
[...]
But also, IETF maintaining a list might open it up for legal liabilities
with alternative naming systems.


Let's please leave Internet lawyering to lawyers.  If people want a 
legal opinion on this draft, the IETF does have resources for that.



So I disagree with Eliot who prefered some kind of FCFS registry that
requires RFCs to get an entry. We do not want alternative naming systems
to require (and burden) the IETF with RFCs.


I am struggling to parse that sentence, but taken together with this...

Basically, .alt is what IETF recommends you should not do, and we 
should not keep
a registry of entries within it. 


We cannot assume that DNS will forever be the only Good approach and 
that all others will forever be Bad. Given that, we as a community are 
obligated to search for better, and to try new things.  As I wrote 
earlier, I do not know that GNS will succeed. I do hope and expect that 
the community will learn something from some deployment experience of 
that protocol so that the next one can be better.


There exist many registries for things the IETF doesn't recommend.  One 
need look no further than TLS 1.3 crypto-suites as an example.


No matter what we say in the ALT draft, someone could burden the IETF 
with a new draft.  People do so every day.  If it gains sufficient 
support, it would have to be at least considered, no matter the topic.  
And again, I suspect most of these sorts of documents are more likely to 
flow to the ISE or perhaps a future IRTF RG.  As the current ISE, that 
is a burden I would gladly bear, because there is the opportunity to 
help the Internet community, including the IETF and ICANN.


I also have no problem rejecting trivial or bad proposals.

Eliot




OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Possible alt-tld last call?

[Christian Huitema]

On 10/16/2022 9:29 AM, Joe Abley wrote:

However, I don't think we are starting from that position. For example we hear 
there is demand for .giraffe for the giraffe naming system described 
athttps://giraffe.org/  because using giraffe.org as an anchor for that naming 
system in the namespace is not acceptable to anybody who cares about GNS.

If giraffe.org doesn't cut the mustard then I have my doubts that 
jduxbenebrnjxudnxznbrnr.alt will satisfy anybody either.

(If giraffe.org can't be tolerated then I also don't see why giraffe.alt is an 
obvious solution, but I sense people are tired of hearing me say that so I'll 
leave it this parenthetical cloak of invisibility and continue whistling 
innocently.)



The main problem with "giraffe.org" and similar is that the subdomains 
are leased, not owned. A glitch in the renewal, and they are grabbed by 
some domain catcher and redirected to "my sexy giraffe" or some such. 
Even without that, the United Organization of Zoos and Safaris can 
complain that they are the rightful owners of all things Giraffe 
related, and take ownership of the name. Maybe, maybe not, but there is 
a lot of uncertainty. If "giraffe.alt" comes with some permanency, then 
".alt" does solve a problem.


-- Christian Huitema

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

Re: [DNSOP] Possible alt-tld last call?

[Paul Wouters]

On Sun, 16 Oct 2022, Suzanne Woolf wrote:


1. As far as I can tell, this draft does not comply with RFC 6761. This is a 
problem for two reasons.


One could advance the 6761bis proposal document first, which would
remove these non-compliance items as those would be no longer needed
(as the bis document proposal removes it as these were not consistently
required in the past). Alternatively, ignoring it wouldn't be the first
time these are ignored, so I guess there is a precedence of ignoring it.


For example, the draft says that DNS resolvers seeing .alt names "do not need 
to look them up in the DNS context”,
but a big part of the point of codifying these names is the assumption that 
queries will leak and DNS servers will
see them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is 
simply not in the public DNS root
zone and the root servers (or better yet, any intermediate resolver) should 
answer “name error”/NXDOMAIN for such
queries. But this should probably be said explicitly, because people who 
configure DNS servers and services
shouldn’t have to guess what’s being implied here. (The WG discussed the 
possibility that such queries should be
blackholed and not answered at all, which is in some ways an obvious answer. 
Clarification of why this was discarded
might also be helpful.)


I think it draft would be better if it said something along the lines
of:

No code changes are required to properly handle leaked queries for .alt
into the DNS, but:

1) Implementations MAY handle .alt specially by (pre)fetching the proofs
   of non-existence of .alt and serve these for all .alt queries.
2) implementations MAY rely on their query minimalization to accomplish 1)
3) or MAY do nothing special, which should work fine but might leak SLD
   queries to the root if the implementation and its querier didn't do query
   minimalization)
4) MAY return FORMERR on .alt queries that in some ways violate the DNS
   specification (so that no code changes are mandatory to support the
   madness .alt queries could bring in, eg >63 SLD names)


2. Having the IETF maintain a registry of pseudo-SLDs concerns me


Me too, I really do believe that the IETF should not do this. It is an
anchor for non-IETF hooks. There is no guarantee of uniqueness in names.
Some alternative sysytems might even use .alt without SLD. Basically,
.alt is what IETF recommends you should not do, and we should not keep
a registry of entries within it.

But also, IETF maintaining a list might open it up for legal liabilities
with alternative naming systems. The whole idea of the ICANN/IETF split
is that ICANN does money and legal stuff, and IETF does codepoints and
running code (with no money) :P

So I disagree with Eliot who prefered some kind of FCFS registry that
requires RFCs to get an entry. We do not want alternative naming systems
to require (and burden) the IETF with RFCs.


3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term 
“registered” differently than common usage.
Judging from searches on RFC 6761 and RFC 8499, it’s ambiguous for DNS naming 
and resolution, and “registered” can
definitely mean something different to a registry or registrar than it does to 
a DNS operator. To people who operate
TLD registries, a name can be “registered” and still may or may not be 
delegated. (“Label” is defined in 8499,
“register” and “delegate” are not.) And, in the reference to “TLD,” it feels 
strange to expand the acronym to
“Top-level label” even if “label” is the right word for what you’re talking 
about.


"pseudo-TLD" is not a good word here to refer to .alt, as other common
SLD's that are open to generic registration are often called
pseudo-TLDs, such as .uk.com.

Paul

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

Re: [DNSOP] Possible alt-tld last call?

[Martin Schanzenbach]

On 16.10.22 12:03, Brian Dickson wrote:
> On Sun, Oct 16, 2022 at 9:08 AM Eliot Lear  wrote:
> 
> > Hiya!
> >
> > Thanks to Suzanne and the chairs for moving things forward.  On this point:
> > On 16.10.22 17:22, Warren Kumari wrote:
> >
> >
> >
> >> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> >> basis that having the IETF “recognize” (if only by recording) such
> >> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> >> supposed recognition of alternate (non-DNS) namespaces as reservations of
> >> the namespace from the shared, common DNS root. We’re still being denounced
> >> in certain corners for .onion. It might be good to have a paragraph calling
> >> out specifically why .alt is not a delegation of a TLD from the DNS root by
> >> the IETF, even though it looks like one. (We didn’t invent this problem,
> >> because we didn’t make the decision that top-level domain labels should be
> >> used by other protocols in a way that led to confusion. But let’s not
> >> propagate it.)
> >>
> >
> >
> > Yup. This is (IMO) the area of the draft where the consensus was the least
> > clear. I still think that it would be useful to have a *purely*
> > informational list saying "Group A says it is using string B and their
> > documentation is at https://foo.example.com"; and "Group X also says that
> > it is using string B and their documentation is at https://bar.example.
> > net". Enough people have pushed back on asking
> > IANA to host this that I think that it should be removed (and I was the one
> > most strongly arguing for it). Obviously it's the DNSOP WGs decision, but I
> > won't argue for keeping it :-)
> >
> >
> > A few points:
> >
> > First, absent at least an FCFS registry there will be no ability to
> > programmatically switch against the label.  If multiple entries exist this
> > is particularly painful.  If no registry exists, then perhaps multiple
> > unofficial registries will pop up and we're in the same boat.  Let's not
> > have that.  That programmatic switch is important.  It allows multiple
> > naming systems to co-exist all the way to the level of the application
> > (e.g., end-to-end) without any ambiguity being introduced.
> >
> > Second, people have been concerned about the possibility of vanity
> > registries.  Requiring an RFC puts an end to that.  I don't think we want
> > to *endorse* any particular approach, but IANA maintains many registries,
> > and nobody has ever taken any of their entries as endorsements.
> >
> > I suspect most of the burden here will fall on the Independent Submissions
> > Editor (currently me) with maybe a little falling on the IRTF, because I
> > doubt we will see a lot of consensus in the IETF for alternate naming
> > systems.  I think some are worried that this will change the nature of the
> > IETF, but to me this confuses names with naming systems.  Creating a naming
> > system is no mean fete.
> >
> > To address the possibility that we DO see a lot of requests, we can create
> > different types of failsafe mechanisms.  They could be any or all of the
> > following:
> >
> >1. If more than one assignment occurs within a year, no assignments
> >may occur in the following year.
> >2. After N assignments, the IAB MAY suspend this procedure if they see
> >evidence of abuse, and refer the matter back to the IETF for further
> >consideration.
> >3. This group can always amend the document based on whatever
> >experiences we see.
> >
> > I'm confident that there are other approaches as well.
> >
> The main problem that a registry is intended to solve, is the collisions
> among apex labels of various alternative naming systems.
> 
> This problem is rooted in the "naming system group chosen" aspect.
> 
> I think there is a relatively simple technological solution to the naming
> system label collision problem.
> 
> Consider what the registry would basically consist of:
> 
>- semantic label (what would currently be used as the apex label, e.g.
>"foo.alt")
>- project URI
> 
> Note the following characteristics of these elements:
> 
>- The apex label is a "switch", but is otherwise not actually used (or
>meaningful) within the naming system (i.e. it is an arbitrary element, and
>usage is basically limited to a binary "compare" to any input to the
>non-DNS resolution system of the project)
>- The URIs of different systems will, by definition, be distinct (i.e.
>unique to the system)
> 
> The obvious (to me at least) solution is to generate the apex label
> programmatically, e.g. encode the URI as the label to be used as the
> switch, rather than the name system's potentially ambiguous semantic name.
> For example, using a hash function, such as sha2-256, with output encoded
> as base32hex.
> (This is just an example; any suitable function that takes URI as input and
> produces an ASCII DNS-compatible label as output would suffice

Re: [DNSOP] Possible alt-tld last call?

[Joe Abley]

Op 16 okt. 2022 om 15:03 heeft Brian Dickson  
het volgende geschreven:

> For example, using a hash function, such as sha2-256, with output encoded as 
> base32hex. 
> (This is just an example; any suitable function that takes URI as input and 
> produces an ASCII DNS-compatible label as output would suffice.)

If we start from the position that names in this shared namespace don't need to 
be semantically meaningful to humans then this whole problem space becomes a 
whole lot easier, or perhaps doesn't even rise to the level of "problem". See 
also 98% of the work done by the ICANN community and arguably the entire 
business models of registries and registrars.

However, I don't think we are starting from that position. For example we hear 
there is demand for .giraffe for the giraffe naming system described at 
https://giraffe.org/ because using giraffe.org as an anchor for that naming 
system in the namespace is not acceptable to anybody who cares about GNS.

If giraffe.org doesn't cut the mustard then I have my doubts that 
jduxbenebrnjxudnxznbrnr.alt will satisfy anybody either.

(If giraffe.org can't be tolerated then I also don't see why giraffe.alt is an 
obvious solution, but I sense people are tired of hearing me say that so I'll 
leave it this parenthetical cloak of invisibility and continue whistling 
innocently.)


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

Re: [DNSOP] Possible alt-tld last call?

[Brian Dickson]

On Sun, Oct 16, 2022 at 9:08 AM Eliot Lear  wrote:

> Hiya!
>
> Thanks to Suzanne and the chairs for moving things forward.  On this point:
> On 16.10.22 17:22, Warren Kumari wrote:
>
>
>
>> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
>> basis that having the IETF “recognize” (if only by recording) such
>> pseudo-delegations may serve to attract unwanted attention to the IETF’s
>> supposed recognition of alternate (non-DNS) namespaces as reservations of
>> the namespace from the shared, common DNS root. We’re still being denounced
>> in certain corners for .onion. It might be good to have a paragraph calling
>> out specifically why .alt is not a delegation of a TLD from the DNS root by
>> the IETF, even though it looks like one. (We didn’t invent this problem,
>> because we didn’t make the decision that top-level domain labels should be
>> used by other protocols in a way that led to confusion. But let’s not
>> propagate it.)
>>
>
>
> Yup. This is (IMO) the area of the draft where the consensus was the least
> clear. I still think that it would be useful to have a *purely*
> informational list saying "Group A says it is using string B and their
> documentation is at https://foo.example.com"; and "Group X also says that
> it is using string B and their documentation is at https://bar.example.
> net". Enough people have pushed back on asking
> IANA to host this that I think that it should be removed (and I was the one
> most strongly arguing for it). Obviously it's the DNSOP WGs decision, but I
> won't argue for keeping it :-)
>
>
> A few points:
>
> First, absent at least an FCFS registry there will be no ability to
> programmatically switch against the label.  If multiple entries exist this
> is particularly painful.  If no registry exists, then perhaps multiple
> unofficial registries will pop up and we're in the same boat.  Let's not
> have that.  That programmatic switch is important.  It allows multiple
> naming systems to co-exist all the way to the level of the application
> (e.g., end-to-end) without any ambiguity being introduced.
>
> Second, people have been concerned about the possibility of vanity
> registries.  Requiring an RFC puts an end to that.  I don't think we want
> to *endorse* any particular approach, but IANA maintains many registries,
> and nobody has ever taken any of their entries as endorsements.
>
> I suspect most of the burden here will fall on the Independent Submissions
> Editor (currently me) with maybe a little falling on the IRTF, because I
> doubt we will see a lot of consensus in the IETF for alternate naming
> systems.  I think some are worried that this will change the nature of the
> IETF, but to me this confuses names with naming systems.  Creating a naming
> system is no mean fete.
>
> To address the possibility that we DO see a lot of requests, we can create
> different types of failsafe mechanisms.  They could be any or all of the
> following:
>
>1. If more than one assignment occurs within a year, no assignments
>may occur in the following year.
>2. After N assignments, the IAB MAY suspend this procedure if they see
>evidence of abuse, and refer the matter back to the IETF for further
>consideration.
>3. This group can always amend the document based on whatever
>experiences we see.
>
> I'm confident that there are other approaches as well.
>
The main problem that a registry is intended to solve, is the collisions
among apex labels of various alternative naming systems.

This problem is rooted in the "naming system group chosen" aspect.

I think there is a relatively simple technological solution to the naming
system label collision problem.

Consider what the registry would basically consist of:

   - semantic label (what would currently be used as the apex label, e.g.
   "foo.alt")
   - project URI

Note the following characteristics of these elements:

   - The apex label is a "switch", but is otherwise not actually used (or
   meaningful) within the naming system (i.e. it is an arbitrary element, and
   usage is basically limited to a binary "compare" to any input to the
   non-DNS resolution system of the project)
   - The URIs of different systems will, by definition, be distinct (i.e.
   unique to the system)

The obvious (to me at least) solution is to generate the apex label
programmatically, e.g. encode the URI as the label to be used as the
switch, rather than the name system's potentially ambiguous semantic name.
For example, using a hash function, such as sha2-256, with output encoded
as base32hex.
(This is just an example; any suitable function that takes URI as input and
produces an ASCII DNS-compatible label as output would suffice.)

It would still be reasonable to have a registry somewhere of a table of
"name, URI, hashed-URI-label".
The difference is that it would no longer matter what order entries are
added, and collisions cannot occur.

Having two projects that

Re: [DNSOP] Possible alt-tld last call?

[Eliot Lear]

Hiya!

Thanks to Suzanne and the chairs for moving things forward.  On this point:

On 16.10.22 17:22, Warren Kumari wrote:



2. Having the IETF maintain a registry of pseudo-SLDs concerns me
on the basis that having the IETF “recognize” (if only by
recording) such pseudo-delegations may serve to attract unwanted
attention to the IETF’s supposed recognition of alternate
(non-DNS) namespaces as reservations of the namespace from the
shared, common DNS root. We’re still being denounced in certain
corners for .onion. It might be good to have a paragraph calling
out specifically why .alt is not a delegation of a TLD from the
DNS root by the IETF, even though it looks like one. (We didn’t
invent this problem, because we didn’t make the decision that
top-level domain labels should be used by other protocols in a way
that led to confusion. But let’s not propagate it.)



Yup. This is (IMO) the area of the draft where the consensus was the 
least clear. I still think that it would be useful to have a *purely* 
informational list saying "Group A says it is using string B and their 
documentation is at https://foo.example.com"; and "Group X also says 
that it is using string B and their documentation is at 
https://bar.example. net". Enough people 
have pushed back on asking IANA to host this that I think that it 
should be removed (and I was the one most strongly arguing for it). 
Obviously it's the DNSOP WGs decision, but I won't argue for keeping 
it :-)



A few points:

First, absent at least an FCFS registry there will be no ability to 
programmatically switch against the label.  If multiple entries exist 
this is particularly painful.  If no registry exists, then perhaps 
multiple unofficial registries will pop up and we're in the same boat.  
Let's not have that.  That programmatic switch is important.  It allows 
multiple naming systems to co-exist all the way to the level of the 
application (e.g., end-to-end) without any ambiguity being introduced.


Second, people have been concerned about the possibility of vanity 
registries.  Requiring an RFC puts an end to that.  I don't think we 
want to *endorse* any particular approach, but IANA maintains many 
registries, and nobody has ever taken any of their entries as endorsements.


I suspect most of the burden here will fall on the Independent 
Submissions Editor (currently me) with maybe a little falling on the 
IRTF, because I doubt we will see a lot of consensus in the IETF for 
alternate naming systems.  I think some are worried that this will 
change the nature of the IETF, but to me this confuses names with naming 
systems.  Creating a naming system is no mean fete.


To address the possibility that we DO see a lot of requests, we can 
create different types of failsafe mechanisms.  They could be any or all 
of the following:


1. If more than one assignment occurs within a year, no assignments may
   occur in the following year.
2. After N assignments, the IAB MAY suspend this procedure if they see
   evidence of abuse, and refer the matter back to the IETF for further
   consideration.
3. This group can always amend the document based on whatever
   experiences we see.

I'm confident that there are other approaches as well.

Eliot


OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Possible alt-tld last call?

[Warren Kumari]

On Sun, Oct 16, 2022 at 11:03 AM, Suzanne Woolf  wrote:

> Dear Colleagues,
>
>
> The chairs have gotten a couple of requests, off-list and on, for a WGLC
> on draft-ietf-dnsop-alt-tld.
>
> We’ve reviewed the current draft closely and have some concerns that we
> feel need to be resolved before any effort to move the draft forward.
> (Suzanne wrote this but it’s been discussed among all of the co-chairs.)
>
> 1. As far as I can tell, this draft does not comply with RFC 6761. This is
> a problem for two reasons.
>
> First, this creates a process problem in that RFC 6761 is the
> standards-track document that specifies how the SUDN registry is to be
> administered, so a request that doesn’t meet the requirements in 6761 can’t
> (or at least shouldn’t) go into the registry.
>
> RFC 6761 section 4 asserts:
>
> The specification also MUST state, in each of the seven "Domain Name
> Reservation Considerations" categories
> below, what special treatment, if any, is to be applied.
>
>
>
> The alt-tld draft ignores this MUST, without explanation (unless I missed
> it).
>
> The substantive issue is that the questions in Section 5 are there to make
> sure there’s a full description of the expected handling of a proposed name
> by the assorted components that take part in DNS operations and protocol.
> The draft answers at least some of the Section 5 questions, but the answers
> are largely implied.
>
> For example, the draft says that DNS resolvers seeing .alt names "do not
> need to look them up in the DNS context”, but a big part of the point of
> codifying these names is the assumption that queries will leak and DNS
> servers will see them. (“Do not need to” isn’t even “SHOULD not”.) It’s
> implied that .alt is simply not in the public DNS root zone and the root
> servers (or better yet, any intermediate resolver) should answer “name
> error”/NXDOMAIN for such queries. But this should probably be said
> explicitly, because people who configure DNS servers and services shouldn’t
> have to guess what’s being implied here. (The WG discussed the possibility
> that such queries should be blackholed and not answered at all, which is in
> some ways an obvious answer. Clarification of why this was discarded might
> also be helpful.)
>
> So, the current draft isn’t meeting the requirements for the registry, and
> also doesn’t clearly answer substantive questions about what DNS operators
> are expected to do. This makes me uncomfortable doing a WGLC without a new
> rev. It would be Rob Wilton’s call of course (as AD for this draft,
> substituting for Warren) but I’m really uneasy with a WGLC without those
> changes— they seem rather too large to punt for a post-WGLC version.
>


Yup. The version 2 back (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-15) has all
of the text / answers, and it would be trivial to put it back. It may
require some minor word-smithing to get the wording to align perfectly, but
that should be simple enough.

On the "what should resolvers do?" question, the prior text said:
"4.  Caching DNS servers SHOULD NOT recognize these names as special
   and should not perform any special handling with them."

This changed from -07  (
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-07), which
said:
"4.  Caching DNS servers SHOULD recognize these names as special and
   SHOULD NOT, by default, attempt to look up NS records for them,
   or otherwise query authoritative DNS servers in an attempt to
   resolve these names.  Instead, caching DNS servers SHOULD
   generate immediate negative responses for all such queries."

This reason for this change was that we had proposed adding this to the
"Locally Served Zones" registry, and so there wasn't expected to be any
"special" handling or knowledge by implementations.
Perhaps we could clarify this somehow….



> 2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the
> basis that having the IETF “recognize” (if only by recording) such
> pseudo-delegations may serve to attract unwanted attention to the IETF’s
> supposed recognition of alternate (non-DNS) namespaces as reservations of
> the namespace from the shared, common DNS root. We’re still being denounced
> in certain corners for .onion. It might be good to have a paragraph calling
> out specifically why .alt is not a delegation of a TLD from the DNS root by
> the IETF, even though it looks like one. (We didn’t invent this problem,
> because we didn’t make the decision that top-level domain labels should be
> used by other protocols in a way that led to confusion. But let’s not
> propagate it.)
>


Yup. This is (IMO) the area of the draft where the consensus was the least
clear. I still think that it would be useful to have a *purely*
informational list saying "Group A says it is using string B and their
documentation is at https://foo.example.com"; and "Group X also says that it
is using string B and their documentation is at https://bar.examp

[DNSOP] Possible alt-tld last call?

[Suzanne Woolf]

Dear Colleagues,


The chairs have gotten a couple of requests, off-list and on, for a WGLC on 
draft-ietf-dnsop-alt-tld.

We’ve reviewed the current draft closely and have some concerns that we feel 
need to be resolved before any effort to move the draft forward. (Suzanne wrote 
this but it’s been discussed among all of the co-chairs.)

1. As far as I can tell, this draft does not comply with RFC 6761. This is a 
problem for two reasons.

First, this creates a process problem in that RFC 6761 is the standards-track 
document that specifies how the SUDN registry is to be administered, so a 
request that doesn’t meet the requirements in 6761 can’t (or at least 
shouldn’t) go into the registry.

RFC 6761 section 4 asserts:

The specification also MUST state, in each of the seven "Domain Name 
Reservation Considerations" categories
below, what special treatment, if any, is to be applied.

The alt-tld draft ignores this MUST, without explanation (unless I missed it).

The substantive issue is that the questions in Section 5 are there to make sure 
there’s a full description of the expected handling of a proposed name by the 
assorted components that take part in DNS operations and protocol. The draft 
answers at least some of the Section 5 questions, but the answers are largely 
implied.

For example, the draft says that DNS resolvers seeing .alt names "do not need 
to look them up in the DNS context”, but a big part of the point of codifying 
these names is the assumption that queries will leak and DNS servers will see 
them. (“Do not need to” isn’t even “SHOULD not”.) It’s implied that .alt is 
simply not in the public DNS root zone and the root servers (or better yet, any 
intermediate resolver) should answer “name error”/NXDOMAIN for such queries. 
But this should probably be said explicitly, because people who configure DNS 
servers and services shouldn’t have to guess what’s being implied here. (The WG 
discussed the possibility that such queries should be blackholed and not 
answered at all, which is in some ways an obvious answer. Clarification of why 
this was discarded might also be helpful.)

So, the current draft isn’t meeting the requirements for the registry, and also 
doesn’t clearly answer substantive questions about what DNS operators are 
expected to do. This makes me uncomfortable doing a WGLC without a new rev. It 
would be Rob Wilton’s call of course (as AD for this draft, substituting for 
Warren) but I’m really uneasy with a WGLC without those changes— they seem 
rather too large to punt for a post-WGLC version.

2. Having the IETF maintain a registry of pseudo-SLDs concerns me on the basis 
that having the IETF “recognize” (if only by recording) such pseudo-delegations 
may serve to attract unwanted attention to the IETF’s supposed recognition of 
alternate (non-DNS) namespaces as reservations of the namespace from the 
shared, common DNS root. We’re still being denounced in certain corners for 
.onion. It might be good to have a paragraph calling out specifically why .alt 
is not a delegation of a TLD from the DNS root by the IETF, even though it 
looks like one. (We didn’t invent this problem, because we didn’t make the 
decision that top-level domain labels should be used by other protocols in a 
way that led to confusion. But let’s not propagate it.)

3. A couple of nits (p. 2): the definition of “pseudo-TLD” uses the term 
“registered” differently than common usage. Judging from searches on RFC 6761 
and RFC 8499, it’s ambiguous for DNS naming and resolution, and “registered” 
can definitely mean something different to a registry or registrar than it does 
to a DNS operator. To people who operate TLD registries, a name can be 
“registered” and still may or may not be delegated. (“Label” is defined in 
8499, “register” and “delegate” are not.) And, in the reference to “TLD,” it 
feels strange to expand the acronym to “Top-level label” even if “label” is the 
right word for what you’re talking about.

Thanks to the editors and the WG for considering these comments.


Best,
Suzanne
(For the chairs)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop