Re: [homenet] Update on RFC 7788 and .home

Ted Lemon <mellon@fugue.com> Wed, 16 November 2016 04:09 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4782129431 for <homenet@ietfa.amsl.com>; Tue, 15 Nov 2016 20:09:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 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] autolearn=ham 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 2RQnvsQPjG63 for <homenet@ietfa.amsl.com>; Tue, 15 Nov 2016 20:09:36 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 E56C31294D4 for <homenet@ietf.org>; Tue, 15 Nov 2016 20:09:35 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id f82so44563052wmf.1 for <homenet@ietf.org>; Tue, 15 Nov 2016 20:09:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zb6ydBSkvkVSkNyVoJKsPHT5yoyfQgLZvrSe7Tms+Xo=; b=DBt3sVNmAGx2h6x23fp/Q2JggFq/nreTjVdWcLuR8MscuEqCvXiLfLPXYbUaCYZHn1 iwoJoluZOePsNR7ltFrs7llFHSLXmBuDGB6/IYHugrrh+q9Wlp/if9yZkKSoU4r2lYvs CnaQHHxT0AIrCewXk3cFD50NAZ0Bg761cJkNFG2RjzZ/1tD7+BUqaINGtKjfq5jR6Z2m jZyW55UR+NzCx3t9vrHY9Y1MDe+jyQpFPuLS0JmBLUkBTSXO34tMbTRwuSYSLPkBHbmx YfYXn/lQOPmzNl1RJB17OCGlvWS3xgs2wjV15DrPsNNh98xsTXIQHO5mKcF30RzO28jb ymOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zb6ydBSkvkVSkNyVoJKsPHT5yoyfQgLZvrSe7Tms+Xo=; b=cPXhy75C1fBkxwhySDNEBnB+Pu+5e3U6llIIMAxiB/1/Rq0aC8/PuyvcFvRP9QFYbE SjzRlgt31MT3z731y8QZDTDE3srhqG2nQZXlJ4jEYxLkZoovGFzQNTVNTne96RSIC8H0 ZI1VaPgH/zj/ySkqBkZB8J/vI/Vl1FgTDYfHKhYPjw5d3AV4maScXM36Xzb0VLBU38gt K+FHFu7GNVCKZreI3GgeuBxyuDYOtvxHH+qrWgGs9Lcswzla7JM9BX5xGziTx1aCWCYV SAkjN9r/6u9pXmJmD/6n1p8Ej+D9fsLbUVaYMlzOIYESwiUNNo2jM5chHSx+1kho7RcV Yz3w==
X-Gm-Message-State: ABUngvdE7wWIwGUY0LxGTwl9labXqjNnCzUGlEfydiSsgjkCenyoSPq1UVWzqDG7Jy56v2Vp/jIHG3JF3kgjtw==
X-Received: by 10.25.192.20 with SMTP id q20mr317128lff.5.1479269374258; Tue, 15 Nov 2016 20:09:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.28.15 with HTTP; Tue, 15 Nov 2016 20:08:53 -0800 (PST)
In-Reply-To: <4DE99B0A-D9B9-4B91-927F-02DC3F0598F9@gmail.com>
References: <CAESTAVuRJ9vNHb3yebXcfsmOS2MgrSeWkvbkKFwgAHZM4zfrOQ@mail.gmail.com> <7d563acb-b99e-293a-c108-a4e25892abe3@bellis.me.uk> <7F8F675B-D0C2-47E9-A190-A9922971132B@gmail.com> <c2f0e07b-bd99-11d7-2e68-3170280bf976@bellis.me.uk> <4DE99B0A-D9B9-4B91-927F-02DC3F0598F9@gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Wed, 16 Nov 2016 13:08:53 +0900
Message-ID: <CAPt1N1nvkNe_Q2LHFzjWDMLJWP9OA0JCxSiGx3U=bUna0A+Kjg@mail.gmail.com>
To: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/lwq6qktlinLxfxyDuS2OPuI2DUY>
Cc: HOMENET <homenet@ietf.org>
Subject: Re: [homenet] Update on RFC 7788 and .home
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Nov 2016 04:09:37 -0000

Great comments, Ralph--thanks!

On Wed, Nov 16, 2016 at 12:48 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
> I’ve read draft-ietf-homenet-dot-00.  If I’ve got it right, the concept and text in draft-ietf-homenet-dot-00 are modeled after the behavior specified in RFC 6303 and the text in RFC 6761that specifies the SUDN registry entries for the SUDNs defined in RFC 6303.  Seems like a good starting point for  draft-ietf-homenet-dot-00.
>
> I think the document can be advanced quickly; here’s some input I hope is helpful...
>
> I suggest that the paragraph in the Introduction that motivates the change from .home to .homenet be augmented or replaced with the reasons Ray listed in his e-mail (included below).
>
> I also have a few clarifications and other fairly minor editorial suggestions…
>
> In section 3, the response to item 3 in the SUDN reservation considerations could be clarified by specifying that any queries in the .homenet zone must be forwarded to a DNS service as configured by explicitly by HNCP or other appropriate local configuration mechanism coordinated with .homenet resolution, as opposed to just “configured”.  A manually configured entry for some external server is “configured”, but not configured in a helpful way.
>
> Given that the existence of draft-ietf-dnsop-terminology-bis, it would be helpful (at least, I would find it helpful) to use the agreed common terminology; for example “recursive resolver” instead of “Caching DNS servers”.
>
> In the answer for question 5, it might help the reader to specify which zones the “authoritative servers” are authoritative for.
>
> “DNS server operator” is likely a term of art in the answer for question, but it’s not clear to me which operators and servers are referred to, here.  Although passive voice should be avoided, it might be appropriate to simply write “DNS servers outside a home network should not be configured to be authoritative for .homenet.
>
> - Ralph
>
>
>> On Nov 15, 2016, at 8:40 PM, Ray Bellis <ray@bellis.me.uk> wrote:
>>
>>
>>
>> On 16/11/2016 09:53, Margaret Cullen wrote:
>>>
>>> What is the reasoning for using .homenet as the Homenet Domain, instead of registering and using .home?
>>>
>>
>> <chair hat partly on>
>>
>> 1.  we cannot be sure that using .home is consistent with the
>>    existing (ab)uses
>>
>>    [e.g. BT in the UK already have about 5M CPE devices deployed
>>     that are not "Homenet" devices but do use ".home" as their
>>     default domain name.  We don't know how those would interact]
>>
>> 2.  ICANN is in receipt of about a dozen applications for ".home",
>>    and some of those applicants no doubt have deeper pockets than
>>    the IETF does should they decide to litigate
>>
>> NB:  Whilst ICANN has previously said that they won't actually delegate
>> ".home" to any of those applicatants because of the amount of existing
>> (ab)use of that name that's visible at the DNS root servers, they are
>> under pressure from the applicants collectively to reverse that position.
>>
>> Ray
>>
>> _______________________________________________
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet