Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 1 Apr 2017 15:17:27 -0500

On Sun, Mar 12, 2017 at 07:20:55PM -0400,
 Suzanne Woolf <[email-masked]> wrote 
 a message of 92 lines which said:

> This message opens a Working Group Last Call for:
> 
> "The ALT Special Use Top Level Domain"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/>

I've read -08 and I believe I understand this draft. I'm not convinced
it's useful (most users of alternative resolution systems won't use it
and, anyway, I'm not even sure it will be added in the Special-Use
registry, which was wrongly frozen by the IESG) but I don't see big
issues with the draft, it seems to me it correctly describes the new
TLD.

Editorial :

Section 1:

"and that should not be resolved" I cannot parse it. Missing "it"?

Section 5 :

After "and anyone watching queries along the path", add a reference to
RFC 7626?

Normative references:

Why is RFC 6303 a normative reference? It is no longer used.

Why is RFC 7686 a normative reference? It is just an example.

---

From: George Michaelson <[email-masked]>
Date: Mon, 3 Apr 2017 19:27:32 -0500

isn't this OBE and it's alt.arpa now?

Serious question btw. I do not think that this document can proceed
without significant re-drafting to a 2LD if that is the case.

G

On Sat, Apr 1, 2017 at 3:17 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 03 Apr 2017 17:51:50 -0700

> isn't this OBE and it's alt.arpa now?

No.

> without significant re-drafting to a 2LD if that is the case.

Are you saying that because of:
    https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/
If so, I suspect you read it wrong. My reading is that the IAB is only 
saying that names that are supposed to act like DNS names (that is, to 
exist in the public DNS) need to be under .arpa. This draft explicitly 
is about non-DNS contexts.

--Paul Hoffman

---

From: George Michaelson <[email-masked]>
Date: Mon, 3 Apr 2017 20:02:19 -0500

The only reference to ICANN delegation process is in an [Ed: note]
which feels to me to be wrong: its a first class issue, and should be
addressed directly, not as editorial.

Secondly, The authors make a judgement call in this block that they
feel requesting delegation is not required. I don't feel the consensus
was that strong actually, but you know, I guess I could be wrong on
that.

Thirdly the draft contains no language which actually explains why a
TLD is required, rather than a deterministic string which denotes 'not
in the DNS' -It may be blindingly obvious to you it has to be a TLD,
but given that the entry of DNS label-strings into the DNS is through
software, and given that at some point, the simple un-parsed string
'something.alt' has to be presented, I would have expected an
explanation why 'alt.arpa' as a pattern match in the DNS entry can't
work as well as 'alt'. Bear in mind, that the argumentative text
states .ONION is a comparator, so poses the problem back on (future)
s/w authors that currently seek a TLD as a pattern match, and now have
to code to ONION.ALT as a pattern match (the match on ALT implies
parsing it off, to denote ONION as a non-DNS label, or embedding of
ALT in the non-DNS namespace) so the dots-parsing problem exists for
the s/w owners *come what may*

Lastly, I think the IAB note pretty strongly goes to 'we dont do that
any more' and I think the draft at the bare minimum should say why
this draft is special, against that letter.  You make a compelling and
simple case: because its specifically NOT-DNS, not public DNS, its not
relevant. Ok, then say so. 'we didn't say so because it wasn't
relevant' feels pretty weak to me.

I can do this as a nit in the GIT if you prefer.

-G

On Mon, Apr 3, 2017 at 7:51 PM, Paul Hoffman <[email-masked]> wrote:
> saying that names that are supposed to act like DNS names (that is, to exist
> in the public DNS) need to be under .arpa. This draft explicitly is about
> non-DNS contexts.
>
> --Paul Hoffman

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 03 Apr 2017 18:13:42 -0700

> addressed directly, not as editorial.

The note says why the ICANN delegation process is *not* used. As the 
Abstract says, these notes will be removed before publication.

> was that strong actually, but you know, I guess I could be wrong on

This is what WG Last Call is for. If you want to reverse what's in the 
current draft, you need to say so explicitly, hopefully providing text 
so that this WG doesn't end up with the sloppy text that the HOMENET WG 
got.

FWIW, I thought that the authors got this version right. The discussion 
didn't converge on strong use cases for delegation, and there were 
strong reasons against. But this is a fair time to open that again.

> the s/w owners *come what may*

If you have such proposed text, that would be useful to evaluate.

> any more'

Please define "that". If you mean "using TLDs that are not delegated", 
please show in the IAB statement where you get that impression. I didn't 
see it, but that doesn't mean it isn't there.

> and I think the draft at the bare minimum should say why

What you are proposing is not a "nit", but a fundamental change 
throughout the document.

--Paul Hoffman

---

From: George Michaelson <[email-masked]>
Date: Mon, 3 Apr 2017 20:24:44 -0500

> Abstract says, these notes will be removed before publication.

Which I think is wrong. The notes are material. I think they should
uplift to the body of the document so there is a permanent RFC record
of why the decison to not go to ICANN delegation was made.

> current draft, you need to say so explicitly, hopefully providing text so
> that this WG doesn't end up with the sloppy text that the HOMENET WG got.
>
> didn't converge on strong use cases for delegation, and there were strong
> reasons against. But this is a fair time to open that again.

No, I don't think I can demonstrate failure to converge on strong use
cases for delegation is weak consensus. If nobody comes forward with a
rock-solid reason to delegate, then I think its fair to call it 'not
delegated'

> If you have such proposed text, that would be useful to evaluate.

The problem is, I don't think I can, because I cannot argue strongly
FOR a TLD, because i believe the impetus for a TLD is aesthetic and
(as for homenet btw) driven by end user UI perception issues.

I believe that the behaviour here is going to drive to string
recognition inside code to switch:

Pythonic pseudocode:
    if fqdn.endswith('.alt'):
       do_non_dns_lookup(fqdn)
    else:
       gethostbyname(fqdn)

type decision. Thats what it think this document drives to. And, given
that, I think endswith('.alt') can be endswith(STUBNAME) and somewhere
else, STUBNAME='.alt.arpa' is going to work.

> please show in the IAB statement where you get that impression. I didn't see
> it, but that doesn't mean it isn't there.

Actually you're probably right. the statement says explicitly "Other
names in the Special-Use Domain Names registry are intended for
exclusion from DNS resolution. An entry in the Special-Use Domain
Names Registry that does not require DNS resolution does not require
the registrant to control the relevant name in the DNS." So the
language there goes directly to BECAUSE you intend requesting no
delegation, you make the cut.

Ie, the fact you've decided consensus wasn't reached to delegated, and
therefore decide to say NOT DELEGATE is directly relevant to the
statement from the IAB, because it goes to the language which says 'if
not in the DNS, and a TLD, put it in the SUDN'

So if you continue to maintain this HAS to be a TLD, (which btw,
requires justifying) AND if you specifically require it NOT to be in
the DNS, then the IAB statement should be cited to drive to its
inclusion in the registry.

> What you are proposing is not a "nit", but a fundamental change throughout
> the document.

No, I'd like to back off that. If you do language to specify why it
has to be a TLD, and if you cite the IAB, I think the document will be
integral and complete.

in other words "I was wrong" but "now I'm right"

cheers

-G

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 3 Apr 2017 22:40:35 -0400

Hi,

On one specific point:

> On Apr 3, 2017, at 9:02 PM, George Michaelson <[email-masked]> wrote:
> 

I’m fine with “the draft needs to be updated with reference to the relevance of .arpa” as a WGLC comment, so the below is intended as contributing to the discussion, not repressing it.

On the intentions and role of the IAB: 

An IAB statement isn’t an IETF document of any kind, never mind a standards track document, and can’t tell the IETF what to do— including this WG.  So the IAB certainly can’t say “We don’t do that any more” as a policy statement about an IETF registry such as the special use names registry. However, RFC 3172 is an IETF BCP, and provides direction to the IETF and the IAB (as admin authority for .arpa) on the requirements that should be followed for a delegation in .arpa. So as a WGLC comment, this suggests the addition of a reference to RFC 3172 and the applicability of the .arpa policy there to the justification for alt.

It’s my view that, as Paul says, the IAB note was written about a different case than the alt-tld draft was: the IAB was attempting to point out an alternative to asking for a delegation in the root zone in the case that a special use name is supposed to be resolvable in the DNS. The alt-tld draft is about names that aren’t intended to be resolvable in the DNS in the first place.

However, since I was a contributor to the IAB document, it puts me in an awkward position to be interpreting it for DNSOP on behalf of the IAB. If further clarification on the IAB statement would be useful, we should explicitly request it.

best,
Suzanne

---

From: George Michaelson <[email-masked]>
Date: Tue, 4 Apr 2017 11:47:48 +0900

I could take it either way. narrow doc is narrow purpose? don't ref it.

doc is highly visible, will be (mis)interpreted as being relevant?
disavow it (which implies ref it)

doc is highly visible, problem next door? Seek guidance.

-G

---

From: "John Levine" <[email-masked]>
Date: 4 Apr 2017 15:00:40 -0000

>without significant re-drafting to a 2LD if that is the case.

Like Paul Hoffman, I read the it the opposite way.  The draft says
about as clearly as it can that foo.alt is for names that are handled
completely outside the DNS.  The IAB draft says that foo.arpa is where
you put names that are handled within the DNS but with quirks.  I
don't see any conflict.

I suppose it would be good for the draft to reference the IAB statement to
say that's something else, not what .alt is about.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Apr 2017 17:03:33 -0400

Hi,

Thanks for the review.

> "and that should not be resolved" I cannot parse it. Missing "it"?

Yes.

> After "and anyone watching queries along the path", add a reference to

A good idea.  Thanks.

> Why is RFC 6303 a normative reference? It is no longer used.

Should be removed.  Thanks.

> Why is RFC 7686 a normative reference? It is just an example.

Yeah, we should move it.  Thanks.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 4 Apr 2017 17:09:34 -0400

Hi George,

On Mon, Apr 03, 2017 at 08:02:19PM -0500, George Michaelson wrote:
> The only reference to ICANN delegation process

Why should there be any reference to any ICANN delegation process?
The name is to be added to the special-use registry, taking it out of
conteplation as a DNS name.

> was that strong actually, but you know, I guess I could be wrong on

We understood the WG to have decided, in my view correctly, that this
name was exclusively for use outside the DNS.  Section 3 makes that
perfectly clear, I think:

   This document reserves the ALT label, using the [RFC6761] process,
   for use as an unmanaged pseudo-TLD namespace.  The ALT label MAY be
   used in any domain name as a pseudo-TLD to signify that this is an
   alternative (non-DNS) namespace, and should not be looked up in a DNS
   context.
 
> TLD is required

The simple reason is to save octets, since these names need to fit in
DNS protocol slots and therefore are subject to the 255 octet limit.
We did remove that discussion somewhere along the line; I'm prepared
to add it back if you like.  Certainly the name could go under arpa,
but when we discussed it before the conclusion was that it took too
many octets that way.

> Lastly, I think the IAB note pretty strongly goes to 'we dont do that

I understand the IAB note to be about the case where the name is
intended for use with the DNS, so I don't think it is relevant to this
use case.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 7 Apr 2017 09:38:08 -0400

Hi,

We had initially scheduled the WGLC on this document to be over by now. However, the flurry of activity around the review we were asked to do on the homenet-dot draft, and the general traffic level on the list during IETF 98, suggested to the chairs that we should extend the WGLC.

We’re hereby formally extending it to next Wednesday, April 12.

As always for WGLC— we need to hear both support and opposition for taking this draft to the next step in the process.

thanks,
Suzanne  & TIm

> On Apr 1, 2017, at 4:17 PM, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 10 Apr 2017 10:38:09 -0400

I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of the document as Informational, while it is listed in the datatracker as "In WG Last Call: Proposed Standard".  

There are arguments in favor of each status.  The relevant text is in section 5 of RFC 6761:

   An IETF "Standards Action" or "IESG Approval" document specifying
   some new naming behaviour, which requires a Special-Use Domain Name
   be reserved to implement this desired new behaviour, needs to contain
   a subsection of the "IANA Considerations" section titled "Domain Name
   Reservation Considerations" giving answers in the seven categories
   listed below.

Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the "Standards Action" requirement.  However, Proposed Standard may not be appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not specify a new protocol, as such.  draft-ietf-dnsop-alt-tld-08 does specify certain behaviors for components of the Internet, which could be thought of as providing for interoperability so that Proposed Standard status would be appropriate.

On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as Informational would require an "IESG Approval" document to meet the requirements of RFC 6761.  A short sentence added to draft-ietf-dnsop-alt-tld-08 is likely all that would be needed, to the effect of "The IESG has reviewed this document and approves of the request to add .alt to the Special Use Domain Names registry."

In any event, in my opinion the WG needs to express its explicit consensus about its choice of intended status for draft-ietf-dnsop-alt-tld-08.

- Ralph

> On Apr 7, 2017, at 9:38 AM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi,
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 10 Apr 2017 10:35:12 -0700

On 10 Apr 2017, at 7:38, Ralph Droms wrote:

> I see that draft-ietf-dnsop-alt-tld-08 gives the intended status of 
> the document as Informational, while it is listed in the datatracker 
> as "In WG Last Call: Proposed Standard".
>
> Publishing draft-ietf-dnsop-alt-tld-08 as Proposed Standard meets the 
> "Standards Action" requirement.  However, Proposed Standard may not be 
> appropriate for draft-ietf-dnsop-alt-tld-08, as the document does not 
> specify a new protocol, as such.  draft-ietf-dnsop-alt-tld-08 does 
> specify certain behaviors for components of the Internet, which could 
> be thought of as providing for interoperability so that Proposed 
> Standard status would be appropriate.
>
> On the other hand, publishing draft-ietf-dnsop-alt-tld-08 as 
> Informational would require an "IESG Approval" document to meet the 
> requirements of RFC 6761.  A short sentence added to 
> draft-ietf-dnsop-alt-tld-08 is likely all that would be needed, to the 
> effect of "The IESG has reviewed this document and approves of the 
> request to add .alt to the Special Use Domain Names registry."
>
> In any event, in my opinion the WG needs to express its explicit 
> consensus about its choice of intended status for 
> draft-ietf-dnsop-alt-tld-08.

Given that most people don't understand the difference between levels, 
it would take less explanation to make this Standards Track to meet 
"Standards Action" in RFC 6761. But if people want to leave this as 
Informational, I agree with Ralph that a sentence like he has given 
(probably at the end of the Introduction) would be needed for clarity.

--Paul Hoffman

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Apr 2017 15:15:39 -0400

I have some editorial comments on draft-ietf-dnsop-alt-tld-08.  I don't think any of these suggestions would make material changes to the meaning of the document, but would improve consistency, readability, etc.

Given the multiple meanings of the word "context", the first sentence of the Abstract might be clearer as:

   This document reserves a string (ALT) to be used as a TLD label for
   domain names intended for non-DNS resolution systems.

Would it be clearer to use "domain name" and cite RFC 7719 in the second sentence of section 1, instead of "Names that look like DNS names (a series of labels separated with dots) [...]"

In section 1, s/Special Use Domain/Special Use Domain Name/ to match the name of the IANA registry.

In section 1.2, I suggest citing RFC 7719 for definitions of "domain name" and "TLD".

In section 2, s/looked up/resolved/

Should RFC 2119 terms (e.g., "should not" and "SHOULD NOT") be capitalized consistently in section 4.1?

I don't think an RF 2119 "SHOULD" is appropriate for advice to human operators of DNS servers.

In section 5, I think the parenthetical would be better written without the parentheses, as the text in parentheses seems to be as important as the rest of the text.

- Ralph

> On Apr 10, 2017, at 10:38 AM, Ralph Droms <[email-masked]> wrote:
>