Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Matthew Pounsett <matt@conundrum.com> Thu, 23 March 2017 14:06 UTC

Return-Path: <matt@conundrum.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 91A6E1267BB for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 07:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-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 AK44nwiPP5oR for <dnsop@ietfa.amsl.com>; Thu, 23 Mar 2017 07:06:13 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 538F7124BFA for <dnsop@ietf.org>; Thu, 23 Mar 2017 07:06:12 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id q7so94408536uaf.2 for <dnsop@ietf.org>; Thu, 23 Mar 2017 07:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BBdEt64Z0xUJB+WBhNtfP0cO8KE1nsUauD7bhSpRpuc=; b=fyrdJgOJOzdpTd8Lknt8Lyv7h5kcAcknbFTbJvxSEy+s9oyuEzvc49MEZ3cBWA/tcw o7B48UP98eVl3X5+Gw0FuEGCu33AcBawhNzjRGK8LHEV+ziwyQ1Ge0IErMTA8VfwSQGb pBAXy1GYEE9wpLPkikNfmYRR6BBrWVOu+gFx7d2ASbtjGO15mQWkw9DF9QwqxGBngqy4 I6TyPPMq/j2nnQpbZ/AqfnqGMjZIeyr/J+3GpUqVa3G5CRXaPP0vvrzejjnQ7O1de5P1 zQ+fRQKK5+ZzEtXLA7W2LI0EA/WIM91dHCMEkKGmnf2iA//Gxt0pk5RNmxLd9FaV//xb +qsA==
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; bh=BBdEt64Z0xUJB+WBhNtfP0cO8KE1nsUauD7bhSpRpuc=; b=KDQrQQdAfoSwzJfyhvUkyz+I4i70XRQ/3PCUMGzCr6StD4wu5xCeLzuJKR9HjEgeqQ WBt3E+xewqCsRgeinR+kgl0pvA9kVpNNrnOfc1xgSsn1rBi02+Eno8otHrbL15r/Xean Hhz4LSfFfrSofb87dXBlDC02hEaDvd2/9kdptH5pXYC3tHeWNv7438sF5IOyuW19qWF6 1Qvf5qDE3F6HK4HYIqZH5mZLkmtcbEClq2vWGC3+dHmEDzph3SBHLXnVPoXvVS6SNu1G 6d3JZvrWWvEn5HEjiMS/guybMB6vdFF7Ss3d0uQFpo7jzIDNCmmRt/Zjcwqn7wKIvPyz Zdzg==
X-Gm-Message-State: AFeK/H2+I5GFUO31YhdIJfewCxiFNUJupgmU/qZ9TpcNEw2z9m/Yau0aHaOvjbRdREsUoLZymli0pYr9aGgbTg==
X-Received: by 10.176.82.130 with SMTP id v2mr1297983uav.62.1490277971561; Thu, 23 Mar 2017 07:06:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.50.65 with HTTP; Thu, 23 Mar 2017 07:06:10 -0700 (PDT)
In-Reply-To: <1E14B142-680B-4E30-809B-68E03EB6E326@gmail.com>
References: <1E14B142-680B-4E30-809B-68E03EB6E326@gmail.com>
From: Matthew Pounsett <matt@conundrum.com>
Date: Thu, 23 Mar 2017 10:06:10 -0400
Message-ID: <CAAiTEH-cn-i+mLPh6w0hSNEPtjA3fM3u9re_S4Rptm7sUC9D6w@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c18fe0c1cfde3054b666198
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/F9dKMItW7EOo64cAIsD_ZAFL-ik>
Subject: Re: [DNSOP] WG review of draft-ietf-homenet-dot-03
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: Thu, 23 Mar 2017 14:06:15 -0000

On 19 March 2017 at 21:44, Suzanne Woolf <suzworldwide@gmail.com> wrote:

> This document is the product of the homenet WG, which has asked the IESG
> to approve it for publication, so our comments are strictly advisory to the
> IESG. There was some discussion of the draft on this list shortly after it
> appeared, in November 2016, but it’s always the AD’s prerogative to ask for
> additional review.
>
>
To first answer the two questions in the call for reviews:  I see no
technical problems either with the RFC6761 application in the draft, or
with having an unsecured delegation in the root zone, should 'homenet.' be
chosen to anchor HNCP names.   There's a clear technical need for special
handling at the border between the local network and the Internet (local
names) and–in the absence of a specification for getting local trust
anchors into every validating resolver inside the local network–an
unsecured delegation for whatever name is chosen to facilitate end-to-end
security.

The reason we have a problem here is that this has been gone about in
entirely the wrong order, and procedurally leaves the IETF in a difficult
position.  We have no business demanding a root zone delegation from ICANN,
and publishing an RFC that requires that to happen in order to be useful is
tantamount to making that demand, regardless of how nicely the demand is
worded.

The need to correct the mistakes of the HNCP draft has, I think, resulted
in a rush that has been detrimental to careful consideration.  At the risk
of repeating the obvious, so that I can refer back to this list, what
should have been done is:
1) speak to ICANN (the community) about whether/how it's possible for IETF
to reserve & delegate an unsecured name from the root
2) if the community says yes, and after a process is defined, pick a name
that doesn't conflict with anything (including DITL research)
3) write the draft to reserve the name

While I appreciate that there's some risk this name might be exposed to end
users, and that perhaps some tiny percentage of end users might react badly
to seeing a reference to ARPA, I think that exposure is mostly going to
happen with technology professionals and hobbyists (power users), not the
typical home user.  So while it still may be preferable to use homenet.
over homenet.arpa., I'm unconvinced that it *needs* to be that way.

If HOMENET is set on trying for homenet., then I would recommend proceeding
with draft-ietf-homenet-redact, and shelving this draft until (1) and (2)
can be completed.

If there's a need that draft-ietf-homenet-dot be finalized before (1) and
(2) can happen, then homenet. should be replaced with homenet.arpa..

- Matt


PS: given that there is already talk of lawsuits over home. and corp., and
given that for any name that might be chosen there's likely somebody out
there in the world that thinks that name might be valuable to register, I
think the chances of getting a 'yes' out of the ICANN community is very
nearly zero.