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

Suzanne Woolf <suzworldwide@gmail.com> Tue, 21 March 2017 14:31 UTC

Return-Path: <suzworldwide@gmail.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 BE6CC129979 for <dnsop@ietfa.amsl.com>; Tue, 21 Mar 2017 07:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ncxWRWd6BRkG for <dnsop@ietfa.amsl.com>; Tue, 21 Mar 2017 07:31:36 -0700 (PDT)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 7FF7E12995B for <dnsop@ietf.org>; Tue, 21 Mar 2017 07:31:36 -0700 (PDT)
Received: by mail-qk0-x235.google.com with SMTP id 1so136053374qkl.3 for <dnsop@ietf.org>; Tue, 21 Mar 2017 07:31:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UPs0paS/vF7FZ3FNZWfZxtxKZqpRI4Bi9Fou4eH6chk=; b=kdp+nOTBSIqKa0gnwqS1Tx1U/YFm1tWJZy7T4zPf91WJIPzWmEBSuVgNY20F+2KPqS 0jmwa/om8VD71+kpcqxqxGg3TS7kM14DnVWqXt6nyUq0Okto0g8jowKaZAEkYu4B8U3n 6I+ZdUJqYWWxWbAYj7B9F/CfKRq1YAI6ESXGCWUWoZehpyKnfqXpk1ojQ4qDJqrWY3yl c+lcw1VNUOQY1KkjdysStqqrdAVIFzvIC3OokvrVL1FaXR/Id9bJ1LsuU826r01YvKDh KliQLzwzDg+ydOiXzwG/liA2pDTrW2YYCtvU21ODY8gvK5KRJ1J+mLkdYPUeR4UL/JYV 0jQg==
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=UPs0paS/vF7FZ3FNZWfZxtxKZqpRI4Bi9Fou4eH6chk=; b=hddShLv7Eo0zSRrXt2dL43x9N3i6skPxabhlhPuHmEkhwTcKhqOwt7pI2wcKQsgbUT a5DqgjOI9+PHRq0ZFe+BzI3nYtCKWPEiocpR/6Wfcgex/FARdV1oQ5ydH0EMDvb1Cda9 dWQ5CJCDnNcGJkVPwi85ozflPT2DbJxJQgqT7ldYTFOqS6H8WcaWHyxaIhiGXQVGya4l NxPkcEi2ou5FwZcCMhDiGLifTaCztCMUy9TgtYxYH7mcDsY1ld5LXhpNFH32YyEIM8bs W7B1gh2vgWgm7bI19KwlxAvx/k+dkeeLP5O6GhHBZ/NfzmJ8nGPVQRhX/y8el3k2wsOl vc4A==
X-Gm-Message-State: AFeK/H2hGFGGyJCEzV+1/rjM5Mj3RN7i9NbCj9AyFCa10/Rl+s6xc5me5oQyw7sm47wLwA==
X-Received: by 10.55.214.24 with SMTP id t24mr32359208qki.141.1490106695346; Tue, 21 Mar 2017 07:31:35 -0700 (PDT)
Received: from ?IPv6:2601:181:c381:c20:6d62:e795:8539:614a? ([2601:181:c381:c20:6d62:e795:8539:614a]) by smtp.gmail.com with ESMTPSA id t47sm7190676qte.45.2017.03.21.07.31.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 21 Mar 2017 07:31:34 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <alpine.LRH.2.20.999.1703210928390.28925@bofh.nohats.ca>
Date: Tue, 21 Mar 2017 10:31:33 -0400
Cc: Russ Housley <housley@vigilsec.com>, dnsop <dnsop@ietf.org>, Ted Lemon <mellon@fugue.com>, Terry Manderson <terry.manderson@icann.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1F8C6D6-7160-4BB0-B8A4-39D0027A52C1@gmail.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>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pNuFI4jhFgx-OpA7t0EH_C-K3d8>
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: Tue, 21 Mar 2017 14:31:39 -0000

Paul,

I’d like to make sure I understand your comment, as I’m not completely sure it addresses mine.

As I read your response, you’re willing to forgo a root zone entry, and the DNSSEC behavior the WG has reached consensus it wants, in order to have an entry in the special use name registry for “homenet”. Is that correct?

If so….I see your point and I hope the IESG  is listening, as I don’t think it’s the HOMENET WG consensus; as written, this draft asks for both a single-label name and certain behavior with respect to DNSSEC, which means asking for an entry in the root zone.

A little more, below.

> On Mar 21, 2017, at 9:54 AM, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Tue, 21 Mar 2017, Suzanne Woolf wrote:
> 
> [also speaking as individual only]
> 
>> I see no justification in draft-ietf-homenet-dot for a single-label name, except an implicit suggestion in
>> Sec. 2 para. 2 that the specific string was chosen to be memorable in cases where homenet names are exposed to
>> users. 
> 
> That seems good enough for me. The problem of DNS being the only
> real name space for endusers is very well understood. And I still
> regularly have to refind my printer based on checking my dhcp server
> logs, something not available to regular endusers. The requirement
> is very real.

The requirement for a name that will resolve in the DNS? Sure.

The requirement for a single label/TLD that will resolve in the DNS root zone? Dramatically less clear to me, and nothing you say above is specific to the root.

From the perspective of the DNS protocol, which string is used to fill a domain name slot is mostly immaterial as long as strings are generated and parsed according to the recognized rules; they’re interchangeable— what matters is that they’re unique within the relevant namespace. The root of a hierarchical namespace is mathematically special in a few ways, but I haven’t seen a case that the name used by HNCP requires any of them. At the same time, the root of the DNS namespace is quite clearly special in the administrative sense; I’m trying to separate the two sets of considerations.

>> I *strongly* suggest that if this document is to be used as justification to create an entirely new process
>> for updating the root zone, coordinated between the IETF and the external body that controls the root zone,
>> the justification should be *much* more explicit.
> 
> This .home / .homenet issue has already been going on for a very long
> time. The longer we wait with resolving this issue, the worse the
> deployment situation will be of software mixing .home vs .homenet.

For the purpose of the question I’m asking, I’m indifferent between the strings “.home" and “.homenet”. The policy problems with “.home" are significantly larger than with “.homenet”, but asking for a root zone entry at all is a significant problem for the current draft, no matter what string is involved.

> Suggesting we postpone .homenet while figuring out a new IETF/ICANN
> process, something that can take years, would basically doom this rename
> and install .home as the defacto standard. Once this new process
> would be completed, it would lead to new breakage, and the new
> software would be forced to look into both domains, or if the
> install base is big enough for .home, would be better of ignoring
> a new .homenet altogether.

Again, I’d like to make sure the problem I was trying to address is clear.

Asking for a delegation in the root zone, particularly an unsigned one, as this document currently does, *will* essentially require "figuring out a new IETF/ICANN process, something that can take years.” This is true no matter what string is being requested. 

It’s simple fact that a name elsewhere in the tree does not have the same obstacle.


Suzanne