Re: [DNSOP] .arpa

Ralph Droms <> Wed, 22 March 2017 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 973AC129B7E for <>; Wed, 22 Mar 2017 11:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tWJv_Pf2Xb_s for <>; Wed, 22 Mar 2017 11:00:55 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DE7112869B for <>; Wed, 22 Mar 2017 11:00:55 -0700 (PDT)
Received: by with SMTP id v127so162743171qkb.2 for <>; Wed, 22 Mar 2017 11:00:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MK+97x8H+n80rbVjUHSyJs1BfuNDxNlN3rGf/Jf6tsM=; b=nELmwCCCDxKy7Vu5kvb/BqtbwC/ZckdzqMv4Ya44Gac/so/r8Oa8b8j4llbpV8djM4 PD+QBFCy3JFi2M/YCI37k9/uOZoYIvX58KT3AHdFw/YtTHjQrTAbgqU6VrfnjHvxMBZJ yF9YcbaTCFvyeGpGPckLEHarHiBhsud3zytFs/5zOCbLaYuKCju0w9V1UQwADIP8Wf8w EZwoBbq+9+hdk5RBXt4SeMM7t1hguM8McuaWHOBIb7EL5WOz+iixbCTKDysp558LCRVs Gg+g2pF/sZHd30GgiFDggX6mQ6IsKIl2pMYu7tRrL4iF8o3IC64Vln1oGsmYrpUGjIir 3oHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MK+97x8H+n80rbVjUHSyJs1BfuNDxNlN3rGf/Jf6tsM=; b=K3m0O1P5HiUc5xK58/yITQ38Bv/SsLkYHm3HrD+li04OxugwllxghJqEc/laqpRuW3 tIPy0SHDBwgJiwTzvUUxz4YOOeMQUfjdTo6dKJI08AaVxJGiiH1nFpI9XkFtzi/b5aTV pYQ9t2iivDrNu1bwY5EeKvHYVTO2cryMrPiZLrGk0blZwk/OGdx3Vqw5CpfaHLNUZpLL AVtskU7WrglToF4YqaGTg8T/RDiX25FPzbgrMYB+0MDH33/6ElYVvk3oiFhFZoutniTv EtKEuA7rlS3W07eRh4IHwPrHvDS4Mhhj5QVmq3Jz5yI/wel8BWjtg3fBQITCEwvocTVs 5k8w==
X-Gm-Message-State: AFeK/H02D+NubA12Pa5SPE8DA0LzFxQhzNEMfvR6VNAaaYbkVNZTiaaUE08qdWDgI21qEw==
X-Received: by with SMTP id n133mr35727289qka.38.1490205653819; Wed, 22 Mar 2017 11:00:53 -0700 (PDT)
Received: from ?IPv6:2601:18f:801:600:fc1a:a4f:1cfd:b13c? ([2601:18f:801:600:fc1a:a4f:1cfd:b13c]) by with ESMTPSA id j20sm1470962qke.14.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Mar 2017 11:00:53 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Ralph Droms <>
In-Reply-To: <>
Date: Wed, 22 Mar 2017 14:00:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <EMEW3|7748a271060e43ad02f4e918d6bc04f1y2LBoG03tjc||> <> <> <EMEW3|60cdac3fad8ea0f5d9c8144322c5e9ddy2LEom03tjc||> <> <> <EMEW3|1770685f3047d9d32676cafa683d64b2y2LFBj03tjc||> <> <>
To: Andrew Sullivan <>
X-Mailer: Apple Mail (2.3259)
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 18:00:58 -0000

> On Mar 22, 2017, at 1:11 PM, Andrew Sullivan <> wrote:
> Hi,
> 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
> lifetime.

I agree that the request is misdirected toward IANA and misplaced in an "IANA Considerations" section.  If the IETF consensus is to find a way to instantiate the appropriate entry in the root zone, such an instantiation should acknowledge several realities and recognize that IETF is making a request of ICANN.  It seems to me homenet-dot should be revised:

* take the relevant text out of the IANA considerations section
* add a section that
  - motivates and explicitly defines the desired entry in the root zone
  - suggests that a request be made directly to ICANN 
  - explicitly points out that no process for such a request exists, and it might be necessary for IETF and ICANN to develop a mutually acceptable process before the request from .homenet can be considered
  - asks for IETF advice on this plan

- Ralph

> Best regards,
> A (speaking, of course, for myself)
> -- 
> Andrew Sullivan
> _______________________________________________
> DNSOP mailing list