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

"Paul Hoffman" <paul.hoffman@vpnc.org> Tue, 04 April 2017 01:13 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6912702E for <dnsop@ietfa.amsl.com>; Mon, 3 Apr 2017 18:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlKAORDGIKJe for <dnsop@ietfa.amsl.com>; Mon, 3 Apr 2017 18:13:45 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2271F1252BA for <dnsop@ietf.org>; Mon, 3 Apr 2017 18:13:45 -0700 (PDT)
Received: from [169.254.126.148] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v341DU09057824 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Apr 2017 18:13:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.126.148]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: George Michaelson <ggm@algebras.org>
Cc: dnsop <dnsop@ietf.org>
Date: Mon, 03 Apr 2017 18:13:42 -0700
Message-ID: <3CEFC70C-949E-4D48-B2B1-17D87D95543F@vpnc.org>
In-Reply-To: <CAKr6gn2xooGe2haYur70eiNrxxkGO603-YRJMr2DNKouWJQ3nw@mail.gmail.com>
References: <333CCE99-82E2-44C9-97ED-2222540097ED@gmail.com> <20170401201727.GA5948@laperouse.bortzmeyer.org> <CAKr6gn3uPHaGi3zmYmzAkuadjAyPMYGqZ5jHZp=rFo+DMLm7AA@mail.gmail.com> <3C85C5DB-7F1A-45B7-BE2A-926065F2C266@vpnc.org> <CAKr6gn2xooGe2haYur70eiNrxxkGO603-YRJMr2DNKouWJQ3nw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kekLmblAjjNSIFScrKhaHcIKIQo>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Apr 2017 01:13:47 -0000

On 3 Apr 2017, at 18:02, George Michaelson wrote:

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

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

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

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.

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

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

> Lastly, I think the IAB note pretty strongly goes to 'we dont do that
> 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
> 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.

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

--Paul Hoffman