Re: [DNSOP] .arpa

Ted Lemon <mellon@fugue.com> Mon, 27 March 2017 03:28 UTC

Return-Path: <mellon@fugue.com>
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 29B40128BB7 for <dnsop@ietfa.amsl.com>; Sun, 26 Mar 2017 20:28:44 -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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 ValRJtIOaQdK for <dnsop@ietfa.amsl.com>; Sun, 26 Mar 2017 20:28:43 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 0996D127241 for <dnsop@ietf.org>; Sun, 26 Mar 2017 20:19:32 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id 190so39046811itm.0 for <dnsop@ietf.org>; Sun, 26 Mar 2017 20:19:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oDsmse6qaumMM8VN13mdmxyP9I4g8ztRRmr+NWVETPc=; b=ccM6m8SVlzv3hkEPOMDqBzVOh/K69FPYD08oWq9Wjqnl/VFPe7oapdNSww2Lv4OQWN zHxSvN3RdzwTFYQ1xRIMQmKVqmsA9+Rxt/LTh/4Hh2o9KS3q4freuIKJOCZIesLlLAC9 2Bp3rv1Djp4c54fOrin2yShD0JYyJappxyPETk3ySKHNKfCYKYRxMzrqGyVsKSFpbkMG 4A/nK/T+McnyEVT4o+qjUW/z7/ZKmTu7HuiHcNlE6CuxyJrR0ni5uBOoan7DVEq86FRZ LIXBe1Ai5R/azLv0Yp+p8ZXo04sL9d25nlDb/LxKL5nPrIbVmWT0XkqZpLJdbBtZJ3I/ QgfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oDsmse6qaumMM8VN13mdmxyP9I4g8ztRRmr+NWVETPc=; b=OCfo4hieh97EucxQWaCc5qfpIO5kNcAMIRWvn1YahJfnnloiFykp3p20ZRsjkrCgk0 ZkU8qOWIQpNK6liZZhEufg0QoVvQMJ0cSbKHL9pcBCDbumifP8zmL9ERLaiHTtpq3wk4 4wgoOTMwM2PQRRuX+7ulY51DoVienJdm1rOJiEZQOsnGyJTumxP+Nk2TDlr+avQTiwX3 KizLxuLs5byqW5D1fT4JXYY5RoLlYR3Lt8afI6y2WyD9eUB5I07gejYMhxq70AT26auN 1Nu549a2BhtP8Z0z+ouFWk3bwaoi6cdhpA09TK3eDsyHctf58KMMTpTFJo1pgE8EzCk4 p1gA==
X-Gm-Message-State: AFeK/H1ERddwMTFOfNk/lvwBLklxNi2uSaBzm0y6/OtERrypKFgIRzDaMpoHXuf8Dzy2BA==
X-Received: by 10.36.10.129 with SMTP id 123mr2725537itw.80.1490584772075; Sun, 26 Mar 2017 20:19:32 -0700 (PDT)
Received: from [172.20.3.20] (swissotel07.s.subnet.rcn.com. [216.80.61.6]) by smtp.gmail.com with ESMTPSA id d196sm5064714ioe.3.2017.03.26.20.19.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 20:19:31 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <CAKr6gn1T4YF61oUQpm9-34vBNGAkin0kLV_EJdL=E6qEwTL1og@mail.gmail.com>
Date: Sun, 26 Mar 2017 22:19:26 -0500
Cc: IETF dnsop Working Group <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: George Michaelson <ggm@algebras.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/kjDqEDYuMoIZa-Gcpa-KGaFB-kU>
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:28:44 -0000

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?