Re: [DNSOP] .arpa

Andrew Sullivan <> Wed, 22 March 2017 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F496129B0F for <>; Wed, 22 Mar 2017 10:12:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=SqBxGKj/; dkim=pass (1024-bit key) header.b=aSTgEBLL
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d8KXRZuD3had for <>; Wed, 22 Mar 2017 10:12:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E71ED129B33 for <>; Wed, 22 Mar 2017 10:12:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E1FF2BB82E for <>; Wed, 22 Mar 2017 17:11:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1490202711; bh=/aBBdOfh1pl37ZC4dF5GN+x17AT1yfbcFS7HsQ06F8c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=SqBxGKj/KfQg3s8MT2JehIYJvxwA6oekAaS+Q+M1g/ARd6kgFfpTycMB6t9A+tckT HiHEkdT5UDQRitmA9pMHN23GY1EZSWyEaBOA2bSDOYw0+UWfheGecGv2DaXWbhamNa 7T8iwZSXJ08AxKxRicwdIhi+wJMEs2x6twGMgc98=
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 51rIqq22A9Ny for <>; Wed, 22 Mar 2017 17:11:45 +0000 (UTC)
Date: Wed, 22 Mar 2017 13:11:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1490202705; bh=/aBBdOfh1pl37ZC4dF5GN+x17AT1yfbcFS7HsQ06F8c=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aSTgEBLLg3STeNMT+ltPvfEBKmljEBcIAC1cWe7ShBi4sOocwI8QHTzftUSJ8bgyl jLaV9uT6ur8QzC+Cx77oYCU4kgN9h+o52udRmPATfpfrMYxtRsW13/C4yEmP3D1UR3 DdMqZVgq1hfr82wlv8WKK3rrrGE3bwBZWZ2fi7RA=
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <EMEW3|7748a271060e43ad02f4e918d6bc04f1y2LBoG03tjc||> <> <> <EMEW3|60cdac3fad8ea0f5d9c8144322c5e9ddy2LEom03tjc||> <> <> <EMEW3|1770685f3047d9d32676cafa683d64b2y2LFBj03tjc||> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [DNSOP] .arpa
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Mar 2017 17:12:30 -0000


On Wed, Mar 22, 2017 at 09:19:24AM -0700, Ray Bellis wrote:
> Arguably I'm not "typical", but IMHO we shouldn't be designing for the
> lowest common denominator.

That argument is absurd on the face of it, because anyone sufficiently
clueful about systems to be using ssh or hand-entering domain names is
also sufficiently clueful to recognize that maybe they should use the
google search result that pertains to networking rather than the US
DoD.  (Presumably these are the same people who have figured out that and are not the same organizations.)  Therefore, would work just fine for such people, there'd be no
design for LCD, and also we'd get something that would work and
wouldn't involve a constitutional crisis for IANA.

> Either way, the Homenet WG has reached its consensus decision to request
> ".homenet" rather than "".

Since the point of this discussion is to inform IETF consensus,
HOMENET's consensus is not the only thing that counts.  It is entirely
possible that HOMENET's consensus will not be the IETF consensus.

> To those that say "no insecure delegations in the root zone" because
> "DNSSEC is good"

I don't think anyone is saying anything about that.  The point is that
_someone else_ gets to decide.  The IETF has literally no say in the
decision about what goes in the root zone itself, and hasn't since the
IETF signed its MoU with ICANN.  (Some argue that for this reason the
IETF must never allocate a top-level label.  I do not agree with them,
but there is absolutely no question about whether we are in a position
to decide actual registrations in the root zone.)

The plain fact is that the IETF IANA considerations in
draft-ietf-homenet-dot-03 makes a request of IANA that the IETF has no
business making, because we are requesting an entry in a registry
whose policy is controlled by someone else.  It's clear that the
weasel words "arrange for" are there to pretend we're not making such
a request it, but the MUST NOT be signed is an attempt to specify
protocol operation in a registry where we have no business working.
If this proceeds as IETF consensus, it will be apparent that it is the
IETF, not ICANN, that threatens the stability of the IANA
arrangements.  I hope we do not have to explore that rathole in my

Best regards,

A (speaking, of course, for myself)

Andrew Sullivan