Re: [DNSOP] .arpa

George Michaelson <ggm@algebras.org> Mon, 27 March 2017 03:47 UTC

Return-Path: <ggm@algebras.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 E47C5127241 for <dnsop@ietfa.amsl.com>; Sun, 26 Mar 2017 20:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
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 i5PHo3RpLzII for <dnsop@ietfa.amsl.com>; Sun, 26 Mar 2017 20:47:34 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46307127342 for <dnsop@ietf.org>; Sun, 26 Mar 2017 20:47:34 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id z204so38030642vkd.1 for <dnsop@ietf.org>; Sun, 26 Mar 2017 20:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2716mz2+vyyAyd/jCEE01H2MbvAR0VS+RfGGlRkpss0=; b=lpkVfAYKV1qcryBjrFy0QeDW0b3wsuM1w2w3u5lXWiW3KivuLDEBPDYvbzH/qs5dbp 1Z5h1CSClx2dSw9PYhWhIvRC3uGF1XmRZq5nytxDqyXBxqJeS/j+gGGdLfgCuFLQDx8H DCYJdn6FJI/BUj0z/y8bj668+IgMQQ59WG0cp81eXVR/wVCAFmmb8TQZoRpHO7whBYLX tynKfFEKT/m+H5mU1rXZcEilCl8g5SXeUsthfX2loK5bSUErnhrM6XmSOVPLuLwHBtcr MJOQvFuLMXEXHoQnwZvEtqjp4ab+w06vaAbUDM5WLZ9e8MTqopE7T4EL/oX2ryurWbkS xbWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2716mz2+vyyAyd/jCEE01H2MbvAR0VS+RfGGlRkpss0=; b=UC11mwo18SbOrAu/LPA7kchkc8mBLJ69/HNEsir6x4dczlqmZL80/iAMSXBrakJFvI r4E2Nztqlj3bNIMq1/3y5fSVSZEC//NMV4wAoTpi2l6FvcGOEoTfxk1KBApZmwkt6uMD y8MgK3cnEefZ/vCxRGXVgdPV6wNY5oVZ7+Xu/7h00d9jreknMlshycY4hr8TTjaW1gm+ g5XHaHPFqWZsGFO0shh7QLPpFHfmwTZOAlTsemsmWcjT7JW288ogKurQgqqNchg2IQVv 5UeT6g+MmVOFJoLVNBNx2MBwqrb0Fju43hY5Y9tRF629JcgQ8AM6pUYZsakJUxXO261s Ja0g==
X-Gm-Message-State: AFeK/H1JtZAPf4HzrZ9zq4fSzBCvyHkw7qW/7tetu7eOyTYu9k5M7BpAea7iJ2UVhqaKEWjgQXKWA4TzxFDRQw==
X-Received: by 10.31.67.209 with SMTP id q200mr9001222vka.43.1490586453180; Sun, 26 Mar 2017 20:47:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.84.20 with HTTP; Sun, 26 Mar 2017 20:47:32 -0700 (PDT)
X-Originating-IP: [216.80.61.5]
In-Reply-To: <C035D5EF-0C48-4BD7-A7C2-ACE533BEB8FF@fugue.com>
References: <E07AFAEB-2B84-4610-87E7-94CF32CF3761@fugue.com> <7652B138-FEAB-4138-91FB-D71AFE6BEF2C@vigilsec.com> <6DCFBC9D-666A-4A3C-A418-82BB6AE3D25D@gmail.com> <alpine.LRH.2.20.999.1703210928390.28925@bofh.nohats.ca> <m1cqKPa-0000FeC@stereo.hq.phicoh.net> <71F88034-72C5-4AEE-9ACE-3493A1173634@gmail.com> <alpine.LRH.2.20.999.1703211011170.30281@bofh.nohats.ca> <0A544BEC-F719-4A7B-99E4-DC878EBE7B0C@gmail.com> <bfea867e81fc4147be39b424f6e3201f@PMBX112-W1-CA-1.pexch112.icann.org> <CALXbJH_Ck38PUPJQ1QktohMkj81J+dBmo9DgfOWvfx9+D6cBOg@mail.gmail.com> <CAKr6gn317Oiz2xxg8gKxO+BaEOFfJN4mZiw1DRLEtDgsvqvSyw@mail.gmail.com> <980ED155-66BC-427D-901F-EAF28DB287D0@fugue.com> <CAKr6gn1T4YF61oUQpm9-34vBNGAkin0kLV_EJdL=E6qEwTL1og@mail.gmail.com> <C035D5EF-0C48-4BD7-A7C2-ACE533BEB8FF@fugue.com>
From: George Michaelson <ggm@algebras.org>
Date: Sun, 26 Mar 2017 22:47:32 -0500
Message-ID: <CAKr6gn2XfL0ketLPCrd9oV3bGJ2B5HyQaUVJ=ffTKUzAHnYtKA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: IETF dnsop Working Group <dnsop@ietf.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PQBa7SsjW6_xq_SReaT4-6A-1Mw>
Subject: Re: [DNSOP] .arpa
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: Mon, 27 Mar 2017 03:47:37 -0000

I really have a problem with "that it is not representative of what is
happening" -I mis-wrote to Ray, regarding how I believed he was
characterizing OpenWRT code. How am I meant to interpret what you
wrote here? Why am I not expected to respond, that is squatting in the
face of a discussion about WHY, let alone HOW the delegation should
happen? I should say that when I recall how the XMPP people felt when
they got pushback over standardization of jabber, I felt a lot of
sympathy for their "your nuts" rant: If people are doing this, maybe
recognizing reality is the best option. But that said, This feels like
technical domain-squatting. Thats how I understand 'what is happening'
to be meaingful, but maybe you meant something else? (I really want to
know btw)

I'd invert that second question: if the strong point of merit driving
requests into ICANN for delegation or reservation of labels is the
sense users interact with them, that has to be clearly stated in the
MoU: If there is a technical requirement for a label, it has to be
very very strong to require a new reference in the "." anchored
namespace. If it can exist in s/w under .Arpa it makes far more sense
to do that, than incur the consequence of asking for special treatment
in a heavyweight process. So I think the arbiter in a technical sense,
is "why can't this exist under an existing namespace". I am not
convinced any of the p2p network requests, hash labels, other novel
non-domain forms of label actually have a good case here.  Your
requirement for .homenet/home/.hn is because you expect it to be used
in ways which you believe demand that top state, for people. Thats
where we descend into an argument about if user-needs are technical
(in the sense 6761 meant) or not. I think you made a case they are. So
I am trying to think that way, and reflect on them that way.

(Alain I believe, possibly others has pointed out that any delegation
change in the root zone carries cost consequence which we make light
of, decrying it as lawyer food, but it does exist, and it does have to
be understood as a cost to the community in the wider sense)

I believe the technical merit language was written in a time when we
thought machine-led purposes would dictate needs. I do not believe it
was drawn up for modern times, and I think it was a naieve decision to
proceed with the MoU, and (re)open the door.

So, if the MoU doesn't say "either because strong machine-technical
requirement places this at the root" (I think despite my opposition,
the case for Onion probably had this because of the CA issuance
requirements) or "human interaction requirements make this a
technically motivated label eg home-use excluded from global DNS, but
for human reasons ANCHORED at the root, not a 2LD or 3LD" .. then
maybe it should? Said better of course.

A reductionist response to user need would be "user pays" -Its not one
I like, or subscribe to. But I am driven to note it.
In that sense, it might even be, that the wisest, simplest path for
the IAB to request new gTLD is to offer to pay for the costs, and make
the community understand every time they put this into the IANA
requirements or IAB directions, they are asking real money to be
spent. It would certainly focus the mind.

-G

On Sun, Mar 26, 2017 at 10:19 PM, Ted Lemon <mellon@fugue.com> wrote:
> On Mar 26, 2017, at 9:51 PM, George Michaelson <ggm@algebras.org> wrote:
>> I was thinking about the 'because its the (D)arpa" opposition when I
>> said that. I think *that* stated reason, is mostly now, a phantom.
>> Maybe I'm wrong on that too. Maybe its a giant political layer9
>> football which will come back to haunt us, forever. Given how much of
>> the planet happily goes into the RIR system to register PTR records
>> for their addresses, I'm struggling to believe this is a choke-issue
>> of significance.
>
> I don't think there is any functional problem with hn.arpa: it could certainly work as a domain under which to put homenet names.   The problem is that it is not representative of what is happening.   With existing uses of .arpa, I don't think this is a problem, but if in fact we expect users to see homenet subdomains, then they should look like what they mean, and they don't mean "a subdomain of arpa."
>
>> You argue a case, as a question of human interaction. You see the
>> domain as one which is going to require human input, human engagement.
>> You want a TLD because you want people to interact with it, as a name.
>> This is not sounding to me like an infrastructure, technical driver
>> for the existence of a label
>
> Here you seem to be claiming that any label that has a meaning that is meant to be understood by end users is not a technical use.   This is not stated in the MoU.   Essentially, if it would be better to reserve a label in the root than under .arpa, then by definition we cannot.   If that's the case, where is the technical use provision in the MoU applicable?   It only makes sense for zones operated by ICANN, and the only zone operated by ICANN of which I am aware (perhaps naively) is the root zone.
>
> So you would seem to be arguing that that provision in the MoU could be struck without harm.   If so, why was it put there in the first place?
>