From nobody Wed Jan 4 05:55:46 2017 Return-Path: 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 D5F2B129580 for ; Wed, 4 Jan 2017 05:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_RP_RNBL=1.31] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coote.org header.b=DTZzXV72; dkim=pass (1024-bit key) header.d=coote.org header.b=DTZzXV72 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 vIeAnGaGg4Ew for ; Wed, 4 Jan 2017 05:55:44 -0800 (PST) Received: from mercury.coote.org (575185b4.skybroadband.com [87.81.133.180]) by ietfa.amsl.com (Postfix) with ESMTP id 748B31294BC for ; Wed, 4 Jan 2017 05:55:43 -0800 (PST) Received: by mercury.coote.org (Postfix, from userid 1000) id F065216C0FDC; Wed, 4 Jan 2017 13:55:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org F065216C0FDC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1483538141; bh=s2AQZ6CD70lM7CPpwEyTHTmhQ/d0yD1mAv4X6TOpVG0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DTZzXV72lPeHLDCxBeDvZ08sh5hCeTHymYGi9kXMcPFwKIz5tbprYa/pY4VzECLE2 D25auSBxf8roMbMXOS5AT/DWcsG4yLmiQKHVE3klkJQXYYuM6KaVhWcffylw5El262 tNaSZEN4Tg1NokCTjyUe1KAksYwyxZg9bgNNgXY8= X-Original-To: homenet@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by mercury.coote.org (Postfix) with ESMTP id 4D59E16C0FDC; Wed, 4 Jan 2017 13:55:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org 4D59E16C0FDC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1483538141; bh=s2AQZ6CD70lM7CPpwEyTHTmhQ/d0yD1mAv4X6TOpVG0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DTZzXV72lPeHLDCxBeDvZ08sh5hCeTHymYGi9kXMcPFwKIz5tbprYa/pY4VzECLE2 D25auSBxf8roMbMXOS5AT/DWcsG4yLmiQKHVE3klkJQXYYuM6KaVhWcffylw5El262 tNaSZEN4Tg1NokCTjyUe1KAksYwyxZg9bgNNgXY8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Coote In-Reply-To: <2ffc700f-b208-e840-973d-71347a716f40@stucchi.ch> Date: Wed, 4 Jan 2017 13:55:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7625BF7F-131E-433E-AAE8-C71105B9C321@coote.org> References: <93E9D4FA-94C2-4ADE-A286-F25CFC0DF17A@coote.org> <2ffc700f-b208-e840-973d-71347a716f40@stucchi.ch> To: max@stucchi.ch X-Mailer: Apple Mail (2.2104) X-Spambayes-Classification: ham; 0.00 Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] upstream dhcp with hnetd X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 13:55:45 -0000 > On 18 Sep 2016, at 18:20, Massimiliano Stucchi wrote: >=20 Quick response from me, eh? >=20 >> Additionally, this is an ADSL connection so I need a pppoe connection = to >> my external modem, including a username/password. What=92s the = canonical >> way to add this extra step with hnetd? I can add it to a uci = interface >> (even an interface not called WAN) and the connection is made, but I >> don=92t know whether this will interfere with hnet.=20 >=20 > I have a similar situation, although on a fiber connection that = requires > PPPoE for IPv4. I solved it like this: >=20 > config interface 'homenet4' > option ifname 'eth0.6' > option proto 'pppoe' > option username 'username' > option password 'password' >=20 > config interface 'homenet4ext' > option ifname 'pppoe-homenet4' > option proto 'hnet' > option mode 'external' > option _orig_ifname 'pppoe-homenet4' >=20 > Basically, you "piggyback" on the interface created by PPPoE to use it > for hnet. That approach made great strides. However, when my ISP resets the dsl = link, IPv4 disappears from my internal networks. I can still log into = the router over ipv6 (usually). If I do get onto the router, than = restarting the network is usually sufficient, although sometimes the = wifi does not restart at all.=20 My guess is that there=92s a missing hook somewhere to hnetd and = deleted subnets are not getting re-added. I=92ve not managed to spot = where in the reams of log data. I can at least reproduce the issue by = resetting the modem (which is external to the router). Is this a problem that you=92ve encountered? Tim= From nobody Wed Jan 4 08:53:55 2017 Return-Path: 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 053991299C5 for ; Wed, 4 Jan 2017 08:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FtX9hj7eRTQF for ; Wed, 4 Jan 2017 08:53:52 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3174129664 for ; Wed, 4 Jan 2017 08:53:51 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id v04GrnPF021314 for ; Wed, 4 Jan 2017 17:53:49 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id B23ECD79EF for ; Wed, 4 Jan 2017 17:53:49 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id Q83062XIhOjP for ; Wed, 4 Jan 2017 17:53:48 +0100 (CET) Received: from trurl.irif.fr (dra38-1-82-225-44-56.fbx.proxad.net [82.225.44.56]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 692ADD7974 for ; Wed, 4 Jan 2017 17:53:47 +0100 (CET) Date: Wed, 04 Jan 2017 17:53:47 +0100 Message-ID: <87y3yq936s.wl-jch@irif.fr> From: Juliusz Chroboczek To: homenet@ietf.org User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 04 Jan 2017 17:53:49 +0100 (CET) X-Miltered: at korolev with ID 586D289D.003 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 586D289D.003 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 586D289D.003 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: [homenet] draft-ietf-homenet-babel-profile and REQ5 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:53:54 -0000 Dear all, Draft-ietf-homenet-babel-profile-01 says: REQ5: a Homenet implementation of Babel MUST implement HMAC-based authentication, as defined in RFC 7298, MUST implement the two mandatory-to-implement algorithms defined in RFC 7298, and MUST enable and require authentication when instructed to do so by HNCP. This requirement is completely useless in its current form. It expresses the intent pretty well, but does nothing to specify the mechanism. In particular, it is nowhere specified how HNCP peers decide to secure a link, and how HNCP peers communicate the authentication information to each other. (Communication between HNCP and Babel is not an issue, as it is local to a single host.) For this requirement to be useful, somebody needs to: (1) precisely define the algorithm that HNCP peers use to decide on authentication paramaters; (2) precisely define the on-the-wire format that HNCP peers use to communicate the authentication parameters; (3) provide an implementation. Please do not dismiss point 3 above. This is a healthy working group, one with a proud tradition of only standardising algorithms and protocols that have been implemented (and in most cases reimplemented independently). It has been a lot of work to make it so, and it would be a shame if we gave up. An important point to understand is that the lack of a cryptographic authentication mechanism does not make HNCP insecure. The expected deployment model is that HNCP and Babel only run on links that are secured at a lower layer, while guest links only run the usual leaf protocols (RA, ND, DHCPv4, ARP, etc.). Cryptographic mechanisms are only needed if for some reason a network is using untrusted links for transit. We've just had a private chat with the chairs and Markus, and I suggested that we should simply remove REQ5 until we've got a precise specification and an implementation. Markus agrees, although for slightly different reasons (he's in favour of running HNCP on trusted links only, as described in the paragraph above). The chairs, however, have expressed their unease at removing this requirement, fearing it might cause trouble during IESG review, and have asked me to bring the discussion to the list. Which I am presently doing. Please tell me what to do. Shall I remove REQ5, and hope for the best during IESG review, or is somebody intending to implement REQ5 in HNCP and collaborate on writing a detailed specification? I'd like to be clear on one point: I shall not be the editor of a specification that contains requirements that nobody has any intention to implement. Thanks for your help, -- Juliusz From nobody Mon Jan 9 10:51:30 2017 Return-Path: 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 71E1A129861 for ; Mon, 9 Jan 2017 10:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5ltUd3TpPJg3 for ; Mon, 9 Jan 2017 10:51:28 -0800 (PST) Received: from mail-pg0-x234.google.com (mail-pg0-x234.google.com [IPv6:2607:f8b0:400e:c05::234]) (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 086B4129860 for ; Mon, 9 Jan 2017 10:51:27 -0800 (PST) Received: by mail-pg0-x234.google.com with SMTP id 204so23681160pge.0 for ; Mon, 09 Jan 2017 10:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:subject:message-id:date:to:mime-version; bh=vsn/IEgLXfabJ9FsgaP8Om51cSPzeO0h+/eHSADxdW8=; b=oDnkEVX0ic1hBstW2G+7ruDhaL7b9dV4aof2wjUJtdM4tgHEJCnAIF39U4pJzgHpjP i8H+A253FpSMXWtDtSlABbfv3uioVpXD4iqWJjwxQ6UH/l4ZF7zpNjvot6Ppd5ynJqAt 06Ov8xppytDyOhmnUQQ6U83JgiCBe9CXSxG+YV8+pTEbsRr6ij3MwkUuIzdAFBqM6FOV 1izxIc4GLIpFjP4Kx32Dbs7+kaY83THXfPGh8ksBN3/vj/I8zXEyLA/Qv2FxGGwLMi8P 0Dija3mehpy8sjFsaMCMMIN39L3ekplekHIaA6Tcya4F4bstlZ9EKaiZmAPG3DQbeYSL duow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=vsn/IEgLXfabJ9FsgaP8Om51cSPzeO0h+/eHSADxdW8=; b=PCvp2HO739EQWS8HgUH+VH/Go/NrTwTSarHZdv2Wy2t8YbF1b3OxLwVWcDKgkLQXnc tQLRME/hjucUob0hWp5Wmoj5kFgE0Ls26GcAMqUML+cIYBiSLZvLE5n7/+nXUpaC/+To dyEiwNI3lJEoVG4Y1iDBVJbMCzmi+BzOybZIVstYLS+te2s4+nEvsO0UBYH4EZ62AJbl JesPA3jG0pOjJHGAWQv+oZi6KFcR4MzIyHUxYIxVdY27fw2ZYfkd3Ir6SdyLelQcCmSF NHP6IX5rjYZit4s3Fn4lAX+X70rO74AgbXwbZN9dXa/C8CGJRwXdCfJKJz6xeHxWx0DE k4Ng== X-Gm-Message-State: AIkVDXJJDck8fILuHgcZ5ZeBNtVIag0X71I3nbqdvfkzR0mBxbjyQQNq1WNrqzRpj4KaEtwK X-Received: by 10.84.205.69 with SMTP id o5mr192878882plh.70.1483987887216; Mon, 09 Jan 2017 10:51:27 -0800 (PST) Received: from ?IPv6:2620::10e7:10:4039:b03a:e0a4:1f2e? ([2620:0:10e7:10:4039:b03a:e0a4:1f2e]) by smtp.gmail.com with ESMTPSA id j128sm28618345pfg.73.2017.01.09.10.51.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 09 Jan 2017 10:51:26 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_7D06734A-1FFD-49FF-AD0C-94CF0929388F" Message-Id: <53A6A7D7-05D1-4CBB-AAC2-E19BEB3B590C@google.com> Date: Mon, 9 Jan 2017 10:51:25 -0800 To: HOMENET Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [homenet] I-D.templin-intarea-rio-redirect X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 18:51:29 -0000 --Apple-Mail=_7D06734A-1FFD-49FF-AD0C-94CF0929388F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hey HOMENET, I notice over in 6MAN that Fred Templin has written an interesting = draft. Route Information Options in Redirect Messages > I think anyone interested in the problems for which HOMENET is chartered = to solve should review and comment. Especially recommended for anyone = who might be implementing a HOMENET router. My impression is that host = operating system maintainers and operators have resisted implementing = RIO processing in RA messages due to operational considerations = associated with RA validation. Maybe those people would be happier with = hosts processing them in ND Redirect messages instead. What does everyone else think? --james woodyatt > --Apple-Mail=_7D06734A-1FFD-49FF-AD0C-94CF0929388F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hey HOMENET,

I notice over in 6MAN that Fred Templin = has written an interesting draft.

  Route = Information Options in Redirect Messages
  <https://tools.ietf.org/html/draft-templin-intarea-rio-redirect<= /a>>

I = think anyone interested in the problems for which HOMENET is chartered = to solve should review and comment. Especially recommended for anyone = who might be implementing a HOMENET router. My impression is that host = operating system maintainers and operators have resisted implementing = RIO processing in RA messages due to operational considerations = associated with RA validation. Maybe those people would be happier with = hosts processing them in ND Redirect messages instead.

What does everyone else = think?


--james woodyatt <jhw@google.com>



= --Apple-Mail=_7D06734A-1FFD-49FF-AD0C-94CF0929388F-- From nobody Thu Jan 12 01:50:00 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA4127058; Thu, 12 Jan 2017 01:49:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148421459864.19377.9810662749692854274.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 01:49:58 -0800 Archived-At: Cc: homenet-chairs@ietf.org, homenet@ietf.org, ray@bellis.me.uk, terry.manderson@icann.org Subject: [homenet] homenet - New Meeting Session Request for IETF 98 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:49:59 -0000 A new meeting session request has just been submitted by Ray Bellis, a Chair of the homenet working group. --------------------------------------------------------- Working Group Name: Home Networking Area Name: Internet Area Session Requester: Ray Bellis Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: v6ops intarea dnsop dnssd 6man sunset4 pcp bier anima softwire dhc mptcp babel Second Priority: roll dprive isis opsec rtgarea rtgwg dane spring dbound Third Priority: manet nfvrg Special Requests: --------------------------------------------------------- From nobody Fri Jan 13 02:05:51 2017 Return-Path: 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 6CF5412896F for ; Fri, 13 Jan 2017 02:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coote.org header.b=QETVv85J; dkim=pass (1024-bit key) header.d=coote.org header.b=QETVv85J 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 H1YEwmoP_gRW for ; Fri, 13 Jan 2017 02:05:44 -0800 (PST) Received: from mercury.coote.org (575185b4.skybroadband.com [87.81.133.180]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDF1270B4 for ; Fri, 13 Jan 2017 02:05:43 -0800 (PST) Received: by mercury.coote.org (Postfix, from userid 1000) id BEDE216C0EC0; Fri, 13 Jan 2017 10:05:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org BEDE216C0EC0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1484301942; bh=a9Jd06lGC9JiD7vqh0l31XU6JiPw2gFTvkkLCptfWvU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QETVv85JnDHaAhIkz49f9N4ZNN8yC/3vZUGLandeo3fq8F9SgaoYTYxB+f523pR7V c5PpGbGLVswQaKrnAXvXkEWzXZMoDHfeqxypqyUfscmKdFHkqtz+oBvBC917JIlopg j4uVEEA9mm1zpTDM0+quXJibK/5OiKU3at96pbYw= X-Original-To: homenet@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by mercury.coote.org (Postfix) with ESMTP id 0CC5716C0EC0; Fri, 13 Jan 2017 10:05:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org 0CC5716C0EC0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1484301942; bh=a9Jd06lGC9JiD7vqh0l31XU6JiPw2gFTvkkLCptfWvU=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=QETVv85JnDHaAhIkz49f9N4ZNN8yC/3vZUGLandeo3fq8F9SgaoYTYxB+f523pR7V c5PpGbGLVswQaKrnAXvXkEWzXZMoDHfeqxypqyUfscmKdFHkqtz+oBvBC917JIlopg j4uVEEA9mm1zpTDM0+quXJibK/5OiKU3at96pbYw= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Coote In-Reply-To: <7625BF7F-131E-433E-AAE8-C71105B9C321@coote.org> Date: Fri, 13 Jan 2017 10:05:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <93E9D4FA-94C2-4ADE-A286-F25CFC0DF17A@coote.org> <2ffc700f-b208-e840-973d-71347a716f40@stucchi.ch> <7625BF7F-131E-433E-AAE8-C71105B9C321@coote.org> To: max@stucchi.ch X-Mailer: Apple Mail (2.2104) X-Spambayes-Classification: ham; 0.00 Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] upstream dhcp with hnetd X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 10:05:50 -0000 Just to document an approach that avoids the link failure issue: > On 4 Jan 2017, at 13:55, Tim Coote wrote: >=20 >=20 >> On 18 Sep 2016, at 18:20, Massimiliano Stucchi = wrote: >>=20 >>=20 >> I have a similar situation, although on a fiber connection that = requires >> PPPoE for IPv4. I solved it like this: >>=20 >> config interface 'homenet4' >> option ifname 'eth0.6' >> option proto 'pppoe' >> option username 'username' >> option password 'password' >>=20 >> config interface 'homenet4ext' >> option ifname 'pppoe-homenet4' >> option proto 'hnet' >> option mode 'external' >> option _orig_ifname 'pppoe-homenet4' >>=20 >> Basically, you "piggyback" on the interface created by PPPoE to use = it >> for hnet. >=20 > That approach made great strides. However, when my ISP resets the dsl = link, IPv4 disappears from my internal networks. I can still log into = the router over ipv6 (usually). If I do get onto the router, than = restarting the network is usually sufficient, although sometimes the = wifi does not restart at all.=20 >=20 > My guess is that there=92s a missing hook somewhere to hnetd and = deleted subnets are not getting re-added. I=92ve not managed to spot = where in the reams of log data. I can at least reproduce the issue by = resetting the modem (which is external to the router). >=20 > Is this a problem that you=92ve encountered? >=20 I got help on this from the openwrt-devel list. The second interface = should use an ifname that=92s an alias of the first (whatever that = means). In this case that would be @homenet4, rather than = pppoe-homenet4. I confirmed that with this change, bouncing the first interface restores = the ipv4 for the second and restores a comparable ifstatus result to a = reboot. Tim= From nobody Thu Jan 19 10:48:22 2017 Return-Path: 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 DF00E1294DC for ; Thu, 19 Jan 2017 10:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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 USFBwAbG88Mq for ; Thu, 19 Jan 2017 10:48:18 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 495E81293DB for ; Thu, 19 Jan 2017 10:48:11 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id z134so43224483lff.3 for ; Thu, 19 Jan 2017 10:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rRqc48nLK8PNlKwv1GGiwU+W2KDSDh1TiLyFP3mgGLE=; b=Navr6whFfY0Uz3yPVy4ITkIodzE62YrTkKlDJQzm8b3Qr5eEBu6ETrG9HazLVm07AN 3cdmsFBynvWKVR8mHlS+DXY6wb0sa3D7R98mlCVZndYjkdmsqFXoKC3l2PgA2Ytct6MW e4yBLE1otmKkCC/p7/WdwbGoN7EXH9AUY3Eb+tTOITP5s5vNzFPGki5DIkZpJwGuvRi8 pLh40JPrnt1LVrThmkVSJytAfbHBDKcDGKmO0ro1Wqk3/opTVbhsgKrTTkRQaUME4Yeb j2h4SQBLzJUFFDaQTgh2ADjl9yV1zxiFO1zwFNtpPwCpogr+J3nZIU/uuNjdAIK4fQ1C I8IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rRqc48nLK8PNlKwv1GGiwU+W2KDSDh1TiLyFP3mgGLE=; b=WHwwy9gIexU4E6eu2fmqqsEBJvze2q2dCW0A91SoJARFt8syQGV0Pv0fIx7HDpsv3s p1BVow48EI5Ng5fcsagkzBM9ybng8pVejA0uuWOEpyNV3yQstl6LmXw/yqCKVxHqDxYl sbq2RwpoO7Y3d5lTA3Wq6mQDbhKhvuG3338MFrqp8J4LhdV4Up+5ZVvIWgPYhMfcQUXI N19pIeOSUVgtFJK40Dt3mExQlnPqj06L+zPEZgHSdur38T+hT0DmXgRDNkOE4jjotJZr Gd+7635CTU99sAxn/Mwv3r9fLjyg/PLojhxcNYg/yYPS7iqHskqduOPBAfrSiG7Dg7kd pYtA== X-Gm-Message-State: AIkVDXIuAE48Pm1LUiL7ZFNNSSqQIWgCmT48C1+UeX8vYMl17ENfFq39bo5dxyBoUxp2drlgZHEgUAyudU6lpg== X-Received: by 10.25.77.204 with SMTP id a195mr2929353lfb.181.1484851689098; Thu, 19 Jan 2017 10:48:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.165.74 with HTTP; Thu, 19 Jan 2017 10:47:28 -0800 (PST) From: Ted Lemon Date: Thu, 19 Jan 2017 13:47:28 -0500 Message-ID: To: HOMENET Content-Type: multipart/alternative; boundary=001a114065b2792bfd054676f9b0 Archived-At: Subject: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:48:21 -0000 --001a114065b2792bfd054676f9b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here are my notes from updating the above two drafts. Ralph Droms writes regarding draft-ietf-homenet-dothome: > I suggest that the paragraph in the Introduction that motivates the chang= e > from .home to .homenet be augmented or replaced with the reasons Ray list= ed > in earlier e-mail: > > > 1. we cannot be sure that using .home is consistent with the existing > (ab)use > > 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 > I updated the text as follows: The '.homenet' top-level domain replaces '.home' which was specified in [RFC7788] as the default domain-name for home networks. '.home' had been selected as the most user-friendly option. However, there are existing uses of '.home' that may be in conflict with this use: evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2]. Also, ICANN has about a dozen applicants for the '.home' top-level domain name, which creates a significant risk of litigation if it were claimed by the IETF outside of that process. As a result, the use of '.home' has been deprecated; this document updates [RFC7788] to replace '.home' with '.homenet', while another document, [I-D.ietf-homenet-redact] deprecates the use of the '.home' TLD. This sentence appears in section 2: > >> Names ending with '.homenet.' MUST refer to services that are located >> within a home network (e.g., a printer, or a toaster). > > I think "services" is too restrictive; in fact, the examples are really > devices or hosts, not services provided by those devices. What is the > restriction "located within a home network", and what, exactly, does it > mean? In my opinion, this document should focus on name evaluation withi= n > the .homenet locally served zone. I updated the text as follows: The top-level domain name '.homenet.' is to be used for naming within a home network. Names ending with '.homenet.' reference a locally-served zone, the contents of which are unique only to a particular home network, and are not globally unique. Such names refer to nodes and/or services that are located within a home network (e.g., a printer, or a toaster). Also in section 2, the phrase "Although home networks most often provide > one or more service discovery mechanisms," assumes the reader knows that > many service discovery mechanisms hide the domain name of the service or > host and, hence, .homenet. I updated the text as follows: Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, it is still expected that in some cases, users will need to see, remember, and even type, names ending with '.homenet'. It is therefore desirable that users identify the top-level domain and understand that using it expresses the intention to connect to a service that is specific to the home network to which they are connected. Enforcing the fulfillment of this intention is out of scope for this document. 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 mu= st > be forwarded to a DNS service as configured by explicitly by HNCP or othe= r > appropriate local configuration mechanism coordinated with .homenet > resolution, as opposed to just =E2=80=9Cconfigured=E2=80=9D. A manually = configured entry > for some external server is =E2=80=9Cconfigured=E2=80=9D, but not configu= red in a helpful > way. Also in item 3, s/for '.homenet'./for domain names ending in '.homenet'/ I updated the text as follows: Name resolution APIs and libraries MUST NOT recognize names that end in '.homenet.' as special an MUST NOT treat them differently. Name resolution APIs MUST send queries for such names to their configured caching DNS server(s). Using a caching server other than the server or servers offered by the home network will result in failure to correctly resolve queries for subdomains of '.homenet'. If a host is configured to always use a resolver other than the one offered by the local network, it will be unable to resolve queries that are subdomains of '.homenet'. > In item 4, s/part of the domain/part or all of the '.homenet' domain/ updated Given 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 =E2=80=9Crecursive resolver=E2=80=9D instead of = =E2=80=9CCaching DNS > servers=E2=80=9D. I updated the draft to use "recursive resolver" instead of "caching name server" and sent a note to Paul asking him why there is no definition for that term in the document. :) In the answer for question 5, it might help the reader to specify which > zones the =E2=80=9Cauthoritative servers=E2=80=9D are authoritative for. Well, now, when I looked at the answer to question five, I realized that the text is wrong. There is no need to specify anything here. If an authoritative server is configured to be authoritative for .homenet or any subdomain(s) of .homenet, it will do the right thing. If it is not, it will do the right thing. The text here requiring an auth server not to return an NS record for .homenet would only apply to the root operator, and we are addressing that in a different way. I think requiring special treatment for this name in an authoritative server would be a mistake. I have updated the text as follows: Only a DNS server that is authoritative for the root ('.') or is configured to be authoritative for '.homenet' or a subdomain of '.homenet' will ever answer a query about '.homenet.' In both of these cases, the server should simply answer as configured: no special handling is required. =E2=80=9CDNS server operator=E2=80=9D is likely a term of art in the answer= for question, > but it=E2=80=99s 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 =E2=80=9CDNS servers outside a home network should not be co= nfigured > to be authoritative for .homenet. I like your proposed text, and updated the document to use it. Jacques Latour and Bob Harold got into a conversation where Jacque said: Where do you delegate homenet to? Advanced DNSSEC validation may check for > proper delegation? This is actually addressed in the IANA considerations: the proposal is to do an unsigned delegation to the AS112 servers. However, the document doesn't actually do anything to make sure that that delegation will produce the right result. I do not know how to address this. Bob then asked: If an insecure delegation can be made in the root, then could a local trust > anchor be used by those who want their .homenet domain DNSSEC validated? I added the following text to the security considerations to address this: In order to enable DNSSEC validation of a particular '.homenet', it might make sense to configure a trust anchor for that homenet. How this might be done is out of scope for this document. Andrew Sullivan wrote, regarding draft-ietf-homenet-redact: in =C2=B61 of =C2=A71, "This document recommends the use of the '.home'=E2= =80=A6." reads as > though the present document (i.e. the I-D itself) is making the > recommendation. Perhaps "That document" instead would work, or "Said > RFC", or something. I think "that document" does the job=E2=80=94thanks for catching this. Andrew also raised the point about the unsigned root zone delegation and the process woes that might follow such a request. The working group appears to have decided to try going down that path despite the potential problems it presents, so I will say no more about that here. He also wrote: > In =C2=A71, "evidence indicates that '.home' queries frequently leak out = and > reach the root name servers [ICANN1] [ICANN2]", I don't think that's the > issue. The issue is that home is a well-known, in use TLD (we know > because of those queries), and the consequences of reusing it are > therefore completely unknown. I updated this according to Ralph's suggestion, which I believe hit on the same point. Please let me know if you think further clarification or deincorrectification is required. New versions of these documents will be hitting the datatracker shortly. If you feel that you had some comment that was not addressed, please let me know: I did my best not to ignore what anybody said, but there was a long thread, so I may have done so anyway. --001a114065b2792bfd054676f9b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here are my notes from updating the above two drafts.
=
Ralph Droms writes regarding draft-ietf-homenet-dothome:

I suggest that the paragraph= in the Introduction that motivates the change from .home to .homenet be au= gmented or replaced with the reasons Ray listed in earlier e-mail:


1. =C2=A0we cannot be sure t= hat using .home is consistent with the existing (ab)use

2.=C2=A0 ICANN is in receipt= of about a dozen applications for ".home", and some of those app= licants no doubt have deeper pockets than the IETF does should they decide = to litigate

I updated the text as follows:

The '.homenet' top-level domain replaces '.home= ' which was specified in [RFC7788] as the default domain-name for home = networks. '.home' had been selected as the most user-friendly optio= n.=C2=A0 However, there are existing uses of '.home' that may be in= conflict with this use: evidence indicates that '.home' queries fr= equently leak out and reach the root name servers [ICANN1] [ICANN2].=C2=A0 = Also, ICANN has about a dozen applicants for the '.home' top-level = domain name, which creates a significant risk of litigation if it were clai= med by the IETF outside of that process.=C2=A0 As a result, the use of '= ;.home' has been deprecated; this document updates [RFC7788] to replace= '.home' with '.homenet', while another document, [I-D.ietf= -homenet-redact] deprecates the use of the '.home' TLD.=C2=A0
=

= This sentence appears in sectio= n 2:
=C2=A0Nam= es ending with '.homenet.' =C2=A0MUST refer to=C2=A0services that are located within a home network (e.g., a p= rinter, or=C2=A0a toaster).
I think "service= s" is too restrictive; in fact, the examples are really devices or hos= ts, not services provided by those devices.=C2=A0 What is the restriction &= quot;located within a home network", and what, exactly, does it mean?= =C2=A0 In my opinion, this document should focus on name evaluation within = the .homenet locally served zone.=C2=A0

=
I updated the text as follows:

The top-= level domain name '.homenet.' is to be used for naming within a hom= e network. Names ending with '.homenet.' reference a locally-served= zone, the contents of which are unique only to a particular home network, = and are not globally unique.=C2=A0 Such names refer to nodes and/or service= s that are located within a home network (e.g., a printer, or a toaster).

=C2=A0<= /span>Also in section 2, the phrase "Although home networks most often prov= ide one or more service discovery mechanisms," assumes the reader know= s that many service discovery mechanisms hide the domain name of the servic= e or host and, hence, .homenet.

I up= dated the text as follows:=C2=A0

Some service discovery= user interfaces that are expected to be used on homenets conceal informati= on such as domain names from end users.=C2=A0 However, it is still expected= that in some cases, users will need to see, remember, and even type, names= ending with '.homenet'. It is therefore desirable that users ident= ify the top-level domain and understand that using it expresses the intenti= on to connect to a service that is specific to the home network to which th= ey are connected.=C2=A0 Enforcing the fulfillment of this intention is out = of scope for this document.

= 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 mus= t be forwarded to a DNS service as configured by explicitly by HNCP or othe= r appropriate local configuration mechanism coordinated with .homenet resol= ution, as opposed to just =E2=80=9Cconfigured=E2=80=9D.=C2=A0 A manually co= nfigured entry for some external server is =E2=80=9Cconfigured=E2=80=9D, bu= t not configured in a helpful way.
Also in item 3, s/for = 9;.homenet'./for domain names ending in '.homenet'/=C2= =A0

I updated the text as follows:

Name resolution APIs and libraries MUST NOT recognize na= mes that end in '.homenet.' as special an MUST NOT treat them diffe= rently. Name resolution APIs MUST send queries for such names to their conf= igured caching DNS server(s). Using a caching server other than the server = or servers offered by the home network will result in failure to correctly = resolve queries for subdomains of '.homenet'. =C2=A0 If a host is c= onfigured to always use a resolver other than the one offered by the local = network, it will be unable to resolve queries that are subdomains of '.= homenet'.
=C2=A0
= In item 4, s/part of the domain/part or all of the '.homenet' domai= n/

updated

Given the existence of draft-ietf-dnsop-terminology-bis, it would be he= lpful (at least, I would find it helpful) to use the agreed common terminol= ogy; for example =E2=80=9Crecursive resolver=E2=80=9D instead of =E2=80=9CC= aching DNS servers=E2=80=9D.

I updat= ed the draft to use "recursive resolver" instead of "caching= name server" and sent a note to Paul asking him why there is no defin= ition for that term in the document. =C2=A0 :)

In the answer for ques= tion 5, it might help the reader to specify which zones the =E2=80=9Cauthor= itative servers=E2=80=9D are authoritative for.

=
Well, now, when I looked at the answer to question five, I reali= zed that the text is wrong. =C2=A0 There is no need to specify anything her= e. =C2=A0 If an authoritative server is configured to be authoritative for = .homenet or any subdomain(s) of .homenet, it will do the right thing. =C2= =A0 If it is not, it will do the right thing. =C2=A0 The text here requirin= g an auth server not to return an NS record for .homenet would only apply t= o the root operator, and we are addressing that in a different way. =C2=A0 = I think requiring special treatment for this name in an authoritative serve= r would be a mistake. =C2=A0 I have updated the text as follows:
=
Only a DNS server that is authoritative for the root ('.'= ) or is configured to be authoritative for '.homenet' or a subdomai= n of '.homenet' will ever answer a query about '.homenet.' = =C2=A0In both of these cases, the server should simply answer as configured= : no special handling is required.=C2=A0

= =E2=80=9CDNS server operator=E2=80=9D is likely a term of art in the answer= for question, but it=E2=80=99s not clear to me which operators and servers= are referred to, here.=C2=A0 Although passive voice should be avoided, it = might be appropriate to simply write =E2=80=9CDNS servers outside a home ne= twork should not be configured to be authoritative for .homenet.

I like your proposed text, and updated the doc= ument to use it.

Jacques Latour and Bob Harold got= into a conversation where Jacque said:

= Where do you delegate homenet to? Advanced DNSSEC validation may check for = proper delegation? =C2=A0

This is ac= tually addressed in the IANA considerations: the proposal is to do an unsig= ned delegation to the AS112 servers. =C2=A0 However, the document doesn'= ;t actually do anything to make sure that that delegation will produce the = right result.=C2=A0 I do not know how to address this.
=C2=A0
Bob then asked:

If an insecure delegation can be made in the ro= ot, then could a local trust anchor be used by those who want their .homene= t domain DNSSEC validated?=C2=A0

I a= dded the following text to the security considerations to address this:

In order to enable DNSSEC validation of a particular '= .homenet', it might make sense to configure a trust anchor for that hom= enet. =C2=A0 How this might be done is out of scope for this document.
=C2=A0
Andrew Sullivan wrote, regarding draft-= ietf-homenet-redact:

= in =C2=B61 of =C2=A71, "This document recommends the use of the '.= home'=E2=80=A6."=C2=A0reads as tho= ugh the present document (i.e. the I-D itself) is making=C2=A0the recommendation.=C2=A0 Perhaps "That document&qu= ot; instead would work, or=C2=A0"Said RFC", or something.<= /blockquote>

=C2=A0I think "that document" doe= s the job=E2=80=94thanks for catching this.

= Andrew also raised the point about the unsigned root zone delegation and th= e process woes that might follow such a request. =C2=A0 The working group a= ppears to have decided to try going down that path despite the potential pr= oblems it presents, so I will say no more about that here.

He also wrote:
= In =C2=A71, "evidence indicates that '.home' queries frequentl= y leak out=C2=A0and reach the root name ser= vers [ICANN1] [ICANN2]", I don't think=C2=A0that's the issue.=C2=A0 The issue is that home is a well-know= n, in use TLD=C2=A0(we know because of thos= e queries), and the consequences of reusing it=C2=A0are therefore co= mpletely unknown.

I updated this according = to Ralph's suggestion, which I believe hit on the same point. =C2=A0 Pl= ease let me know if you think further clarification or deincorrectification= is required.

New versions of these documents will= be hitting the datatracker shortly. =C2=A0 If you feel that you had some c= omment that was not addressed, please let me know: I did my best not to ign= ore what anybody said, but there was a long thread, so I may have done so a= nyway.=C2=A0
--001a114065b2792bfd054676f9b0-- From nobody Thu Jan 19 10:54:30 2017 Return-Path: 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 8222B12951F for ; Thu, 19 Jan 2017 10:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SN90lGmdZwrz for ; Thu, 19 Jan 2017 10:54:24 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 E3C3B1294AC for ; Thu, 19 Jan 2017 10:54:23 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id f144so15520877pfa.2 for ; Thu, 19 Jan 2017 10:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=HcPf0FZEBraAxlILA+VVJgPgZCdWWZE0dCEjW7EWB2A=; b=kpqkslJPcoKVn0BPShsmmIVRLcNRQnpSdD+l+seugn/nKa4F1awjg0CoTMXLirLhAn 97d8NQ9gYzRhgjIfXOtRYplgniM9tFyvqTly78T949Ryr3+SyT9Tbbbi7PM+JAkKD4lL jzVtYOFq0SpvZg5Lbkb0rhvUUMUz8VwCxx65Rti6ujcP/IdDZueh6dxpVqLOYoRQXMtr sod3aIccevo1Y07dg1QL+Fj8y5xoQRAgIOPumP7uyiJ7TYUyqcvP48fIyof7giGjTWFl Qfu0zsEhJQkJhrtIYldYjZ458dcN2OrZhWCQ5A6NzWYX/eVegMER4+CRmSLROXId5WSM e8eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=HcPf0FZEBraAxlILA+VVJgPgZCdWWZE0dCEjW7EWB2A=; b=uIrjzErD4asad47B0wX0HlYDPRdzdKB33VpQMILwqhdPaSCreTIgwvrtvk3XWGHw7o Trycpyy/4I5WBRdVXuiIJINJXWQLVblP3rEaJ2fAwrC5ZZyIotCuxUjA4QJKehXr5dAx UyqoiwUJ4XS/KmqqOJbkQCJXBy9LHGlp8BFJA+h+wBfCl7ff2RSkruiaRKgwYSDCwk59 FI3hCNWHGwk/pYImGdSjMOl52NPeCOP9PMGcvCs2fEXBv7oJiunF9Tvs06LODtAMEbDX Dc4lkcVwqvjPAU5M0FQOeoxVGLMHqg47Z+3Ikj7BPQeEJgTtiE9mwYUsrtOVIQorf556 4QIQ== X-Gm-Message-State: AIkVDXLMtojRKOtpp/N9TQBNjp1Pt9jvPcIHFSBUvOYY8UPqFKxDwKLcqBkKXTbH+GnDDkuq X-Received: by 10.99.173.14 with SMTP id g14mr12007355pgf.176.1484852063147; Thu, 19 Jan 2017 10:54:23 -0800 (PST) Received: from dhcp-100-99-230-134.pao.corp.google.com ([100.99.230.134]) by smtp.gmail.com with ESMTPSA id x16sm10560072pfk.79.2017.01.19.10.54.22 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 19 Jan 2017 10:54:22 -0800 (PST) From: james woodyatt Content-Type: multipart/alternative; boundary="Apple-Mail=_63ACC5B0-CC33-4413-88F2-8805ACC4F0D2" Message-Id: <09F6092C-98E5-4F5A-9DB3-101C5990EF83@google.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Thu, 19 Jan 2017 10:54:21 -0800 References: <53A6A7D7-05D1-4CBB-AAC2-E19BEB3B590C@google.com> To: HOMENET In-Reply-To: <53A6A7D7-05D1-4CBB-AAC2-E19BEB3B590C@google.com> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [homenet] I-D.templin-intarea-rio-redirect X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:54:25 -0000 --Apple-Mail=_63ACC5B0-CC33-4413-88F2-8805ACC4F0D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, Update: I=E2=80=99ve accepted Fred=E2=80=99s invitation to be a = co-author on this draft. I think it would be really helpful to have the = opinions of anyone here with experiencing implementing and deploying = HOMENET routers. On Jan 9, 2017, at 10:51, james woodyatt wrote: >=20 > Hey HOMENET, >=20 > I notice over in 6MAN that Fred Templin has written an interesting = draft. >=20 > Route Information Options in Redirect Messages > > >=20 > I think anyone interested in the problems for which HOMENET is = chartered to solve should review and comment. Especially recommended for = anyone who might be implementing a HOMENET router. My impression is that = host operating system maintainers and operators have resisted = implementing RIO processing in RA messages due to operational = considerations associated with RA validation. Maybe those people would = be happier with hosts processing them in ND Redirect messages instead. >=20 > What does everyone else think? --james woodyatt > --Apple-Mail=_63ACC5B0-CC33-4413-88F2-8805ACC4F0D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi everyone,

Update: I=E2=80=99ve accepted Fred=E2=80=99s invitation to be = a co-author on this draft. I think it would be really helpful to have = the opinions of anyone here with experiencing implementing and deploying = HOMENET routers.

On = Jan 9, 2017, at 10:51, james woodyatt <jhw@google.com> = wrote:

--james woodyatt <jhw@google.com>



= --Apple-Mail=_63ACC5B0-CC33-4413-88F2-8805ACC4F0D2-- From nobody Thu Jan 19 11:18:48 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B70129407; Thu, 19 Jan 2017 11:18:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148485352715.10406.13013453439683737028.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 11:18:47 -0800 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-dot-01.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:18:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Special Use Top Level Domain '.homenet' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-01.txt Pages : 7 Date : 2017-01-19 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.homenet.', and designates this top-level domain as a special-use domain name. The '.homenet' top-level domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 19 11:19:03 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2380812953C; Thu, 19 Jan 2017 11:18:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148485353713.10313.15695434295734804941.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 11:18:57 -0800 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-redact-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:18:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Redacting .home from HNCP Author : Ted Lemon Filename : draft-ietf-homenet-redact-02.txt Pages : 3 Date : 2017-01-19 Abstract: This document updates the Home Networking Control Protocol, eliminating the recommendation for a default top-level name for local name resolution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-redact/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-redact-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-redact-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 30 09:44:10 2017 Return-Path: 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 A8E0B129A28 for ; Mon, 30 Jan 2017 09:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 EWas2QCheJSq for ; Mon, 30 Jan 2017 09:44:07 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 3BC8C129A30 for ; Mon, 30 Jan 2017 09:44:05 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s140so137410387qke.0 for ; Mon, 30 Jan 2017 09:44:05 -0800 (PST) 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=2SsJH6KrFgGsE6WgrG/b07MiqIB+woa27B2QqsmORGY=; b=Cn+dqADxgkmGSbMpX11Rqk71OcJA2kjBnn2ndtStpDH/JtAxF/M7uEHidKMP1roDNE ZikvNnB6d9o93fsCPY0T1HkuDVi2LnrzV8AQ7Q7sLUUSo5xDQvmhGgbu+rm2DeAjbbAW lAVeWf3LaLH+v/cFNbDGl5VdWByghTHZiyRzpzTuXvPqZRF/e5i2FgoeiGoAu6Gz3XC8 xK0Oqr3bautEkUaWuhpH671fhVMg8A9lTFXmK7UcY8Jv/Doq7xjNb9Ea69DQYp30WiPi 6G/4pa9C16gEYaF1heumZY4LEb9/sC8CV6ntItIzQMaLr7CO4zmu8uu3WfbVHqe0IXEX JkUg== 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=2SsJH6KrFgGsE6WgrG/b07MiqIB+woa27B2QqsmORGY=; b=oq6tdc6UzdRfK64ahGlXbB7P5pmAj7+j8lg2EAKhil1GouFR/nBzNQqarIqi1ZYen6 9nBI6tdnK2AWyZCfUjQD4x+KqLSCtlbdSNEXpcAgFpBxRzwAhB4RU13SrQKlBxe5+ReE wA/TCZm4x2ZLjNoS8b4EMTC/tpDtx+tffO62H/dRMCWjr33+ozgOSENdHDbPlt+S7o/L hAcwHYXTKQY2SL2RcXhzUDd5xEtu4jvxWFVfCTmOfgwWAN6UpoTCyYJLwhJc9pA5i3X7 g7MWD7IFYpjT2nQFxGvsARA8CdYTrXvsblKHKBAyH/6LxjU7UrhzGbAmkC3tHW51aJZw 2/cA== X-Gm-Message-State: AIkVDXJrzzwf+dcqB2/W4nJ97MMqJMnWiNAVC+whzXuX38UhE6wp4TN9XGmXu1GYP97LKQ== X-Received: by 10.55.180.129 with SMTP id d123mr22019636qkf.158.1485798244250; Mon, 30 Jan 2017 09:44:04 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:85d3:a4fe:5e55:a31c? ([2601:18f:801:600:85d3:a4fe:5e55:a31c]) by smtp.gmail.com with ESMTPSA id k18sm12804029qtc.12.2017.01.30.09.44.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 09:44:03 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-977BDD74-16CB-4948-ABF3-806A2DBC7D3B Mime-Version: 1.0 (1.0) From: Ralph Droms X-Mailer: iPad Mail (14C92) In-Reply-To: Date: Mon, 30 Jan 2017 12:44:02 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: To: Ted Lemon Archived-At: Cc: HOMENET Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 17:44:09 -0000 --Apple-Mail-977BDD74-16CB-4948-ABF3-806A2DBC7D3B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jan 19, 2017, at 1:47 PM, Ted Lemon wrote: >=20 > Here are my notes from updating the above two drafts. Ted - thanks for the notes. In general, I think you've addressed my comment= s and the document is ready to be forwarded to the IESG. I do have one rema= ining small issue (see inline). >=20 > Ralph Droms writes regarding draft-ietf-homenet-dothome: >> I suggest that the paragraph in the Introduction that motivates the chang= e from .home to .homenet be augmented or replaced with the reasons Ray liste= d in earlier e-mail: >>=20 >>=20 >>=20 >> 1. we cannot be sure that using .home is consistent with the existing (a= b)use >>=20 >> 2. ICANN is in receipt of about a dozen applications for ".home", and so= me of those applicants no doubt have deeper pockets than the IETF does shoul= d they decide to litigate >>=20 > I updated the text as follows: >=20 > The '.homenet' top-level domain replaces '.home' which was specified in [R= FC7788] as the default domain-name for home networks. '.home' had been selec= ted as the most user-friendly option. However, there are existing uses of '= .home' that may be in conflict with this use: evidence indicates that '.home= ' queries frequently leak out and reach the root name servers [ICANN1] [ICAN= N2]. Also, ICANN has about a dozen applicants for the '.home' top-level dom= ain name, which creates a significant risk of litigation if it were claimed b= y the IETF outside of that process. As a result, the use of '.home' has bee= n deprecated; this document updates [RFC7788] to replace '.home' with '.home= net', while another document, [I-D.ietf-homenet-redact] deprecates the use o= f the '.home' TLD.=20 Ok. >=20 >> This sentence appears in section 2: >>> Names ending with '.homenet.' MUST refer to services that are located w= ithin a home network (e.g., a printer, or a toaster). >> I think "services" is too restrictive; in fact, the examples are really d= evices or hosts, not services provided by those devices. What is the restri= ction "located within a home network", and what, exactly, does it mean? In m= y opinion, this document should focus on name evaluation within the .homenet= locally served zone.=20 >=20 > I updated the text as follows: >=20 > The top-level domain name '.homenet.' is to be used for naming within a ho= me network. Names ending with '.homenet.' reference a locally-served zone, t= he contents of which are unique only to a particular home network, and are n= ot globally unique. Such names refer to nodes and/or services that are loca= ted within a home network (e.g., a printer, or a toaster). Ok. >=20 >> Also in section 2, the phrase "Although home networks most often provide= one or more service discovery mechanisms," assumes the reader knows that ma= ny service discovery mechanisms hide the domain name of the service or host a= nd, hence, .homenet. >=20 > I updated the text as follows:=20 >=20 > Some service discovery user interfaces that are expected to be used on hom= enets conceal information such as domain names from end users. However, it i= s still expected that in some cases, users will need to see, remember, and e= ven type, names ending with '.homenet'. It is therefore desirable that users= identify the top-level domain and understand that using it expresses the in= tention to connect to a service that is specific to the home network to whic= h they are connected. Enforcing the fulfillment of this intention is out of= scope for this document. Ok. >=20 >> In section 3, the response to item 3 in the SUDN reservation consideratio= ns could be clarified by specifying that any queries in the .homenet zone mu= st be forwarded to a DNS service as configured by explicitly by HNCP or othe= r appropriate local configuration mechanism coordinated with .homenet resolu= tion, as opposed to just =E2=80=9Cconfigured=E2=80=9D. A manually configure= d entry for some external server is =E2=80=9Cconfigured=E2=80=9D, but not co= nfigured in a helpful way. >> Also in item 3, s/for '.homenet'./for domain names ending in '.homenet'/=20= >=20 > I updated the text as follows: >=20 > Name resolution APIs and libraries MUST NOT recognize names that end in '.= homenet.' as special an MUST NOT treat them differently. Name resolution API= s MUST send queries for such names to their configured caching DNS server(s)= . Using a caching server other than the server or servers offered by the hom= e network will result in failure to correctly resolve queries for subdomains= of '.homenet'. If a host is configured to always use a resolver other tha= n the one offered by the local network, it will be unable to resolve queries= that are subdomains of '.homenet'. I think this is almost right, but still misses the explicit requirement the "= configured ... servers" be the servers in the home network. Perhaps: Name resolution APIs MUST send queries for such name to a recursive DNS serv= er configured to be authoritative for the .homenet zone appropriate to the h= ome network. This RDNSS or list of RDNSSes will usually be supplied to the c= lient through a local configuration mechanism like HNCP or DHCP. If a host i= s configured to use a resolver other than one that is authoritative for the a= ppropriate .homenet zone, the client may be unable to resolve or receive inc= orrect results for names in sub domains of ".homenet". > =20 >> In item 4, s/part of the domain/part or all of the '.homenet' domain/ > updated >=20 Ok. >> Given the existence of draft-ietf-dnsop-terminology-bis, it would be help= ful (at least, I would find it helpful) to use the agreed common terminology= ; for example =E2=80=9Crecursive resolver=E2=80=9D instead of =E2=80=9CCachi= ng DNS servers=E2=80=9D. >=20 > I updated the draft to use "recursive resolver" instead of "caching name s= erver" and sent a note to Paul asking him why there is no definition for tha= t term in the document. :) Ok. I threw "RDNSS" in the text above, dunno which term is best. >=20 >> In the answer for question 5, it might help the reader to specify which z= ones the =E2=80=9Cauthoritative servers=E2=80=9D are authoritative for. >=20 >=20 > Well, now, when I looked at the answer to question five, I realized that t= he text is wrong. There is no need to specify anything here. If an autho= ritative server is configured to be authoritative for .homenet or any subdom= ain(s) of .homenet, it will do the right thing. If it is not, it will do t= he right thing. The text here requiring an auth server not to return an NS= record for .homenet would only apply to the root operator, and we are addre= ssing that in a different way. I think requiring special treatment for thi= s name in an authoritative server would be a mistake. I have updated the t= ext as follows: >=20 > Only a DNS server that is authoritative for the root ('.') or is configure= d to be authoritative for '.homenet' or a subdomain of '.homenet' will ever a= nswer a query about '.homenet.' In both of these cases, the server should s= imply answer as configured: no special handling is required.=20 Good catch and I agree with your new text. >=20 >> =E2=80=9CDNS server operator=E2=80=9D is likely a term of art in the answ= er for question, but it=E2=80=99s not clear to me which operators and server= s are referred to, here. Although passive voice should be avoided, it might= be appropriate to simply write =E2=80=9CDNS servers outside a home network s= hould not be configured to be authoritative for .homenet. >=20 > I like your proposed text, and updated the document to use it. Ok. - Ralph >=20 > Jacques Latour and Bob Harold got into a conversation where Jacque said: >=20 >> Where do you delegate homenet to? Advanced DNSSEC validation may check fo= r proper delegation? =20 >=20 > This is actually addressed in the IANA considerations: the proposal is to d= o an unsigned delegation to the AS112 servers. However, the document doesn= 't actually do anything to make sure that that delegation will produce the r= ight result. I do not know how to address this. > =20 > Bob then asked: >=20 >> If an insecure delegation can be made in the root, then could a local tru= st anchor be used by those who want their .homenet domain DNSSEC validated?=20= >=20 > I added the following text to the security considerations to address this:= >=20 > In order to enable DNSSEC validation of a particular '.homenet', it might m= ake sense to configure a trust anchor for that homenet. How this might be d= one is out of scope for this document. > =20 > Andrew Sullivan wrote, regarding draft-ietf-homenet-redact: >=20 >> in =C2=B61 of =C2=A71, "This document recommends the use of the '.home'=E2= =80=A6." reads as though the present document (i.e. the I-D itself) is makin= g the recommendation. Perhaps "That document" instead would work, or "Said R= FC", or something. >=20 > I think "that document" does the job=E2=80=94thanks for catching this. >=20 > Andrew also raised the point about the unsigned root zone delegation and t= he process woes that might follow such a request. The working group appear= s to have decided to try going down that path despite the potential problems= it presents, so I will say no more about that here. >=20 > He also wrote: >> In =C2=A71, "evidence indicates that '.home' queries frequently leak out a= nd reach the root name servers [ICANN1] [ICANN2]", I don't think that's the i= ssue. The issue is that home is a well-known, in use TLD (we know because o= f those queries), and the consequences of reusing it are therefore completel= y unknown. >=20 > I updated this according to Ralph's suggestion, which I believe hit on the= same point. Please let me know if you think further clarification or dein= correctification is required. >=20 > New versions of these documents will be hitting the datatracker shortly. = If you feel that you had some comment that was not addressed, please let me= know: I did my best not to ignore what anybody said, but there was a long t= hread, so I may have done so anyway.=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail-977BDD74-16CB-4948-ABF3-806A2DBC7D3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On Jan 1= 9, 2017, at 1:47 PM, Ted Lemon <mello= n@fugue.com> wrote:

Here are my notes from updating the above two drafts.
=

Ted - thanks for the notes.  In general, I t= hink you've addressed my comments and the document is ready to be forwarded t= o the IESG.  I do have one remaining small issue (see inline).

=

Ralph Dr= oms writes regarding draft-ietf-homenet-dothome:

I suggest that the paragraph i= n the Introduction that motivates the change from .home to .homenet be augme= nted or replaced with the reasons Ray listed in earlier e-mail:


1.  we cannot be sure th= at using .home is consistent with the existing (ab)use

2.  ICANN is in receipt o= f about a dozen applications for ".home", and some of those applicants no do= ubt have deeper pockets than the IETF does should they decide to litigate

I updated the text as follows:

= The '.homenet' top-level domain replaces '.home' which was specified in [RFC= 7788] as the default domain-name for home networks. '.home' had been selecte= d as the most user-friendly option.  However, there are existing uses o= f '.home' that may be in conflict with this use: evidence indicates that '.h= ome' queries frequently leak out and reach the root name servers [ICANN1] [I= CANN2].  Also, ICANN has about a dozen applicants for the '.home' top-l= evel domain name, which creates a significant risk of litigation if it were c= laimed by the IETF outside of that process.  As a result, the use of '.= home' has been deprecated; this document updates [RFC7788] to replace '.home= ' with '.homenet', while another document, [I-D.ietf-homenet-redact] depreca= tes the use of the '.home' TLD. 

Ok.

<= div>

This sentence appears in section 2= :
 Names end= ing with '.homenet.'  MUST refer to&nbs= p;services that are located within a home network (e.g., a printer, or a toaster).
I think "services" is too restrictive; i= n fact, the examples are really devices or hosts, not services provided by t= hose devices.  What is the restriction "located within a home network",= and what, exactly, does it mean?  In my opinion, this document should f= ocus on name evaluation within the .homenet locally served zone. = ;

I updated the text as follows:

The top-level domain name '.homenet.' is to be used for n= aming within a home network. Names ending with '.homenet.' reference a local= ly-served zone, the contents of which are unique only to a particular home n= etwork, and are not globally unique.  Such names refer to nodes and/or s= ervices that are located within a home network (e.g., a printer, or a toaste= r).

Ok.


 Also in section 2, the phrase "Although= home networks most often provide one or more service discovery mechanisms,"= assumes the reader knows that many service discovery mechanisms hide the do= main name of the service or host and, hence, .homenet.

I updated the text as follows: 

<= blockquote style=3D"margin:0px 0px 0px 40px;border:none;padding:0px">
So= me service discovery user interfaces that are expected to be used on homenet= s conceal information such as domain names from end users.  However, it= is still expected that in some cases, users will need to see, remember, and= even type, names ending with '.homenet'. It is therefore desirable that use= rs identify the top-level domain and understand that using it expresses the i= ntention to connect to a service that is specific to the home network to whi= ch they are connected.  Enforcing the fulfillment of this intention is o= ut of scope for this document.

Ok.


In= section 3, the response to item 3 in the SUDN reservation considerations co= uld 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 app= ropriate local configuration mechanism coordinated with .homenet resolution,= as opposed to just =E2=80=9Cconfigured=E2=80=9D.  A manually configure= d entry for some external server is =E2=80=9Cconfigured=E2=80=9D, but not co= nfigured in a helpful way.
Also in item 3, s/for '.home= net'./for domain names ending in '.homenet'/ 

I updated the text as follows:

Name r= esolution APIs and libraries MUST NOT recognize names that end in '.homenet.= ' as special an MUST NOT treat them differently. Name resolution APIs MUST s= end queries for such names to their configured caching DNS server(s). Using a= caching server other than the server or servers offered by the home network= will result in failure to correctly resolve queries for subdomains of '.hom= enet'.   If a host is configured to always use a resolver other than th= e one offered by the local network, it will be unable to resolve queries tha= t are subdomains of '.homenet'.
<= div>
I think this is almost right, but still misses the explicit re= quirement the "configured ... servers" be the servers in the home network.

Perhaps:

Name resolution AP= Is MUST send queries for such name to a recursive DNS server configured to b= e authoritative for the .homenet zone appropriate to the home network.  = ;This RDNSS or list of RDNSSes will usually be supplied to the client throug= h a local configuration mechanism like HNCP or DHCP.  If a host is conf= igured to use a resolver other than one that is authoritative for the approp= riate .homenet zone, the client may be unable to resolve or receive incorrec= t results for names in sub domains of ".homenet".

<= blockquote type=3D"cite">
 
In= item 4, s/part of the domain/part or all of the '.homenet' domain/

updated

<= div>
Ok.

Given the existence of draft-ietf-dnsop-terminology-bis, it would be helpf= ul (at least, I would find it helpful) to use the agreed common terminology;= for example =E2=80=9Crecursive resolver=E2=80=9D instead of =E2=80=9CCachin= g DNS servers=E2=80=9D.

I updated the= draft to use "recursive resolver" instead of "caching name server" and sent= a note to Paul asking him why there is no definition for that term in the d= ocument.   :)

Ok. &n= bsp;I threw "RDNSS" in the text above, dunno which term is best.

In the answer for question 5, it might help= the reader to specify which zones the =E2=80=9Cauthoritative servers=E2=80=9D= are authoritative for.

Well, now, whe= n I looked at the answer to question five, I realized that the text is wrong= .   There is no need to specify anything here.   If an authoritati= ve server is configured to be authoritative for .homenet or any subdomain(s)= of .homenet, it will do the right thing.   If it is not, it will do th= e right thing.   The text here requiring an auth server not to return a= n NS record for .homenet would only apply to the root operator, and we are a= ddressing that in a different way.   I think requiring special treatmen= t for this name in an authoritative server would be a mistake.   I have= updated the text as follows:

Only a DNS server that is a= uthoritative for the root ('.') or is configured to be authoritative for '.h= omenet' or a subdomain of '.homenet' will ever answer a query about '.homene= t.'  In both of these cases, the server should simply answer as configu= red: no special handling is required. 

Good catch and I agree with your new text.


=E2= =80=9CDNS server operator=E2=80=9D is likely a term of art in the answer for= question, but it=E2=80=99s not clear to me which operators and servers are r= eferred to, here.  Although passive voice should be avoided, it might b= e appropriate to simply write =E2=80=9CDNS servers outside a home network sh= ould not be configured to be authoritative for .homenet.
=

I like your proposed text, and updated the document to u= se it.

Ok.

=
- Ralph

<= div>
Jacques Latour and Bob Harold got into a conversation whe= re Jacque said:

Wh= ere do you delegate homenet to? Advanced DNSSEC validation may check for pro= per delegation?  

This is actual= ly addressed in the IANA considerations: the proposal is to do an unsigned d= elegation to the AS112 servers.   However, the document doesn't actuall= y do anything to make sure that that delegation will produce the right resul= t.  I do not know how to address this.
 
Bob then asked:

If an insecure delegation can be made in the root,= then could a local trust anchor be used by those who want their .homenet do= main DNSSEC validated? 

I added t= he following text to the security considerations to address this:
=
In order to enable DNSSEC validation of a particular '.homenet', it= might make sense to configure a trust anchor for that homenet.   How t= his might be done is out of scope for this document.
=  
Andrew Sullivan wrote, regarding draft-ietf-homenet-redact:=

in= =C2=B61 of =C2=A71, "This document recommends the use of the '.home'=E2=80=A6= ." reads as though the present document= (i.e. the I-D itself) is making the re= commendation.  Perhaps "That document" instead would work, or "Said RFC", or something.

 I think "= that document" does the job=E2=80=94thanks for catching this.

Andrew also raised the point about the unsigned root zone d= elegation and the process woes that might follow such a request.   The w= orking group appears to have decided to try going down that path despite the= potential problems it presents, so I will say no more about that here.

He also wrote:
In= =C2=A71, "evidence indicates that '.home' queries frequently leak out = and reach the root name servers [ICANN1] [IC= ANN2]", I don't think that's the issue.=   The issue is that home is a well-known, in use TLD (we know because of those queries), and the consequences o= f reusing it are therefore completely unknown.
=
I updated this according to Ralph's suggestion, which I belie= ve hit on the same point.   Please let me know if you think further cla= rification or deincorrectification is required.

New= versions of these documents will be hitting the datatracker shortly.  = If you feel that you had some comment that was not addressed, please let me= know: I did my best not to ignore what anybody said, but there was a long t= hread, so I may have done so anyway. 
____________________= ___________________________
homenet mailing list
<= span>homenet@ietf.org
https://www.ietf= .org/mailman/listinfo/homenet
= = --Apple-Mail-977BDD74-16CB-4948-ABF3-806A2DBC7D3B-- From nobody Mon Jan 30 10:09:59 2017 Return-Path: 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 1B3FA129A7E for ; Mon, 30 Jan 2017 10:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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 BXl8Jd-QwHlB for ; Mon, 30 Jan 2017 10:09:54 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 7BC02129A7F for ; Mon, 30 Jan 2017 10:09:54 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id n124so198405310lfd.2 for ; Mon, 30 Jan 2017 10:09:54 -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; bh=XBZyqtZMfv41yC4kIR7GdjZ9UzZhBDSPRRB+Rhk5apo=; b=oHo9QkbM6fyvipfKmZutG8dfUyZ0DMX0PvVq4wMDc2Tzvrb3KsaJ6H4jvVJVqTwoqt XnA5GAaDkQ8Mg8CZmBQ67wGbsCqLKleM4cA53MNkJ0ksTYuCHIo9/EaxsPmD6m1qJgH5 NYnLgBwyh+GrcHuHoYBG0BRUEaAmu1fdZiwj/zTnDr1gb84cRZN1SIvhxBXOSco6Mn5C OztXGestAIfO5PhkwbZMTFxEV6XnyZ631L35v6W49MWjcZvi7eYxZDCtKceHSruYytE5 jTVWJR+jrj2KC8eW0m8DLViFQ9cHP7RXe4NA5HwbCR9YyFUQ90GyMCtcCHvJa2tcnARE IWMw== 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:cc; bh=XBZyqtZMfv41yC4kIR7GdjZ9UzZhBDSPRRB+Rhk5apo=; b=ViOl3pyaNHKDY/OkOGIubToI0RSUgjPEYzGVPkQbqPYh/++5o8gHMG7EZh0RZMI/Br oyf0nrzl6Zn/URvQ6b+yXcRIeUMCh6EyD0lYcBCvcWFTcEsroh4qpsNjulxOmVGNgOb8 yvu01YU52XfGGEtbO0SNsYZeqClioYKp0ok3+LA6rCRB+ZGMvUyL4+1mTXauSdc5km5P i535xbrvv8CPDNiwikEXjY2mp7nxOlWFY3e9aT8keEuU9HWuAFhGXsPKT+LTkwjIZTQ+ aeuxxbwphCWvw/qNyc6rCGGwRIv8lQGJpyermBbPRMvJ/cmM4NEG34kAMhC6nmCShqGo ZWPQ== X-Gm-Message-State: AIkVDXLwEgj0lDKx6bGms7x8Ux93h+3w8MgnVjo+PALJzBiS/w7ztO4Gp5WiIE4v1rUukAFL00lwNY+g8up3bw== X-Received: by 10.25.34.196 with SMTP id i187mr7735904lfi.176.1485799792569; Mon, 30 Jan 2017 10:09:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.20.67 with HTTP; Mon, 30 Jan 2017 10:09:51 -0800 (PST) Received: by 10.25.20.67 with HTTP; Mon, 30 Jan 2017 10:09:51 -0800 (PST) In-Reply-To: References: From: Ted Lemon Date: Mon, 30 Jan 2017 13:09:51 -0500 Message-ID: To: Ralph Droms Content-Type: multipart/alternative; boundary=001a113a9ea0d80641054753b867 Archived-At: Cc: HOMENET Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 18:09:56 -0000 --001a113a9ea0d80641054753b867 Content-Type: text/plain; charset=UTF-8 On Jan 30, 2017 12:44 PM, "Ralph Droms" wrote: Name resolution APIs MUST send queries for such name to a recursive DNS server configured to be authoritative for the .homenet zone appropriate to the home network. This RDNSS or list of RDNSSes will usually be supplied to the client through a local configuration mechanism like HNCP or DHCP. If a host is configured to use a resolver other than one that is authoritative for the appropriate .homenet zone, the client may be unable to resolve or receive incorrect results for names in sub domains of ".homenet". The problem with this is that you're asking the resolver to know that it is talking to a homenet. I would rather describe the problem than write normative text that fixes it. --001a113a9ea0d80641054753b867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Jan 30, 20= 17 12:44 PM, "Ralph Droms" <rdroms.ietf@gmail.com> wrote:
<= div dir=3D"auto">
<= div>Name resolution APIs MUST send queries for such name to a recursive DNS= server configured to be authoritative for the .homenet zone appropriate to= the home network.=C2=A0 This RDNSS or list of RDNSSes will usually be supp= lied to the client through a local configuration mechanism like HNCP or DHC= P.=C2=A0 If a host is configured to use a resolver other than one that is a= uthoritative for the appropriate .homenet zone, the client may be unable to= resolve or receive incorrect results for names in sub domains of ".ho= menet".
The problem with this is that you're asking t= he resolver to know that it is talking to a homenet. =C2=A0 I would rather = describe the problem than write normative text that fixes it.
--001a113a9ea0d80641054753b867-- From nobody Mon Jan 30 10:26:41 2017 Return-Path: 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 D03D3129A76 for ; Mon, 30 Jan 2017 10:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=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 jDTbGIkBS3D6 for ; Mon, 30 Jan 2017 10:26:38 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 6238512952D for ; Mon, 30 Jan 2017 10:26:38 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u25so138130166qki.2 for ; Mon, 30 Jan 2017 10:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=12g26TbJrXUYLdbNWsbPvBHm4cUsbp9L/0zRs+fvCjQ=; b=TPFOUG8C4btO1yxvTRgJpnACa+iitjawldT7wu2PgHdeRN+A0AKW1uKg3xTDeNfIaG 5FkKV1WAf19B+ZQZLHx654NP6OIbSxO6Ud7ShLPjBOZn2yJAaRP5vVXZhbwwlk22z4qj Bisfv975AF4Q72O3Z+CGHPKEP9yDiPWGSPr20HIxh8d2rQAvpYFeQ4eYags63N4LLi+A 5Cdx5Za2u1IEW/WhxMSJNEzxEfl8vm/87XuXxynkt3Q9PI6ClO8fmaH7ZJTg3U/qQzln m2kWnI920N2VSQSuQBqC9kvaa5ySXLfJRLN48FEz+gcW0+OgSEAzJUnB/Fy6afcoMUkQ Roqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=12g26TbJrXUYLdbNWsbPvBHm4cUsbp9L/0zRs+fvCjQ=; b=D0HHpYPhg84O7swI86GqJmHv7q09m1Yinh/pjiN0yZDhl+uXgoDOr9geXmFcyIlJV0 uJE9Lq+zdCGtMqdym/fY4+afRuicP3eOahU0BxXbYa4ZLKPE0cFUZ3wjsew88Gptu6Xy +hJ42TLILA0Onee7RsHqXSv3GLhwqib0BduQvor2qMIv4t7hE5jc3jh1AbgtJW/JMHB/ 0e29hZCCKELvq8CEzYux/b/VJTsK5cY260OAb145wLNyLhmMiePZvgPCDjKXRTdWN031 F72EjCTXpV28Db4Dv8Wogu898lffxnyxALH3rx6oV6UvHo4AxPijq/6t9jvQK0qydIew CpTA== X-Gm-Message-State: AIkVDXKc3VzExpESwu11FXXsQWr+5G7EydMf/vCMrRtncHl1kVJvkWSUfuRh/RXcuqQoow== X-Received: by 10.55.214.207 with SMTP id p76mr22451507qkl.241.1485800797458; Mon, 30 Jan 2017 10:26:37 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:c1be:bbd3:f770:412? ([2601:18f:801:600:c1be:bbd3:f770:412]) by smtp.gmail.com with ESMTPSA id 7sm12925284qkx.49.2017.01.30.10.26.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 10:26:37 -0800 (PST) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CA8A473E-8B1B-4002-96C3-C195154507BA" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 30 Jan 2017 13:26:34 -0500 In-Reply-To: To: Ted Lemon References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: HOMENET Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 18:26:40 -0000 --Apple-Mail=_CA8A473E-8B1B-4002-96C3-C195154507BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 30, 2017, at 1:09 PM, Ted Lemon wrote: >=20 > On Jan 30, 2017 12:44 PM, "Ralph Droms" > wrote: > Name resolution APIs MUST send queries for such name to a recursive = DNS server configured to be authoritative for the .homenet zone = appropriate to the home network. This RDNSS or list of RDNSSes will = usually be supplied to the client through a local configuration = mechanism like HNCP or DHCP. If a host is configured to use a resolver = other than one that is authoritative for the appropriate .homenet zone, = the client may be unable to resolve or receive incorrect results for = names in sub domains of ".homenet". >=20 > The problem with this is that you're asking the resolver to know that = it is talking to a homenet. I would rather describe the problem than = write normative text that fixes it. Ah, of course, I see your point. On the other hand "MUST send queries = for such names to their configured caching DNS server(s)" seems to me to = have no content - what else would the client API do but send queries to = the configured servers? 2nd try: Name resolution APIs and libraries MUST NOT recognize names that end in = '.homenet.' as special and MUST NOT treat them differently. Name = resolution APIs will only resolve such a name correctly if the query is = sent to a recursive DNS server configured to be authoritative for the = .homenet zone appropriate to the home network. This RDNSS or list of = RDNSSes will usually be supplied to the client through a local = configuration mechanism like HNCP or DHCP. If a host is configured to = use a resolver other than one that is authoritative for the appropriate = .homenet zone, the client may be unable to resolve or receive incorrect = results for names in sub domains of ".homenet". - Ralph --Apple-Mail=_CA8A473E-8B1B-4002-96C3-C195154507BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 30, 2017, at 1:09 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Jan 30, 2017 12:44 PM, = "Ralph Droms" <rdroms.ietf@gmail.com> = wrote:
Name resolution APIs MUST send queries for = such name to a recursive DNS server configured to be authoritative for = the .homenet zone appropriate to the home network.  This RDNSS or = list of RDNSSes will usually be supplied to the client through a local = configuration mechanism like HNCP or DHCP.  If a host is configured = to use a resolver other than one that is authoritative for the = appropriate .homenet zone, the client may be unable to resolve or = receive incorrect results for names in sub domains of = ".homenet".

The problem = with this is that you're asking the resolver to know that it is talking = to a homenet.   I would rather describe the problem than write = normative text that fixes it.

Ah, of course, I see your point.  On the other hand = "MUST send = queries for such names to their configured caching DNS server(s)" seems = to me to have no content - what else would the client API do but send = queries to the configured servers?

2nd try:

Name = resolution APIs and libraries MUST NOT recognize names that end in = '.homenet.' as special and MUST NOT treat them differently. =  Name resolution = APIs will only resolve such a name correctly if the query is sent to = a recursive DNS server configured to be authoritative for = the .homenet zone appropriate to the home network.  This RDNSS or = list of RDNSSes will usually be supplied to the client through a local = configuration mechanism like HNCP or DHCP.  If a host is configured = to use a resolver other than one that is authoritative for the = appropriate .homenet zone, the client may be unable to resolve or = receive incorrect results for names in sub domains of = ".homenet".

- = Ralph

= --Apple-Mail=_CA8A473E-8B1B-4002-96C3-C195154507BA-- From nobody Mon Jan 30 12:04:54 2017 Return-Path: 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 D34C2129B53 for ; Mon, 30 Jan 2017 12:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 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_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 u6qE23oD1giB for ; Mon, 30 Jan 2017 12:04:52 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 137CB129B4F for ; Mon, 30 Jan 2017 12:04:52 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id l126so8796596qkc.1 for ; Mon, 30 Jan 2017 12:04:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mof13TuXdIql/0s5R+800rSraD+6EuDz8ImUpJ8eaJA=; b=MVOQmmufDWG+VdsauoMUoOcPtKbFXmvv7KcjazL0o89NAybLlCJX9VLIdudUb4r0ev y4BM+AuE1nT+XNd5aDmb/XMUILMsJoA+H65BmjivoOqyn1BJNwsp3otYWd1iSk4mFnaT 9abKOeyAR8BfOor1nrfex8KgFjxsc0YXu7R1By10MxaE/qazZzhokFGBsLqWCzj3r+wo oRKfdhZXOye1TEX612BgupqFwzBDyYcxAOpj+ALW7upt88Kg30LdahUrzMlYl8ZrnCw7 QfY4wEp7c1VpUPNGsmvMTjYRAbz6MUeuOmCtwOlARDJJcYqQ0AhBAid+hyi7hNS44eOC BotQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mof13TuXdIql/0s5R+800rSraD+6EuDz8ImUpJ8eaJA=; b=gCy/m22adyqwW1+AazE6+5PFMlB9Dh4ameVwnlO5idDWRPm51SdA74+vJSXzmxcIcV 6gx5z/91+YMnGkWvArgPmoctIzKB5T3mFRFi7OVH/Hk9MZOsM/rWWxIhTMZei2zDJHLj GSGIsWV5YwEUuprgSMhEJv6a1YdBTPF/yxKf0CVxwKWtT73Y6LrgCRt6t7dpkkUyOGKa D5VjXvTmThDEDQc7LwjsmHtdYji9UCWqHliqw5i1Y2Bwr69ot1P5o9ggW1iyJXl2BNlo 9ELz5Va3qx6xrLyz1OBbxUdKZB//Il4f+M8kqmfiE2GepYwA5iuZuJaqZT79y6A2Zqkt S2Og== X-Gm-Message-State: AIkVDXLxjXi4j6Q3glCp8MmYJ4dkQkT0X7CGUxYqMWbxklSIS83ZX4j4zFFyyE9aGFneYg== X-Received: by 10.55.22.219 with SMTP id 88mr23208055qkw.283.1485806690763; Mon, 30 Jan 2017 12:04:50 -0800 (PST) Received: from [10.70.104.179] ([64.94.31.206]) by smtp.gmail.com with ESMTPSA id w138sm13133024qka.27.2017.01.30.12.04.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 12:04:49 -0800 (PST) From: Ted Lemon Message-Id: <04633FA3-6478-493D-8AED-987547C37AAF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C0BB9CAC-4308-4BB2-B788-ABB67408D24A" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 30 Jan 2017 15:04:46 -0500 In-Reply-To: To: Ralph Droms References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: HOMENET Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:04:54 -0000 --Apple-Mail=_C0BB9CAC-4308-4BB2-B788-ABB67408D24A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 30, 2017, at 1:26 PM, Ralph Droms wrote: > Name resolution APIs and libraries MUST NOT recognize names that end = in '.homenet.' as special and MUST NOT treat them differently. Name = resolution APIs will only resolve such a name correctly if the query is = sent to a recursive DNS server configured to be authoritative for the = .homenet zone appropriate to the home network. This RDNSS or list of = RDNSSes will usually be supplied to the client through a local = configuration mechanism like HNCP or DHCP. If a host is configured to = use a resolver other than one that is authoritative for the appropriate = .homenet zone, the client may be unable to resolve or receive incorrect = results for names in sub domains of ".homenet". How about this: > Name resolution APIs and libraries MUST NOT recognize names that end = in '.homenet.' as special and MUST NOT treat them differently. Name = resolution APIs MUST send queries for such names to a recursive DNS = server that is configured to be authoritative for the .homenet zone = appropriate to the home network. One or more IP addresses for recursive = DNS servers will usually be supplied to the client through router = advertisements or DHCP. If a host is configured to use a resolver other = than one that is authoritative for the appropriate .homenet zone, the = client may be unable to resolve, or may receive incorrect results for, = names in sub domains of ".homenet".=20 I don't like RDNSS, so I expanded the acronym; I don't think that we = should mention HNCP here as a host configuration protocol. I also = cleaned up the last sentence a bit.= --Apple-Mail=_C0BB9CAC-4308-4BB2-B788-ABB67408D24A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Jan 30, 2017, at 1:26 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
Name resolution APIs and libraries MUST NOT recognize = names that end in '.homenet.' as special and MUST NOT treat them = differently.  Name = resolution APIs will only resolve such a name correctly if the query is = sent to a recursive DNS server configured to be = authoritative for the .homenet zone appropriate to the home = network.  This RDNSS or list of RDNSSes will usually be supplied to = the client through a local configuration mechanism like HNCP or = DHCP.  If a host is configured to use a resolver other than one = that is authoritative for the appropriate .homenet zone, the client may = be unable to resolve or receive incorrect results for names in sub = domains of ".homenet".

How about this:

Name = resolution APIs and libraries MUST NOT recognize names that end in = '.homenet.' as special and MUST NOT treat them differently. Name = resolution APIs MUST send queries for such names to a recursive DNS = server that is configured to be authoritative for the .homenet zone = appropriate to the home network.  One or more IP addresses for = recursive DNS servers will usually be supplied to the client through = router advertisements or DHCP.  If a host is configured to use a = resolver other than one that is authoritative for the appropriate = .homenet zone, the client may be unable to resolve, or may receive = incorrect results for, names in sub domains of = ".homenet". 

I don't like = RDNSS, so I expanded the acronym; I don't think that we should mention = HNCP here as a host configuration protocol.   I also cleaned up the = last sentence a bit.
= --Apple-Mail=_C0BB9CAC-4308-4BB2-B788-ABB67408D24A-- From nobody Mon Jan 30 12:11:14 2017 Return-Path: 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 AB3D9129B69 for ; Mon, 30 Jan 2017 12:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=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 kq30-RWh2tfY for ; Mon, 30 Jan 2017 12:11:12 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 27562129B67 for ; Mon, 30 Jan 2017 12:11:12 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id k15so215489435qtg.3 for ; Mon, 30 Jan 2017 12:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=x43X6VdA6qvKZhDcHrbipuMrRtGvJVhP5pvRlXQ0xAE=; b=iKmrvolNdwZ6tzueyPiUimfUXe5uDHySudz/Z+x41yrloReAGotzl1EAuJY/rN3iGN NYbLU15/+wIp34SVmt76f5pmPAsqeXWkkfehoU5RXj2HasYwTUKH5rNfmD5ouUc8VcHp araGbfHJzfus3e5KQl1IQelroDnhfIA6WLAT8WTa0LVAfn+4BzQvxkdo99+LdcNo99hy hdD/BP5D990SC+cBg0i339F2jZDXWjaeD2JFQLDPrFiIrtabwjbodMVGBDcax/+I9SZQ oUDVZeSZEsNyUTErP6tN2T8yfaPZL1PevzFR1wyCJSATw27PoLLJKramesmwXAgBp/R2 U3YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=x43X6VdA6qvKZhDcHrbipuMrRtGvJVhP5pvRlXQ0xAE=; b=LZFo0tS9HEecKLEaJsvLGp+jrXLrTaIerPIsUCeguBgRw9lWK56JIXfW3xiA87pPie 0YRFEnTc/ZxQiClUGN/yCBdiWj/KQSs6U0K5VMIkN3L94NsZXbWiKhYCVaJ5ATgYqBML G+3eWtt2Dmu6P3RC+im7y0I5gQVm/1FMA/NqvU2nHEv//Wh1kKv+4iPwN14Ojf2303jy K+NvO3Pxa2xV1VG86ow9Zf3DCxPTkqPYbYFbt8QfvFfXuq5rCZHYWGpgOUcQcXdqQwZe o3KGLUALWItO37ZGEAsq2hhHNUUAni5TSY+pNHfJBGucBS2Z9SV4MMKq9omDoMQo2aAE fbxg== X-Gm-Message-State: AIkVDXL/wV0ypLWgcB2ocvFAwoSv91dKgURdwpTYUc9LRDDRWHUBXU6MCiSQYT2ghtu6zg== X-Received: by 10.237.50.66 with SMTP id y60mr22922487qtd.12.1485807071291; Mon, 30 Jan 2017 12:11:11 -0800 (PST) Received: from ?IPv6:2601:18f:801:600:f834:ade1:189c:67f2? ([2601:18f:801:600:f834:ade1:189c:67f2]) by smtp.gmail.com with ESMTPSA id o99sm13174797qko.12.2017.01.30.12.11.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 12:11:10 -0800 (PST) From: Ralph Droms Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_93153936-70B6-41B7-8BED-3882D95414BC" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 30 Jan 2017 15:11:06 -0500 In-Reply-To: <04633FA3-6478-493D-8AED-987547C37AAF@fugue.com> To: Ted Lemon References: <04633FA3-6478-493D-8AED-987547C37AAF@fugue.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: HOMENET Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:11:14 -0000 --Apple-Mail=_93153936-70B6-41B7-8BED-3882D95414BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 30, 2017, at 3:04 PM, Ted Lemon wrote: >=20 > On Jan 30, 2017, at 1:26 PM, Ralph Droms > wrote: >> Name resolution APIs and libraries MUST NOT recognize names that end = in '.homenet.' as special and MUST NOT treat them differently. Name = resolution APIs will only resolve such a name correctly if the query is = sent to a recursive DNS server configured to be authoritative for the = .homenet zone appropriate to the home network. This RDNSS or list of = RDNSSes will usually be supplied to the client through a local = configuration mechanism like HNCP or DHCP. If a host is configured to = use a resolver other than one that is authoritative for the appropriate = .homenet zone, the client may be unable to resolve or receive incorrect = results for names in sub domains of ".homenet". >=20 > How about this: >=20 >> Name resolution APIs and libraries MUST NOT recognize names that end = in '.homenet.' as special and MUST NOT treat them differently. Name = resolution APIs MUST send queries for such names to a recursive DNS = server that is configured to be authoritative for the .homenet zone = appropriate to the home network. One or more IP addresses for recursive = DNS servers will usually be supplied to the client through router = advertisements or DHCP. If a host is configured to use a resolver other = than one that is authoritative for the appropriate .homenet zone, the = client may be unable to resolve, or may receive incorrect results for, = names in sub domains of ".homenet".=20 >=20 > I don't like RDNSS, so I expanded the acronym; I don't think that we = should mention HNCP here as a host configuration protocol. I also = cleaned up the last sentence a bit. Fine with me...=20 - Ralph --Apple-Mail=_93153936-70B6-41B7-8BED-3882D95414BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 30, 2017, at 3:04 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Jan 30, = 2017, at 1:26 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
Name resolution APIs and libraries = MUST NOT recognize names that end in '.homenet.' as special and MUST NOT = treat them differently.  Name resolution APIs will only resolve such a name correctly = if the query is sent to a recursive DNS server configured to = be authoritative for the .homenet zone appropriate to the home = network.  This RDNSS or list of RDNSSes will usually be supplied to = the client through a local configuration mechanism like HNCP or = DHCP.  If a host is configured to use a resolver other than one = that is authoritative for the appropriate .homenet zone, the client may = be unable to resolve or receive incorrect results for names in sub = domains of ".homenet".

How about this:

Name resolution APIs and = libraries MUST NOT recognize names that end in '.homenet.' as special = and MUST NOT treat them differently. Name resolution APIs MUST send = queries for such names to a recursive DNS server that is configured to = be authoritative for the .homenet zone appropriate to the home network. =  One or more IP addresses for recursive DNS servers will usually be = supplied to the client through router advertisements or DHCP.  If a = host is configured to use a resolver other than one that is = authoritative for the appropriate .homenet zone, the client may be = unable to resolve, or may receive incorrect results for, names in sub = domains of ".homenet". 

I don't like RDNSS, so I expanded the acronym; I don't think = that we should mention HNCP here as a host configuration protocol. =   I also cleaned up the last sentence a = bit.

Fine with = me... 

- Ralph


= --Apple-Mail=_93153936-70B6-41B7-8BED-3882D95414BC-- From nobody Mon Jan 30 12:13:14 2017 Return-Path: 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 840E2129B7E for ; Mon, 30 Jan 2017 12:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 p2pDzYotXXyc for ; Mon, 30 Jan 2017 12:13:11 -0800 (PST) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09BC129AA5 for ; Mon, 30 Jan 2017 12:13:10 -0800 (PST) Received: from [46.227.151.81] (port=62842 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1cYIK2-0002GZ-Cw (Exim 4.72) for homenet@ietf.org (return-path ); Mon, 30 Jan 2017 20:13:06 +0000 To: homenet@ietf.org References: <04633FA3-6478-493D-8AED-987547C37AAF@fugue.com> From: Ray Bellis Message-ID: <6c74938e-bacd-9c59-1436-1d550da6cc3f@bellis.me.uk> Date: Mon, 30 Jan 2017 20:13:09 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:13:12 -0000 On 30/01/2017 20:11, Ralph Droms wrote: > Fine with me... Ralph - thanks for checking through Ted's edits. Mark and I shall be going through the documents ourselves this week before we advance them to the IESG. If any other people that made comments during WGLC would please also double check that their issues have been addressed that would be much appreciated. thanks, Ray From nobody Mon Jan 30 12:20:34 2017 Return-Path: X-Original-To: homenet@ietf.org Delivered-To: homenet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B55C0129A47; Mon, 30 Jan 2017 12:20:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148580763273.29936.7426275687617600086.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 12:20:32 -0800 Archived-At: Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-dot-02.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:20:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Home Networking of the IETF. Title : Special Use Top Level Domain '.homenet' Authors : Pierre Pfister Ted Lemon Filename : draft-ietf-homenet-dot-02.txt Pages : 7 Date : 2017-01-30 Abstract: This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.homenet.', and designates this top-level domain as a special-use domain name. The '.homenet' top-level domain replaces '.home' as the default domain used by the Home Networking Control Protocol (HNCP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-dot/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-homenet-dot-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-dot-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 30 12:22:02 2017 Return-Path: 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 0FD48129BAF for ; Mon, 30 Jan 2017 12:22:01 -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 TgNc9AABZBZs for ; Mon, 30 Jan 2017 12:22:00 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 52612129BB0 for ; Mon, 30 Jan 2017 12:21:58 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v23so215092237qtb.0 for ; Mon, 30 Jan 2017 12:21:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=X5uHcF4emTeHehkHdLK7/hSNHWgy7/2EP6MNZz5WoaI=; b=f1KFLarKdLfbKxUk7dg78OUGm/xi4qcup0eT6NfEtUqT81vzNPjJUIPPsWaGVbQx3P H8JKNUANucf0SazY+q1hSThGQCeAYtQLkg9daqBAxZ58Csz6AkgR2B/MuKLZMuzD/kwD RGnbpco40HSFRtMLFYoA1f8abBXT4RUFn1WwCzF++KrdPo9TDo6xYHv8j54sWjrk/geB SKbn7BvGJ6+cZ2fAp03QWCMifrNwY46i8FgWB/aPPoRx86ylogEp+M/MZ644UdiuzK4i ecLsIFrZwNP7Lla/HuXhcLcI/d7fCM70wUWnJHu+3VYnbqTb6YzMp+irYvMF3gIDperO VoDQ== 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=X5uHcF4emTeHehkHdLK7/hSNHWgy7/2EP6MNZz5WoaI=; b=oDPhTM0adns2PdQNyABaaIqR3MMxjLuxAWEvUw0ik8oWqY0aILx/5+QUzy2SqQ+xYf PTIV84akylR8TrsgVJrEZfyz7iGFCuEitcYQESfgg2sqMeqvOkVVE3RP5o/sP1sJX7z2 gBQuheWGcln8vcY5YZQN0vRldhIE3VZOJAE0TTrLsxkcOY+2PAKxJZP8b5W8AFHUFbCk bFSnnkDXP0SLgY9L83zkfqixUPCJqr2I2PCSut1peln23S6IT+uz7t8tkr/Mg/iFTi24 YNGYWFp2pZk43mcwtDyW3+4MGJdVcctjhLpdFvftdisQ/9doSG9VYwtWSSrxEJdLF4b7 E3qg== X-Gm-Message-State: AIkVDXKqlFphoBkbY2p567ms5srY/6Gzpv4+xq10MmhUL+6+KY+UPPVh71tUXk2wFrs22w== X-Received: by 10.200.56.4 with SMTP id q4mr23753317qtb.73.1485807717440; Mon, 30 Jan 2017 12:21:57 -0800 (PST) Received: from [10.70.104.179] ([64.94.31.206]) by smtp.gmail.com with ESMTPSA id i187sm13180643qkd.20.2017.01.30.12.21.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 12:21:56 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ted Lemon In-Reply-To: <6c74938e-bacd-9c59-1436-1d550da6cc3f@bellis.me.uk> Date: Mon, 30 Jan 2017 15:21:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6ADB0374-6D9D-4CE6-863A-08871368C468@fugue.com> References: <04633FA3-6478-493D-8AED-987547C37AAF@fugue.com> <6c74938e-bacd-9c59-1436-1d550da6cc3f@bellis.me.uk> To: Ray Bellis X-Mailer: Apple Mail (2.3259) Archived-At: Cc: homenet@ietf.org Subject: Re: [homenet] Last call updates to draft-ietf-homenet-dothome and draft-ietf-homenet-redact X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 20:22:01 -0000 Thanks, Ray! I've uploaded a new version of the document, so if = someone is moved to do another review now, they may want to start from = there. From nobody Mon Jan 30 18:24:01 2017 Return-Path: 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 D8E9F129C25; Mon, 30 Jan 2017 18:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RvRYqrHsIUgN; Mon, 30 Jan 2017 18:23:53 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D95F129A30; Mon, 30 Jan 2017 18:23:53 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 71E46B81E9C; Mon, 30 Jan 2017 18:23:53 -0800 (PST) To: rdroms.ietf@gmail.com, markus.stenberg@iki.fi, cyrus@openwrt.org, pierre.pfister@darou.fr X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20170131022353.71E46B81E9C@rfc-editor.org> Date: Mon, 30 Jan 2017 18:23:53 -0800 (PST) Archived-At: Cc: text/plain@rfc-editor.org, charset=UTF-8@rfc-editor.org, rfc-editor@rfc-editor.orgContent-Type, iesg@ietf.org, homenet@ietf.org, terry.manderson@icann.org Subject: [homenet] [Errata Held for Document Update] RFC7788 (4718) X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: IETF Homenet WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 02:23:55 -0000 The following errata report has been held for document update for RFC7788, "Home Networking Control Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4718 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Ralph Droms Date Reported: 2016-06-23 Held by: Terry Manderson (IESG) Section: GLOBAL Original Text ------------- 7.4. Multicast DNS Proxy The designated Multicast DNS (mDNS) [RFC6762] proxy on a Common Link is elected based on the capabilities described in Section 4. [...] The elected router MUST provide an mDNS proxy on the given link and announce it as described in Section 8. [...] 8. Naming and Service Discovery [...] Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Common Link (Section 6.1) for which it is the designated DHCPv4, stateful DHCPv6 server, mDNS proxy, or for which it provides forward or reverse DNS services on behalf of connected devices. [...] 10.1. HNCP-Version TLV [...] M-capability: Priority value used for electing the on-link mDNS [RFC6762] proxy. It MUST be set to 0 if the router is not capable of proxying mDNS, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority Corrected Text -------------- 7.4. Multicast DNS Hybrid Proxy The designated Multicast DNS (mDNS) [RFC6762] Hybrid Proxy [draft-ietf-dnssd-hybrid-03] on a Common Link is elected based on the capabilities described in Section 4. [...] The elected router MUST provide an mDNS Hybrid Proxy on the given link and announce it as described in Section 8. [...] 8. Naming and Service Discovery [...] Each HNCP router SHOULD provide and announce an auto-generated or user-configured name for each internal Common Link (Section 6.1) for which it is the designated DHCPv4, stateful DHCPv6 server, mDNS Hybrid Proxy, or for which it provides forward or reverse DNS services on behalf of connected devices. [...] 10.1. HNCP-Version TLV [...] M-capability: Priority value used for electing the on-link mDNS Hybrid Proxy. It MUST be set to 0 if the router is not capable of providing an mDNS Hybrid Proxy service, otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to 7 to indicate a non-default priority Notes ----- RFC 7788 refers to "Multicast DNS (mDNS) proxy" and gives a citation for RFC 6762. RFC 6762, "Multicast DNS," defines multicast DNS and mentions (without an explicit definition) a "Multicast DNS Proxy" service. This proxy service is also known as "Bonjour Sleep Proxy" [https://en.wikipedia.org/wiki/Bonjour_Sleep_Proxy] However, the intent of RFC 7788 is to specify the operation and advertisement of the multicast DNS Hybrid Proxy Service, as defined in draft-ietf-dnssd-hybrid-03, "Hybrid Unicast/Multicast DNS-Based Service Discovery." This errata corrects the mentions of "mDNS proxy" in RFC 7788 to "Hybrid Proxy." draft-ietf-dnssd-hybrid-03 should also be added to the Normative References. -------------------------------------- RFC7788 (draft-ietf-homenet-hncp-10) -------------------------------------- Title : Home Networking Control Protocol Publication Date : April 2016 Author(s) : M. Stenberg, S. Barth, P. Pfister Category : PROPOSED STANDARD Source : Home Networking Area : Internet Stream : IETF Verifying Party : IESG