From ywang@cnnic.cn Thu Jun 28 05:46:08 2012 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 6FFB421F852E for ; Thu, 28 Jun 2012 05:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlVtnBKGmbZc for ; Thu, 28 Jun 2012 05:46:08 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 5ACF921F84D6 for ; Thu, 28 Jun 2012 05:46:03 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: ywang@cnnic.cn Received: from unknown127.0.0.1 (HELO cnnicpc) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 28 Jun 2012 16:13:17 +0800 From: "Yan Wang" To: References: <4FA6D1AD.1050004@mtcc.com> <0e8401cd2bce$96e52770$c4af7650$@com> <4FA8057C.4080906@mtcc.com> <018301cd2c80$cd8405f0$688c11d0$@com> <08545291-3F56-4403-9B07-793E30755A63@apple.com> <9D946452-FB18-4D8E-B5DE-2A2F098670C5@nominet.org.uk> <4FAACD7B.9070607@mtcc.com> <24673342-0E01-44E7-AB84-990192CD7879@nominet.org.uk> In-Reply-To: <24673342-0E01-44E7-AB84-990192CD7879@nominet.org.uk> Date: Thu, 28 Jun 2012 16:13:18 +0800 Message-ID: <00b001cd5505$e024adb0$a06e0910$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNLHZmV0Hh6uNFwU28Vt5NK9tzvZa+l+mAgAGOYwCAANjbgIAA1KiAgAAC4ACATdtpcA== Content-Language: zh-cn Subject: [homenet] any plan? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 12:46:08 -0000 Hi all=A3=AC The maillist seems too quiet recently. Is there any plan for homenet in IETF84? Best wishes, Yan From tjc@ecs.soton.ac.uk Thu Jun 28 06:07:41 2012 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 8AAD021F8445 for ; Thu, 28 Jun 2012 06:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+ilGGy5jNXQ for ; Thu, 28 Jun 2012 06:07:41 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id CEFB621F843F for ; Thu, 28 Jun 2012 06:07:39 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q5SD7SbQ002913; Thu, 28 Jun 2012 14:07:28 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q5SD7SbQ002913 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1340888848; bh=nXzxpLO4UvhEhBHaNHtdhaNzgKI=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=tntvApOnCLYD8OdbxQVMyXIye4ov98ey+jHsUobCEa1CWEgT7yxHh/vSV2hawncYG NekDnnt3nZ/i7DxE20gJ9tGa5plB51y62Nc3HaE5Ib1tyETWF8zwkmMkHTFea1Rlck qZcI4h4kF4RPEvcCapBGHte5VivF0merZk9EWn6s= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP id o5RE7R0544153619yk ret-id none; Thu, 28 Jun 2012 14:07:28 +0100 Received: from [152.78.206.22] (ip-206-022.eduroam.soton.ac.uk [152.78.206.22]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q5SD7QK4014985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 14:07:26 +0100 References: <4FA6D1AD.1050004@mtcc.com> <0e8401cd2bce$96e52770$c4af7650$@com> <4FA8057C.4080906@mtcc.com> <018301cd2c80$cd8405f0$688c11d0$@com> <08545291-3F56-4403-9B07-793E30755A63@apple.com> <9D946452-FB18-4D8E-B5DE-2A2F098670C5@nominet.org.uk> <4FAACD7B.9070607@mtcc.com> <24673342-0E01-44E7-AB84-990192CD7879@nominet.org.uk> <00b001cd5505$e024adb0$a06e0910$@cn> In-Reply-To: <00b001cd5505$e024adb0$a06e0910$@cn> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-ID: X-Mailer: iPad Mail (9B206) From: Tim Chown Date: Thu, 28 Jun 2012 14:10:22 +0100 To: Yan Wang X-smtpf-Report: sid=o5RE7R054415361900; tid=o5RE7R0544153619yk; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q5SD7SbQ002913 X-ECS-MailScanner: Found to be clean X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "" Subject: Re: [homenet] any plan? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 13:07:41 -0000 Hi, A timely question. The -03 architecture draft will be out today or tomorrow. Some expert comment on naming and service discovery areas has been solicited= . I believe a session is booked. Tim On 28 Jun 2012, at 09:13, "Yan Wang" wrote: > Hi all=EF=BC=8C >=20 > The maillist seems too quiet recently. Is there any plan for homenet in > IETF84? >=20 >=20 >=20 >=20 > Best wishes, > Yan >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From Ray.Bellis@nominet.org.uk Thu Jun 28 07:04:10 2012 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 F16A421F852C for ; Thu, 28 Jun 2012 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjGh2fmdncUe for ; Thu, 28 Jun 2012 07:04:09 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD2621F8518 for ; Thu, 28 Jun 2012 07:04:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=4FcLkCOo0lX6K1HA9mpTNQ9Bid0GkYFqWGJ3ygyeTRONjZgmASE3BGRV Rs279zgUR76KdPTyQwPscSc2fvckCHDcolLXqL6ff0ucqUJkBfUtMf9Ca ++596psXTo5uH/b; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1340892249; x=1372428249; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[homenet]=20any=20plan?|Date:=20Thu,=20 28=20Jun=202012=2014:04:05=20+0000|Message-ID:=20<0DFEE46 2-5A2F-4575-8D27-EBEBA0C6B978@nominet.org.uk>|To:=20"home net@ietf.org=20Group"=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20<807e61a5-e024-4379-a384-dd72c49a4c1b> |In-Reply-To:=20|References:=20<4FA6D1AD.1050 004@mtcc.com>=0D=0A=20<0e8401cd2bce$96e52770$c4af7650$@co m>=20<4FA8057C.4080906@mtcc.com>=0D=0A=20<018301cd2c80$cd 8405f0$688c11d0$@com>=0D=0A=20<08545291-3F56-4403-9B07-79 3E30755A63@apple.com>=0D=0A=20<9D946452-FB18-4D8E-B5DE-2A 2F098670C5@nominet.org.uk>=0D=0A=20<4FAACD7B.9070607@mtcc .com>=0D=0A=20<24673342-0E01-44E7-AB84-990192CD7879@nomin et.org.uk>=0D=0A=20<00b001cd5505$e024adb0$a06e0910$@cn> =0D=0A=20=0D=0A=20; bh=PKgasp/NqO8ueKGxKFC1LXiDMDoMrz/efV2XuMpmncM=; b=Bh8PVIX7yEIHSBzQa6v5y7EVR6e6Mwaq7dKq7q/FZFCuZZfr+5tYG0QK juo+ialIGtZOHqaAiOIVoHxkycQWfml9PyU4z4bR8HI2mV3+inS0ccVr0 b/+ykY//D4/S0eJ; X-IronPort-AV: E=Sophos;i="4.77,492,1336345200"; d="scan'208";a="33847463" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 28 Jun 2012 15:04:07 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%19]) with mapi; Thu, 28 Jun 2012 15:04:07 +0100 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: [homenet] any plan? Thread-Index: AQHNVS8F8PjDtHkguk2w+yfB96hrcZcPsp+A Date: Thu, 28 Jun 2012 14:04:05 +0000 Message-ID: <0DFEE462-5A2F-4575-8D27-EBEBA0C6B978@nominet.org.uk> References: <4FA6D1AD.1050004@mtcc.com> <0e8401cd2bce$96e52770$c4af7650$@com> <4FA8057C.4080906@mtcc.com> <018301cd2c80$cd8405f0$688c11d0$@com> <08545291-3F56-4403-9B07-793E30755A63@apple.com> <9D946452-FB18-4D8E-B5DE-2A2F098670C5@nominet.org.uk> <4FAACD7B.9070607@mtcc.com> <24673342-0E01-44E7-AB84-990192CD7879@nominet.org.uk> <00b001cd5505$e024adb0$a06e0910$@cn> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <807e61a5-e024-4379-a384-dd72c49a4c1b> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [homenet] any plan? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 14:04:10 -0000 On 28 Jun 2012, at 14:10, Tim Chown wrote: > Some expert comment on naming and service discovery areas has been solici= ted. and I'm promised should be arriving imminently... > I believe a session is booked. Yes, a session has been booked. Mark and I will be sorting out the agenda shortly, but expect the bulk of t= he session to concentrate on the Architecture Draft again. The main focus will probably be on the Naming and Service Discovery, and Se= curity areas. We're also expecting to have a contribution on border discovery. Ray From dave.taht@gmail.com Thu Jun 28 09:27:54 2012 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 953E321F8523 for ; Thu, 28 Jun 2012 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwoVeo4zSxQd for ; Thu, 28 Jun 2012 09:27:53 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3017E21F84FB for ; Thu, 28 Jun 2012 09:27:53 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so1613961wgb.13 for ; Thu, 28 Jun 2012 09:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=XDt8LK7Sw+XOZlCTrJrzJLFRuOU0OlW1K1zzSF1vBdA=; b=Gdhjstt3lKGf3pPHnb/YNGeHNuPdYEUMHC2nsLnd/FsO9/xjTkqUVhIXw/sqz03NlR 0g1/6W8aT21FR0AVcAjTYrJcxHO5u8c77DEw0LT25YIEssecTRsBBVtHu3RwuTD1wg+K t/JIoKNyeZfN93bB/19v6hN76055lfkrR2aZNYuQvN8G4SHejBifUeoY4gG0yRAQCcjs ge14kD5qovnK6bZKyiLGTuPgZvs1BYhu53ZT6YQCet2YffLX5mnavXZmSd3BjOZXkvgX Az935ThNmBDH+/XrthPLuiX/BIFRZPcuYmgMRWGTQ8rGzHM+ZHoOJ1WuHvMuOziTpJDN ISOg== MIME-Version: 1.0 Received: by 10.180.94.4 with SMTP id cy4mr1191880wib.2.1340900871483; Thu, 28 Jun 2012 09:27:51 -0700 (PDT) Received: by 10.223.103.199 with HTTP; Thu, 28 Jun 2012 09:27:51 -0700 (PDT) In-Reply-To: <0DFEE462-5A2F-4575-8D27-EBEBA0C6B978@nominet.org.uk> References: <4FA6D1AD.1050004@mtcc.com> <0e8401cd2bce$96e52770$c4af7650$@com> <4FA8057C.4080906@mtcc.com> <018301cd2c80$cd8405f0$688c11d0$@com> <08545291-3F56-4403-9B07-793E30755A63@apple.com> <9D946452-FB18-4D8E-B5DE-2A2F098670C5@nominet.org.uk> <4FAACD7B.9070607@mtcc.com> <24673342-0E01-44E7-AB84-990192CD7879@nominet.org.uk> <00b001cd5505$e024adb0$a06e0910$@cn> <0DFEE462-5A2F-4575-8D27-EBEBA0C6B978@nominet.org.uk> Date: Thu, 28 Jun 2012 12:27:51 -0400 Message-ID: From: Dave Taht To: Ray Bellis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "homenet@ietf.org Group" Subject: Re: [homenet] any plan? X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:27:54 -0000 In terms of "running code", I have a few updates for homenet. 1) Codel and FQ_codel in openwrt/cerowrt mainline and upcoming linux 3.5 Van Jacobson and Kathie Nichols new RED replacement, "Codel" is out and showing great results. (in the fq_codel variant especially). Their paper, "controlling queue delay", the ns2, ns3 sims, and code are linked to at: http://www.bufferbloat.net/projects/codel/wiki Cerowrt has it as it's default qdisc, openwrt has it in their qos subsystem only (as yet) Codel is dual BSD/GPL licensed to give more folk a leg up on it. (fq_codel is GPL, but multiple other technologies for fair queuing exist) Reducing latency and fixing bufferbloat on homenet devices, for ethernet, seems feasible now, although much work remains at multiple layers of the stack (and wifi needs major work especially) We are trying to have some data in time for ietf but I suppose most of that is of interest to other working groups. 2) jg recently outlined a plan for better aqm and classification for everything (which applies especially to home gateways) https://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-= to-fix-it/ I've spent part of the last year pushing better classification into multiple daemons (quagga/dnsmasq/rsync/etc), have patches for transmission in my queue - in addition to fixing bufferbloat, etc, but the above link is the first top level overview of that low-level-incremental thing we've been doing that has existed and could use some more brain cells on it. recently we had a debate on classifying DNS queries as CS5 2) On the routing/security front, the first ever (so far as I know) implementation of secure RIP and babel has landed in quagga-RE, implementing RFC4822 (and borrowing some stuff from RFC6506). To me, this is a huge advance on the state of the art, making possible ip level security in a routed network. code: https://github.com/Quagga-RE/ Support for hsls, olsr and batman is also migrating into quagga: http://lists.quagga.net/pipermail/quagga-dev/2012-June/009438.html My overall goal for the quagga work is to be able to align with the competing ospf ideas here on homenet using the same daemon infrastructure and may the best protocol win. 3) Border detection, have quite a few thoughts, look forward to reading the draft 4) I have made no progress on naming. Experiments with routed multicast DNS were less than satisfactory across multiple domains. getting bind to work well requires nsupdate integration with everything. And lastly, Cerowrt-3.3.8-6 is out, testing tons of new ideas, and proving pretty stable, with -7 adding in the new quagga this weekend. --=20 Dave T=E4ht Blatant Plug: http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!" From internet-drafts@ietf.org Fri Jun 29 07:39:33 2012 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 6CFC221F8714; Fri, 29 Jun 2012 07:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5rmDwKj73n0; Fri, 29 Jun 2012 07:39:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9206121F867D; Fri, 29 Jun 2012 07:39:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120629143909.14631.77927.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2012 07:39:09 -0700 Cc: homenet@ietf.org Subject: [homenet] I-D Action: draft-ietf-homenet-arch-03.txt X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 14:39:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Home Networking Working Group of the IETF. Title : Home Networking Architecture for IPv6 Author(s) : Tim Chown Jari Arkko Anders Brandt Ole Troan Jason Weil Filename : draft-ietf-homenet-arch-03.txt Pages : 37 Date : 2012-06-29 Abstract: This text describes evolving networking technology within increasingly large residential home networks. The goal of this document is to define the architecture for IPv6-based home networking through the associated principles, considerations and requirements. The text briefly highlights the implications of the introduction of IPv6 for home networking, discusses topology scenarios, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed, and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-homenet-arch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-homenet-arch-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ogud@ogud.com Fri Jun 29 08:06:23 2012 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 515A021F8697 for ; Fri, 29 Jun 2012 08:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXWFf8uHKr5S for ; Fri, 29 Jun 2012 08:06:22 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 59D8E21F870B for ; Fri, 29 Jun 2012 08:06:22 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q5TF6Lo8025695 for ; Fri, 29 Jun 2012 11:06:21 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FEDC46C.8070205@ogud.com> Date: Fri, 29 Jun 2012 11:06:20 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: homenet@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Subject: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:06:23 -0000 After the Homenet meeting in Paris I realized that the group needs good principles for its name-space work. The principles in -arch-02 are a good start but IMHO not sufficient. It makes not sense to be proposing/evaluating solutions when there are no agreed upon principles/requirements. The chairs have been bugging me to follow up with a contribution. Below is my attempt at defining as compactly/broadly as possible design principles for Name services: a) Homenet name-service MUST NOT interfere with Internet name-service b) Homenet name-service MUST NOT be in Internet name space. e) Homenet name-service MUST function throughout the whole "site" c) Homenet name-service SHOULD support both lookups and discovery d) Homenet name-service SHOULD be considerate of bandwidth usage e) Homenet name-service MUST allow segmentation of "name space" for different classes/groups/cliques of applications/devices g) Homenet name-service SHOULD allow both broadcast service as well as more traditional lookup service. I'm expecting a lively discussion on this topic :-) Olafur From rdroms.ietf@gmail.com Fri Jun 29 08:34:29 2012 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 8192A21F8783 for ; Fri, 29 Jun 2012 08:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymRu-RHzODDX for ; Fri, 29 Jun 2012 08:34:27 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC521F8778 for ; Fri, 29 Jun 2012 08:34:27 -0700 (PDT) Received: by qcac10 with SMTP id c10so880176qca.31 for ; Fri, 29 Jun 2012 08:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=58OupjAoW+aSo5R3ekPEoFmwvITaos77jdkUxbxlq+o=; b=0jTTGhBZgpLphVmh23JQEFtVtKeKGwgni8sXei1uoS3nzLqRAihjfqL30tg3wY6XsK /M/WJ+OnEkb0Jv3vzHaQi2fNLysnHMROQFWFnLlAWLZwQvi4/AR20U3qi6C+TOrNYgv0 Asf16e4pXWc+83SpCSDnK7eWgsyAeKil0WzM6O+x5A2PzktF0Z1vutBlZMWt0yh0SneM 6ibBlsN/YsVfVBAe+2zoz4iBbrRbse4qWyxqxkCL0ImE5xbNqsRXPuFQFbdnp9o/tiwV mSNoaqYW3bEaV0Dqw0ea6COMsmRceSD+8t3nyFwBrKj6Kq28JUEa+AfqOaX7dOzLIv/i AbpQ== Received: by 10.229.105.141 with SMTP id t13mr956738qco.118.1340984066967; Fri, 29 Jun 2012 08:34:26 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id u4sm10898874qaa.1.2012.06.29.08.34.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 08:34:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4FEDC46C.8070205@ogud.com> Date: Fri, 29 Jun 2012 11:34:22 -0400 Content-Transfer-Encoding: 7bit Message-Id: <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> References: <4FEDC46C.8070205@ogud.com> To: Olafur Gudmundsson X-Mailer: Apple Mail (2.1278) Cc: homenet@ietf.org, Ralph Droms Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:34:29 -0000 So, let's compare this with what I talked about during the Paris WG meeting: * Disconnected operation ("fate sharing"): name resolution for reachable devices continues if the local network is disconnected from the global Internet * Relative name resolution: some naming convention that allows name resolution while mitigating the need to know an absolute location in the global DNS namespace * Representation in the global DNS namespace, for access from off-net * Unmanaged operation * Efficient message utilization: for example, keep unwanted traffic off of an IEEE802.15.4 network Merging those points with comments in-line... On Jun 29, 2012, at 11:06 AM 6/29/12, Olafur Gudmundsson wrote: > After the Homenet meeting in Paris I realized that the group needs > good principles for its name-space work. The principles in -arch-02 are > a good start but IMHO not sufficient. > It makes not sense to be proposing/evaluating solutions when there > are no agreed upon principles/requirements. > > The chairs have been bugging me to follow up with a contribution. > Below is my attempt at defining as compactly/broadly as > possible design principles for Name services: > > a) Homenet name-service MUST NOT interfere with Internet name-service "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a better word. Users want a single interface into naming and don't want to have to differentiate between "naming stuff on my local network" and "naming stuff in the Internet". Ted Lemon raised this issue much more eloquently during the WG meeting. I'll add my first bullet here, rephrased a little: a.1) Relative name resolution: some naming convention that allows name resolution while mitigating the need to know an absolute location in the Internet name-service > b) Homenet name-service MUST NOT be in Internet name space. How are things in the home identified from outside the homenet? > e) Homenet name-service MUST function throughout the whole "site" > > c) Homenet name-service SHOULD support both lookups and discovery What do you mean by "lookups and discovery"? Are they different forms of name resolution? > d) Homenet name-service SHOULD be considerate of bandwidth usage > > e) Homenet name-service MUST allow segmentation of "name space" for > different classes/groups/cliques of applications/devices What requirements is this segmentation intended to satisfy? > g) Homenet name-service SHOULD allow both broadcast service as well as > more traditional lookup service. Seems like an implementation detail to support a higher level requirement like "must not require a centralized registration/resolution service". Two operational points from my list: h) Disconnected operation ("fate sharing"): name resolution for reachable devices continues if the local network is disconnected from the global Internet i) Unmanaged operation > > I'm expecting a lively discussion on this topic :-) OK, I've contributed to the discussion. - Ralph > > Olafur > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From bkerensa@gmail.com Fri Jun 29 10:49:17 2012 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 447C821F8723 for ; Fri, 29 Jun 2012 10:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-GcUiV5sbQW for ; Fri, 29 Jun 2012 10:49:16 -0700 (PDT) Received: from mail-yw0-f42.google.com (mail-yw0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDA921F85AD for ; Fri, 29 Jun 2012 10:49:16 -0700 (PDT) Received: by yhfq11 with SMTP id q11so3619305yhf.15 for ; Fri, 29 Jun 2012 10:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=geTu/dP85wUdO3Z3/Brf/g5+4BygTHzPbKBXXuQ/AXM=; b=ea2b5BR5Y0bRdWhVDuLKF56ha1dT0/wkDpL8KmixlH+qEJx1Qt9/kmfydJdDkYCupH Q6Jm2ydjfC/MuXkltmZDolotNlAjsSQrZLgLe4F9Hcd2JgvaRxGkrb0+0ervaboUX9PB stQwQFpameC0lNkrIQlIZxQJkljftzwc2Y+fCPOINCWq2uA4G4RX0jHkTI1dt2QmFZ37 6PFuNp5ZlRWyvNhWtvJomXXaZKjgLY6ZG5H/2RB+GqhltKu55BYDoGs/j0DTYK0wyVBJ 3my8goGZXMNrjIwrHLBWKlQLZSc17K0wSE1imSwhlPWl5MhmEufQzKO/OtdPw93r+l8q 9D9w== Received: by 10.50.89.198 with SMTP id bq6mr1871616igb.28.1340992155706; Fri, 29 Jun 2012 10:49:15 -0700 (PDT) MIME-Version: 1.0 Sender: bkerensa@gmail.com Received: by 10.64.82.6 with HTTP; Fri, 29 Jun 2012 10:48:35 -0700 (PDT) In-Reply-To: <4FEDC46C.8070205@ogud.com> References: <4FEDC46C.8070205@ogud.com> From: Benjamin Kerensa Date: Fri, 29 Jun 2012 10:48:35 -0700 X-Google-Sender-Auth: nsU-KVekZAi6SSgObuNJKoCtBhs Message-ID: To: Olafur Gudmundsson Content-Type: multipart/alternative; boundary=e89a8f2359bd16646c04c3a011f9 Cc: homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:56:20 -0000 --e89a8f2359bd16646c04c3a011f9 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 8:06 AM, Olafur Gudmundsson wrote: > After the Homenet meeting in Paris I realized that the group needs > good principles for its name-space work. The principles in -arch-02 are > a good start but IMHO not sufficient. > It makes not sense to be proposing/evaluating solutions when there > are no agreed upon principles/requirements. > > The chairs have been bugging me to follow up with a contribution. > Below is my attempt at defining as compactly/broadly as > possible design principles for Name services: > > a) Homenet name-service MUST NOT interfere with Internet name-service > > b) Homenet name-service MUST NOT be in Internet name space. > > e) Homenet name-service MUST function throughout the whole "site" > > c) Homenet name-service SHOULD support both lookups and discovery > > d) Homenet name-service SHOULD be considerate of bandwidth usage > > e) Homenet name-service MUST allow segmentation of "name space" for > different classes/groups/cliques of applications/devices > > g) Homenet name-service SHOULD allow both broadcast service as well as > more traditional lookup service. > > I'm expecting a lively discussion on this topic :-) > > Olafur > ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > I think the above design principles seem pretty precise and common sense I guess my only question is in the case of segmentation of "name space" for various classes is there going to be limitations to the segmentation or policies surrounding cases where segmentation occurs in the "name space". --e89a8f2359bd16646c04c3a011f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jun 29, 2012 at 8:06 AM, Olafur = Gudmundsson <ogud@ogud.com> wrote:
After the Homenet meeting in Paris I realized that the group needs
good principles for its name-space work. The principles in -arch-02 are
a good start but IMHO not sufficient.
It makes not sense to be proposing/evaluating solutions when there
are no agreed upon principles/requirements.

The chairs have been bugging me to follow up with a contribution.
Below is my attempt at defining as compactly/broadly as
possible design principles for Name services:

a) Homenet name-service MUST NOT interfere with Internet name-service

b) Homenet name-service MUST NOT be in Internet name space.

e) Homenet name-service MUST function throughout the whole "site"=

c) Homenet name-service SHOULD support both lookups and discovery

d) Homenet name-service SHOULD be considerate of bandwidth usage

e) Homenet name-service MUST allow segmentation of "name space" f= or
different classes/groups/cliques of applications/devices

g) Homenet name-service SHOULD allow both broadcast service as well as
=A0 more traditional lookup service.

I'm expecting a lively discussion on this topic :-)

=A0 =A0Olafur
_______________________________________________
homenet mailing list
homenet@ietf.org<= br> https://www.ietf.org/mailman/listinfo/homenet


I think the above design prin= ciples seem pretty precise and common sense=A0
I guess my only qu= estion is in the case of segmentation of "name space" for various= classes is there going to be limitations to the segmentation or policies s= urrounding cases where segmentation occurs in the "name space". --e89a8f2359bd16646c04c3a011f9-- From ogud@ogud.com Fri Jun 29 11:19:42 2012 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 6620921F8821 for ; Fri, 29 Jun 2012 11:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpd06Z61V-uz for ; Fri, 29 Jun 2012 11:19:41 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7C221F8859 for ; Fri, 29 Jun 2012 11:19:41 -0700 (PDT) Received: from [IPv6:::1] (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id q5TIJZ2K027140; Fri, 29 Jun 2012 14:19:36 -0400 (EDT) (envelope-from ogud@ogud.com) Message-ID: <4FEDF1B6.30401@ogud.com> Date: Fri, 29 Jun 2012 14:19:34 -0400 From: Olafur Gudmundsson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ralph Droms References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> In-Reply-To: <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4 Cc: homenet@ietf.org Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 18:19:42 -0000 On 29/06/2012 11:34, Ralph Droms wrote: > So, let's compare this with what I talked about during the Paris WG meeting: > > * Disconnected operation ("fate sharing"): name resolution for reachable > devices continues if the local network is disconnected from the global > Internet > > * Relative name resolution: some naming convention that allows name > resolution while mitigating the need to know an absolute location in the > global DNS namespace > > * Representation in the global DNS namespace, for access from off-net > > * Unmanaged operation > > * Efficient message utilization: for example, keep unwanted traffic > off of an IEEE802.15.4 network > > Merging those points with comments in-line... > > > On Jun 29, 2012, at 11:06 AM 6/29/12, Olafur Gudmundsson wrote: > >> After the Homenet meeting in Paris I realized that the group needs >> good principles for its name-space work. The principles in -arch-02 are >> a good start but IMHO not sufficient. >> It makes not sense to be proposing/evaluating solutions when there >> are no agreed upon principles/requirements. >> >> The chairs have been bugging me to follow up with a contribution. >> Below is my attempt at defining as compactly/broadly as >> possible design principles for Name services: >> >> a) Homenet name-service MUST NOT interfere with Internet name-service > > "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a > better word. Users want a single interface into naming and don't > want to have to differentiate between "naming stuff on my local network" > and "naming stuff in the Internet". Ted Lemon raised this issue much > more eloquently during the WG meeting. > > I'll add my first bullet here, rephrased a little: > > a.1) Relative name resolution: some naming convention that allows name > resolution while mitigating the need to know an absolute location in the > Internet name-service > >> b) Homenet name-service MUST NOT be in Internet name space. > > How are things in the home identified from outside the homenet? They will have to have two names one internal and one externally visible. > >> e) Homenet name-service MUST function throughout the whole "site" >> >> c) Homenet name-service SHOULD support both lookups and discovery > > What do you mean by "lookups and discovery"? Are they different > forms of name resolution? > lookup is direct query, discovery may use broadcast/multicast messages or a service where applications register in order to be found. >> d) Homenet name-service SHOULD be considerate of bandwidth usage >> >> e) Homenet name-service MUST allow segmentation of "name space" for >> different classes/groups/cliques of applications/devices > > What requirements is this segmentation intended to satisfy? Think kitchen appliances and media center do they ever need to talk ? I worry that if they talk, that one day I open the refrigerator and grab a beer, now suddenly the music changes to polka. But seriously, I want to be able to drop/ignore messages, that nothing on the device cares about, at the lowest layer possible. > >> g) Homenet name-service SHOULD allow both broadcast service as well as >> more traditional lookup service. > > Seems like an implementation detail to support a higher level requirement > like "must not require a centralized registration/resolution service". > Maybe, but as some people seem to assume that only one and not the other operating mode be used I wanted to put this on the table. > Two operational points from my list: > > h) Disconnected operation ("fate sharing"): name resolution for reachable > devices continues if the local network is disconnected from the global > Internet This is a violation of my principle b) home net names should always work if the supplier of the data is awake. I was debating to put in something about supporting devices that are only sometimes on but decided to keep that out. > > i) Unmanaged operation This is a good one Olafur From mike@mtcc.com Fri Jun 29 11:27:45 2012 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 4D33821F8799 for ; Fri, 29 Jun 2012 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KowaLYYPYpDL for ; Fri, 29 Jun 2012 11:27:44 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 54C9921F876C for ; Fri, 29 Jun 2012 11:27:44 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q5TIRfkq004619 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 11:27:42 -0700 Message-ID: <4FEDF39D.8060909@mtcc.com> Date: Fri, 29 Jun 2012 11:27:41 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Ralph Droms References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> In-Reply-To: <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1711; t=1340994462; x=1341858462; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20Ralph=20Droms=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=G81jiEvusD+PVykYe6Cfw4Rj966qf1pg0ZoF4K9ReKs=; b=tQ2qZcU11y9ERkZBop5vQtyczePlyglVEEp6etyIDv2mfgx8rmDAuOW8BB 9xv5/NLQpsfqKX3fPRZgQjzCO5NCq0nc/gYfdlDI0n4I0oFiZBfYwhn4cKB/ CTOj8nVHYR2N/nmaF9mJjb3/mJONb8pxTUD3gURNsbS5/+Vq5Wpy0=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org, Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 18:27:45 -0000 On 06/29/2012 08:34 AM, Ralph Droms wrote: > > a) Homenet name-service MUST NOT interfere with Internet name-service > "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a > better word. Users want a single interface into naming and don't > want to have to differentiate between "naming stuff on my local network" > and "naming stuff in the Internet". Ted Lemon raised this issue much > more eloquently during the WG meeting. > > I'll add my first bullet here, rephrased a little: > > a.1) Relative name resolution: some naming convention that allows name > resolution while mitigating the need to know an absolute location in the > Internet name-service > >> b) Homenet name-service MUST NOT be in Internet name space. > How are things in the home identified from outside the homenet? > Maybe I can add some fuel to Olafur's fire. I'd like to say that the homenet name service MUST be DNS. This may sound like heresy, but here's my reason: I want the ability to transition from a private name space to a public name space with minimal fuss. I don't want a different naming mechanism that has its own oddities just because I can't think up a clever domain name for my home net that goes into the global DNS when I'm forced to install my router. When I'm finally inspired, I want to be able to make that transition and then worry about the split horizon implications (if I even get around to caring about such a thing). So perhaps, we can make use of statistically unique naming to keep things from bumping into one another, etc... this is sort of off the cuff, but the real point is not having to transmogrify one naming scheme into another. Yuck. Mike From d.sturek@att.net Fri Jun 29 12:01:01 2012 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 0A77B21F889D for ; Fri, 29 Jun 2012 12:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLSCu2AqDRD2 for ; Fri, 29 Jun 2012 12:00:59 -0700 (PDT) Received: from nm27-vm3.bullet.mail.ne1.yahoo.com (nm27-vm3.bullet.mail.ne1.yahoo.com [98.138.91.157]) by ietfa.amsl.com (Postfix) with SMTP id 759BD21F88B6 for ; Fri, 29 Jun 2012 12:00:56 -0700 (PDT) Received: from [98.138.226.178] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2012 19:00:52 -0000 Received: from [68.142.194.243] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 29 Jun 2012 19:00:52 -0000 Received: from [66.94.237.99] by t1.bullet.mud.yahoo.com with NNFMP; 29 Jun 2012 19:00:52 -0000 Received: from [127.0.0.1] by omp1004.access.mail.mud.yahoo.com with NNFMP; 29 Jun 2012 19:00:52 -0000 X-Yahoo-Newman-Id: 435118.68469.bm@omp1004.access.mail.mud.yahoo.com Received: (qmail 4105 invoked from network); 29 Jun 2012 19:00:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1340996452; bh=smFEscAnV/tCqnm6IOd0w/lVNjgVX6YSI7SlpKTmFMM=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=KBBc83mYHvmJ/L9iuVDwqBB0Qqqp40dRN9mFXhND2taJ/0lrdGVMz6VdRZLsT954OeRpqEbhSfku4CA3Ff8XuFbytPGOSV+/O3b99VelYMvja9SMCLeFNoEZGQ4kcK/Z//E8TgnZ3Uj0CK/hkqFzDdyjrVc04L1yVzws5hjMa3I= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hLPjQTUVM1lpCx4Wvkq_eFQcEYZ9lMjr8xI5GTArkXyj.Ni FMC1VCFYUv0odUL9CNQYddEHJEYdPSAv_r2Ozv8rURicUW4o1AYJzbBX1Nlm 0QBRYiHIyCTZJpzfZ5a_MCCxVqthvie26L7R1XDt1V4bwW7ecr.3zamfj0Sx tnxPH_4tns9ts1PxEdc.uI3NTV_C14HOrVpNwf4o6Mz9tCP8F8irSZgdX_EE glmPkwzNfeE4ksu5sY3AoenMXnWL7jDIeFdgsq4pysR0XxWLZN9LfntGO7mD MkhzSb6xBSb5Fvtp2XZhn4re7xJOpCzGoIhxWy1kfHNysUZ4znYFKcXHqBnE fAH06yTL8FAe_ovbhPlihny_klEjVe38ZCAQxVjHtj7qK2oL51M23kt41jnn _bxsqnIigKAp659ukMlxXwRAetq1HClB_FZRIRDexpyqpeySD1yqsjxQEbdE eO3FEv5SNWM..GudlOq3vZiMSJf9tKokXXhShcz145EZAPw-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.30.0.104] (d.sturek@87.123.125.225 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 29 Jun 2012 12:00:51 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 29 Jun 2012 11:53:12 -0700 From: Don Sturek To: Michael Thomas , Ralph Droms Message-ID: Thread-Topic: [homenet] Name service design principles: a proposal In-Reply-To: <4FEDF39D.8060909@mtcc.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: homenet@ietf.org, Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:01:01 -0000 Hi Michael, The difficulty with your proposal is that the homenet address space is now connected to the wider internet. Services in the home must be discoverable without any internet connectivity. Don On 6/29/12 11:27 AM, "Michael Thomas" wrote: >On 06/29/2012 08:34 AM, Ralph Droms wrote: >> >> a) Homenet name-service MUST NOT interfere with Internet name-service >> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >> better word. Users want a single interface into naming and don't >> want to have to differentiate between "naming stuff on my local network" >> and "naming stuff in the Internet". Ted Lemon raised this issue much >> more eloquently during the WG meeting. >> >> I'll add my first bullet here, rephrased a little: >> >> a.1) Relative name resolution: some naming convention that allows name >> resolution while mitigating the need to know an absolute location in the >> Internet name-service >> >>> b) Homenet name-service MUST NOT be in Internet name space. >> How are things in the home identified from outside the homenet? >> > >Maybe I can add some fuel to Olafur's fire. I'd like to say that the >homenet name service MUST be DNS. > >This may sound like heresy, but here's my reason: I want the ability >to transition from a private name space to a public name space with >minimal fuss. I don't want a different naming mechanism that has >its own oddities just because I can't think up a clever domain name >for my home net that goes into the global DNS when I'm forced to >install my router. When I'm finally inspired, I want to be able to make >that transition and then worry about the split horizon implications >(if I even get around to caring about such a thing). > >So perhaps, we can make use of statistically unique naming to keep >things from bumping into one another, etc... this is sort of off the cuff, >but the real point is not having to transmogrify one naming scheme into >another. Yuck. > >Mike >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From mike@mtcc.com Fri Jun 29 12:18:58 2012 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 1379C21F8865 for ; Fri, 29 Jun 2012 12:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlNlPKZucBS4 for ; Fri, 29 Jun 2012 12:18:57 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2100C21F8855 for ; Fri, 29 Jun 2012 12:18:57 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q5TJIr5A024516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 12:18:54 -0700 Message-ID: <4FEDFF9D.6010209@mtcc.com> Date: Fri, 29 Jun 2012 12:18:53 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Don Sturek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2946; t=1340997534; x=1341861534; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20Don=20Sturek=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=pCsuORrkr+MhDFFwP3NZ93vh1eXlkkzgEeDXTYSmEf8=; b=uUxbSU+hdoBDQ5vwX1NqcTnY0/D1y8XJEmSh4e/MPYeHTbPT/H+t9UPPeE 0v1RX0RprNUpe3L9eT3tT/YRhOQ5dSZuJ+2ptD2QaAyBb1fVEiJJbLZgAyk1 P0iqN5TkSNU2fGhxA6/ZTjs7rAXZDZJjKuq96jsggq07HpcLQTavk=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: homenet@ietf.org, Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:18:58 -0000 On 06/29/2012 11:53 AM, Don Sturek wrote: > Hi Michael, > > The difficulty with your proposal is that the homenet address space is now > connected to the wider internet. It wasn't a proposal of a solution, so much as plea to not make my life more difficult trying to keep track of the difference between "in" and "out" naming systems. We've done a pretty good job of teaching the world about fqdn's to the point that seeing unqualified names makes me wonder what they are and whether they even refer to anything Internet-like. And of course, I want to have a flip of the switch if I decide to make them Internet-wide visible. > > Services in the home must be discoverable without any internet > connectivity. By discoverable, I assume that you mean that my home name translation still needs to work when I don't have connectivity. That seems like a perfectly reasonable requirement too. Mike > > Don > > > On 6/29/12 11:27 AM, "Michael Thomas" wrote: > >> On 06/29/2012 08:34 AM, Ralph Droms wrote: >>> a) Homenet name-service MUST NOT interfere with Internet name-service >>> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >>> better word. Users want a single interface into naming and don't >>> want to have to differentiate between "naming stuff on my local network" >>> and "naming stuff in the Internet". Ted Lemon raised this issue much >>> more eloquently during the WG meeting. >>> >>> I'll add my first bullet here, rephrased a little: >>> >>> a.1) Relative name resolution: some naming convention that allows name >>> resolution while mitigating the need to know an absolute location in the >>> Internet name-service >>> >>>> b) Homenet name-service MUST NOT be in Internet name space. >>> How are things in the home identified from outside the homenet? >>> >> Maybe I can add some fuel to Olafur's fire. I'd like to say that the >> homenet name service MUST be DNS. >> >> This may sound like heresy, but here's my reason: I want the ability >> to transition from a private name space to a public name space with >> minimal fuss. I don't want a different naming mechanism that has >> its own oddities just because I can't think up a clever domain name >> for my home net that goes into the global DNS when I'm forced to >> install my router. When I'm finally inspired, I want to be able to make >> that transition and then worry about the split horizon implications >> (if I even get around to caring about such a thing). >> >> So perhaps, we can make use of statistically unique naming to keep >> things from bumping into one another, etc... this is sort of off the cuff, >> but the real point is not having to transmogrify one naming scheme into >> another. Yuck. >> >> Mike >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet From bkerensa@gmail.com Fri Jun 29 12:20:43 2012 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 62D6521F8891 for ; Fri, 29 Jun 2012 12:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqBKjQXD9Z6v for ; Fri, 29 Jun 2012 12:20:42 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3C121F888C for ; Fri, 29 Jun 2012 12:20:42 -0700 (PDT) Received: by dacx6 with SMTP id x6so4956614dac.31 for ; Fri, 29 Jun 2012 12:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LpRpIDf9+FpOSo9ufwW/aXCIYgqCy1Jckq5IJm/wOq4=; b=pq9rilQwm5OLpVvIwuNLmM+8hrGapoWE/5ts6e5ABYH5JuSsH8G00zHEsHFivSSPnR ERXgLwcjCpmo5uCkyryUZkzKyNOklN6KvXxqtLI3/qyo9/0O6GdUQhlqUUodt3Gk+N43 NBhM7jSkCZj3AApIg3+/QAuDt9yVMzwsJNu3wWJh+OcSRU22stzoYRFnMazU5nwAH8iz 7HtyDjbbFR3Ad9hxLA+hhgvPSuk7mPh5lMmGbF4d5eg33UXNcVHVRFFYQnCmkkT9y1PE WiIKZ+ngeQbwryKXo4C1kLE51fRq/gIl5jWobzoQWcR11nj2P3hLdGdrqW4ACWvEiFth nB1g== Received: by 10.68.238.232 with SMTP id vn8mr9732461pbc.78.1340997642064; Fri, 29 Jun 2012 12:20:42 -0700 (PDT) Received: from [192.168.2.3] (c-24-21-188-65.hsd1.or.comcast.net. [24.21.188.65]) by mx.google.com with ESMTPS id tq4sm6266407pbc.11.2012.06.29.12.20.41 (version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 12:20:41 -0700 (PDT) Sender: Benjamin Kerensa Message-ID: <4FEE0008.3010304@ubuntu.com> Date: Fri, 29 Jun 2012 12:20:40 -0700 From: Benjamin Kerensa Organization: Ubuntu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120620 Thunderbird/14.0 MIME-Version: 1.0 To: homenet@ietf.org References: <4FEDFF9D.6010209@mtcc.com> In-Reply-To: <4FEDFF9D.6010209@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:20:43 -0000 On 06/29/2012 12:18 PM, Michael Thomas wrote: > On 06/29/2012 11:53 AM, Don Sturek wrote: >> Hi Michael, >> >> The difficulty with your proposal is that the homenet address space >> is now >> connected to the wider internet. > > It wasn't a proposal of a solution, so much as plea to not make my > life more difficult trying to keep track of the difference between > "in" and "out" naming systems. We've done a pretty good job of > teaching the world about fqdn's to the point that seeing unqualified > names makes me wonder what they are and whether they even refer > to anything Internet-like. And of course, I want to have a flip of > the switch if I decide to make them Internet-wide visible. > >> >> Services in the home must be discoverable without any internet >> connectivity. > > > By discoverable, I assume that you mean that my home name translation > still needs to work when I don't have connectivity. That seems like a > perfectly reasonable requirement too. > > Mike > >> >> Don >> >> >> On 6/29/12 11:27 AM, "Michael Thomas" wrote: >> >>> On 06/29/2012 08:34 AM, Ralph Droms wrote: >>>> a) Homenet name-service MUST NOT interfere with Internet name-service >>>> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >>>> better word. Users want a single interface into naming and don't >>>> want to have to differentiate between "naming stuff on my local >>>> network" >>>> and "naming stuff in the Internet". Ted Lemon raised this issue much >>>> more eloquently during the WG meeting. >>>> >>>> I'll add my first bullet here, rephrased a little: >>>> >>>> a.1) Relative name resolution: some naming convention that allows name >>>> resolution while mitigating the need to know an absolute location >>>> in the >>>> Internet name-service >>>> >>>>> b) Homenet name-service MUST NOT be in Internet name space. >>>> How are things in the home identified from outside the homenet? >>>> >>> Maybe I can add some fuel to Olafur's fire. I'd like to say that the >>> homenet name service MUST be DNS. >>> >>> This may sound like heresy, but here's my reason: I want the ability >>> to transition from a private name space to a public name space with >>> minimal fuss. I don't want a different naming mechanism that has >>> its own oddities just because I can't think up a clever domain name >>> for my home net that goes into the global DNS when I'm forced to >>> install my router. When I'm finally inspired, I want to be able to make >>> that transition and then worry about the split horizon implications >>> (if I even get around to caring about such a thing). >>> >>> So perhaps, we can make use of statistically unique naming to keep >>> things from bumping into one another, etc... this is sort of off the >>> cuff, >>> but the real point is not having to transmogrify one naming scheme into >>> another. Yuck. Seems like a smart move >>> >>> Mike >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Benjamin Kerensa http://benjaminkerensa.com "I am what I am because of who we all are" - Ubuntu From jhw@apple.com Fri Jun 29 12:58:30 2012 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 140EF21F8808 for ; Fri, 29 Jun 2012 12:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR6K4mLfVqpw for ; Fri, 29 Jun 2012 12:58:29 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB3121F8687 for ; Fri, 29 Jun 2012 12:58:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M6E00B8QA4BVAC2@mail-out.apple.com> for homenet@ietf.org; Fri, 29 Jun 2012 12:58:04 -0700 (PDT) X-AuditID: 11807112-b7f826d000004103-00-4fee08cc683a Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 22.BE.16643.CC80EEF4; Fri, 29 Jun 2012 12:58:04 -0700 (PDT) From: james woodyatt In-reply-to: <4FEDF39D.8060909@mtcc.com> Date: Fri, 29 Jun 2012 12:58:03 -0700 Message-id: References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1482) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42IRPMjroHuG452/wY1GAYv3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEr49CBncwFk1gr3nT+YmtgnMLSxcjBISFgItH216SLkRPIFJO4 cG89WxcjF4eQwGwmid3/TzODJJgFtCRu/HvJBGLzCuhJ3Nt+A8wWFnCU2PLmGxuIzSagIvHt 8l2wOKeAhsTOKb1gcRYBVYmt22axQ8zRlli28DUzxBwbicenn7KC2EICJRJv9s5gBLFFBPQl nh75xQZxkKzE7+3LWSYw8s1CcsYsJGfMQjJ2ASPzKkbBotScxEpDc73EgoKcVL3k/NxNjKBA aigU2sF4f5feIUYBDkYlHt5NV9/6C7EmlhVX5h5ilOBgVhLhfbgYKMSbklhZlVqUH19UmpNa fIhRmoNFSZz3f8VrfyGB9MSS1OzU1ILUIpgsEwenVAOj0TEtofXqsn+K/fflCAS9bD67NGHD mmBPsfirQhzyh/LmLBW/9aJicgjbmler2c7cLphvEZLxZPXGexImIiyvHAuTpt0IU65erGza 2pb9c6UJj8q5GbkbhHiLhJXmffz8NfNoiKH3BQUeFv2UAMmQOzKc8v8Tq2czVVZln7pxM+3i dX3lpGglluKMREMt5qLiRACkMtwjIAIAAA== Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:58:30 -0000 On Jun 29, 2012, at 11:27 , Michael Thomas wrote: > > Maybe I can add some fuel to Olafur's fire. I'd like to say that the homenet name service MUST be DNS. Let's go further. Let's say that it must be DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for 199 days at this point, so one imagines that it stands a decent chance of being a published RFC by the time HOMENET finishes its first round of major work. -- james woodyatt member of technical staff, core os networking [*] From kerlyn2001@gmail.com Fri Jun 29 13:07:56 2012 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 C636C21F859A for ; Fri, 29 Jun 2012 13:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOgh6Bvytv2Z for ; Fri, 29 Jun 2012 13:07:55 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64D9221F8595 for ; Fri, 29 Jun 2012 13:07:55 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5157631pbc.31 for ; Fri, 29 Jun 2012 13:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h0l6xDlziWGwED0MGwdUlBVUQXmKGILVBFIevTIRKog=; b=briX97p3ydBkBVJHS9MzqeNYYU4iAZnjotk0wGLls3/Ob02vwnVzUCwiPODuJlnn9+ 0ndrIT3YywX9ak2ZbxlB/sd7OL5zdlGoZhQ1Bndfr3C4OP5KrIXAQHNvBBozLgjBi7A4 yQG730q7lwW04G2msd/nU0kQKhCVzlzzxiX8kMt0qvn5zvq7+nq2SwmEE+twxYGNQe7e NMSUBjD1ySa0sykyZma98xFj6tMXUA/YMtjrpK42miD/jWmb+L0LF44O172yPq2mmzn9 24BcbRL01oiAq6ciRi1yg+4pruk+JLfIAgQYalrXxsA2UJqcagBYfLWCYtCpJzH+KJ+G Ex5A== MIME-Version: 1.0 Received: by 10.66.89.170 with SMTP id bp10mr3055573pab.12.1341000475087; Fri, 29 Jun 2012 13:07:55 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.142.47.11 with HTTP; Fri, 29 Jun 2012 13:07:55 -0700 (PDT) In-Reply-To: <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> Date: Fri, 29 Jun 2012 16:07:55 -0400 X-Google-Sender-Auth: zO6x-8hL5dQVxbnR3aVRL9EGkk8 Message-ID: From: Kerry Lynn To: Ralph Droms Content-Type: multipart/alternative; boundary=f46d04289c89f6116604c3a2005f Cc: homenet@ietf.org, Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:07:56 -0000 --f46d04289c89f6116604c3a2005f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 11:34 AM, Ralph Droms wrote: > So, let's compare this with what I talked about during the Paris WG > meeting: > > * Disconnected operation ("fate sharing"): name resolution for reachable > devices continues if the local network is disconnected from the global > Internet > > * Relative name resolution: some naming convention that allows name > resolution while mitigating the need to know an absolute location in the > global DNS namespace > > * Representation in the global DNS namespace, for access from off-net > > * Unmanaged operation > > * Efficient message utilization: for example, keep unwanted traffic > off of an IEEE802.15.4 network > > Merging those points with comments in-line... > > > On Jun 29, 2012, at 11:06 AM 6/29/12, Olafur Gudmundsson wrote: > > > After the Homenet meeting in Paris I realized that the group needs > > good principles for its name-space work. The principles in -arch-02 are > > a good start but IMHO not sufficient. > > It makes not sense to be proposing/evaluating solutions when there > > are no agreed upon principles/requirements. > > > > The chairs have been bugging me to follow up with a contribution. > > Below is my attempt at defining as compactly/broadly as > > possible design principles for Name services: > > > You don't state the usual "strong bias toward existing standards/running code", so I assume it goes without saying ;-) > > a) Homenet name-service MUST NOT interfere with Internet name-service > > "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a > better word. Users want a single interface into naming and don't > want to have to differentiate between "naming stuff on my local network" > and "naming stuff in the Internet". Ted Lemon raised this issue much > more eloquently during the WG meeting. > > I'd go further and say users want a single way to THINK about local and wide-area names and resolution. Some of us with a strong bias toward a DNS-like solution have been looking at this issue for 2+ years in other contexts. > I'll add my first bullet here, rephrased a little: > > a.1) Relative name resolution: some naming convention that allows name > resolution while mitigating the need to know an absolute location in the > Internet name-service > > Is the desire here to preserve the "main" element of the name (e.g. the leftmost label of a FQDN)? > > b) Homenet name-service MUST NOT be in Internet name space. > > How are things in the home identified from outside the homenet? > > It would be helpful Olafur if you could provide some motivation for these requirements. I agree that local naming and discovery should be possible without requiring a directory server. But if I can access myHost.myDomain.net from outside, why not from inside the home net? > > e) Homenet name-service MUST function throughout the whole "site" > > > > c) Homenet name-service SHOULD support both lookups and discovery > > What do you mean by "lookups and discovery"? Are they different > forms of name resolution? > > > d) Homenet name-service SHOULD be considerate of bandwidth usage > > > Could this be restated as "the bandwidth requirement for discovery should remain relatively constant as the network scales"? The cost of achieving this may be to add additional elements like proxies or directory servers to the network. > e) Homenet name-service MUST allow segmentation of "name space" for > > different classes/groups/cliques of applications/devices > > What requirements is this segmentation intended to satisfy? > > This may be tricky in practice, and should be prioritized relative to other requirements. We discuss methods in http://tools.ietf.org/html/draft-vanderstok-core-dna. If this requirement must be met by a multicast protocol, the fact is that many OSs only support a handful of multicast addresses. > > g) Homenet name-service SHOULD allow both broadcast service as well as > > more traditional lookup service. > > Seems like an implementation detail to support a higher level requirement > like "must not require a centralized registration/resolution service". > > An important point here is that existing discovery protocols are not going away any time soon and could be leveraged to "seed" a directory server with records. Two operational points from my list: > > h) Disconnected operation ("fate sharing"): name resolution for reachable > devices continues if the local network is disconnected from the global > Internet > > And if the local directory server goes down... > i) Unmanaged operation > > Yes!!! -K- > > > > I'm expecting a lively discussion on this topic :-) > > OK, I've contributed to the discussion. > > - Ralph > > > > > > > Olafur > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --f46d04289c89f6116604c3a2005f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 11:34 AM, Ralph Droms <rdroms.ietf@gmail.com> wrote:
So, let's compare this with what I talked about during the Paris WG mee= ting:

* Disconnected operation ("fate sharing"): name resolution for re= achable
devices continues if the local network is disconnected from the global
Internet

* Relative name resolution: some naming convention that allows name
resolution while mitigating the need to know an absolute location in the global DNS namespace

* Representation in the global DNS namespace, for access from off-net

* Unmanaged operation

* Efficient message utilization: for example, keep unwanted traffic
off of an IEEE802.15.4 network

Merging those points with comments in-line...


On Jun 29, 2012, at 11:06 AM 6/29/12, Olafur Gudmundsson wrote:

> After the Homenet meeting in Paris I realized that the group needs
> good principles for its name-space work. The principles in -arch-02 ar= e
> a good start but IMHO not sufficient.
> It makes not sense to be proposing/evaluating solutions when there
> are no agreed upon principles/requirements.
>
> The chairs have been bugging me to follow up with a contribution.
> Below is my attempt at defining as compactly/broadly as
> possible design principles for Name services:
>
You don't state the usual "strong = bias toward existing standards/running code",
so I assume it= goes without saying ;-)=A0
=A0
> a) Homenet name-service MUST NOT interfere with Internet name-service<= br>
"Internet name-service"? =A0Do you mean "DNS"? = =A0"Co-exist" might be a
better word. =A0Users want a single interface into naming and don't
want to have to differentiate between "naming stuff on my local networ= k"
and "naming stuff in the Internet". =A0Ted Lemon raised this issu= e much
more eloquently during the WG meeting.

I'd go further and say users want a single way to= THINK about local and
wide-area names and resolution. =A0Some of= us with a strong bias toward a
DNS-like solution have been looki= ng at this issue for 2+ years in other
contexts.
=A0
I'll add my first bullet here, rephrased a little:

a.1) Relative name resolution: some naming convention that allows name
resolution while mitigating the need to know an absolute location in the
Internet name-service

Is the desire here to preserve the "main&q= uot; element of the name (e.g. the
leftmost label of a FQDN)?
=A0
> b) Homenet name-service MUST NOT be in Internet name space.

How are things in the home identified from outside the homenet?

It would be helpful Olafur if= you could provide some motivation for these
requirements. =A0=A0= I agree that=A0local naming and discovery should be possible
from outside, why=A0not from inside the=A0home net?
=A0
> e) Homenet name-service MUST function throughout the whole "site&= quot;
>
> c) Homenet name-service SHOULD support both lookups and discovery

What do you mean by "lookups and discovery"? =A0Are they di= fferent
forms of name resolution?

> d) Homenet name-service SHOULD be considerate of bandwidth usage
>
Could this be restated as "the bandwid= th requirement for discovery should remain
relatively constant as= the network scales"? =A0The cost of achieving this may be
to add additional elements like proxies or directory servers to the network= .

> e) Homenet name-service MUST allow segmentation of "name space&qu= ot; for
> different classes/groups/cliques of applications/devices

What requirements is this segmentation intended to satisfy?

This may be tricky in practic= e, and should be prioritized relative to other=A0requirements.
this requirement must be met by a multicast protocol, the fact is that= many OSs
only support a handful of multicast addresses.
=A0
> g) Homenet name-service SHOULD allow both broadcast service as well as=
> =A0 more traditional lookup service.

Seems like an implementation detail to support a higher level require= ment
like "must not require a centralized registration/resolution service&q= uot;.

An important point here is that existing discovery pr= otocols are not going away any
time soon and could be leveraged= =A0to "seed" a directory server with records.

Two operational points from my list:

h) Disconnected operation ("fate sharing"): name resolution for r= eachable
devices continues if the local network is disconnected from the global
Internet

And if the local directory server goes down...
<= div>=A0
i) Unmanaged operation

Yes!!!

-K-
=A0
>
> I'm expecting a lively discussion on this topic :-)

OK, I've contributed to the discussion.

- Ralph



>
> =A0 =A0Olafur
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--f46d04289c89f6116604c3a2005f-- From rdroms.ietf@gmail.com Fri Jun 29 13:09:10 2012 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 376A121F85A4 for ; Fri, 29 Jun 2012 13:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8P-jmeGi6Sl for ; Fri, 29 Jun 2012 13:09:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD2A21F859E for ; Fri, 29 Jun 2012 13:09:09 -0700 (PDT) Received: by qcac10 with SMTP id c10so1044241qca.31 for ; Fri, 29 Jun 2012 13:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DJFi1i9SjyM/GYy5mljOOTiI6VC2Dll7KmtEugUNiZ8=; b=DKoflHZTXnOi1AB75ZkekZknGJAAdeuNFfhgFB//8J4lQQobKNTemn2FCMFP69xJpC J96hD68BQALbpflU89kcWWGIKeAs1hoYUhYOJwXLZTj+kOmx60Ad5+MgK75IApJP50fB fNNI4pIoG+xLVjtdm6NIZAluJ9A4pT0LmofxdHwvp6zADgqN8zO+Qew7c7S4IVh6PO8z UPGsd3fhGsuZZRvu0vXtVJy9bGdHfYyPJmzOUK4wIpUuDT5kXp7VyrtwjMF1/swG4vlZ rzxCCoSGXCE4K/YmrAy81YVcOji5/cG+s9Z6s/1/bdsfQvfl4Vy018C9GaumTDS6S2yu aCFw== Received: by 10.224.177.10 with SMTP id bg10mr6499650qab.54.1341000548853; Fri, 29 Jun 2012 13:09:08 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id bk12sm12317482qab.6.2012.06.29.13.09.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:09:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 29 Jun 2012 16:09:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7EFFABA0-F840-4A86-AECF-1D2C2B10B217@gmail.com> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> To: james woodyatt X-Mailer: Apple Mail (2.1278) Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:09:10 -0000 On Jun 29, 2012, at 3:58 PM 6/29/12, james woodyatt wrote: > On Jun 29, 2012, at 11:27 , Michael Thomas wrote: >>=20 >> Maybe I can add some fuel to Olafur's fire. I'd like to say that the = homenet name service MUST be DNS. >=20 > Let's go further. Let's say that it must be DNS-Based Service = Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor = Queue for 199 days at this point, so one imagines that it stands a = decent chance of being a published RFC by the time HOMENET finishes its = first round of major work. Well, DNS-Based Service Discovery addresses just one kind of = requirement: listing entities that provide a certain kind of service; = perhaps generalizable to resolution based on a characteristic or set of = characteristics that might return more than one response to the = resolution request. At some point, there needs to be a mechanism for = resolving an identity to a single IP address. - Ralph >=20 >=20 > -- > james woodyatt > member of technical staff, core os networking >=20 > [*] > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From kerlyn2001@gmail.com Fri Jun 29 13:19:22 2012 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 B700121F88DB for ; Fri, 29 Jun 2012 13:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.681 X-Spam-Level: X-Spam-Status: No, score=-99.681 tagged_above=-999 required=5 tests=[AWL=-3.295, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyeXx2v3Hf+E for ; Fri, 29 Jun 2012 13:19:21 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6D55D21F88A9 for ; Fri, 29 Jun 2012 13:19:21 -0700 (PDT) Received: by dacx6 with SMTP id x6so5012323dac.31 for ; Fri, 29 Jun 2012 13:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=DFvpkCEwVXjkeqmn/AKMve0ia9Mr2B8MF2NgRiJQ64w=; b=m6xzvKAav5h00tddcD+4l49WA91cYJQmNwjs0LXr+XBo7KysFpRuvuAxfnY4aKms4T B5+/4dl1T9fcyjVJxXAIQXZ02tYsjfkefnGPYf6/ERjCo8AbI5JtASsyoxRealECnCzz jbZ1Oo+xm0dfN4i1/cEafUzv+64VR1BkQoo+QL2zX50VCYYPIohup6Q+nRnQY/CzY6JU ZFRcMX5riYiZfrFGAM6Xdnr+IZXOfiVb9UdGMWb5BkffHerE/fmF1lxdZKDoijsxjPBC tOeXfKUCRyZoW/XmIAMr9+tALoneW9lXqmir1dsw1E+I2neygovvC7PatmviTYrxr870 hDBA== MIME-Version: 1.0 Received: by 10.68.224.225 with SMTP id rf1mr9491649pbc.55.1341001160887; Fri, 29 Jun 2012 13:19:20 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.142.47.11 with HTTP; Fri, 29 Jun 2012 13:19:20 -0700 (PDT) In-Reply-To: <7EFFABA0-F840-4A86-AECF-1D2C2B10B217@gmail.com> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <7EFFABA0-F840-4A86-AECF-1D2C2B10B217@gmail.com> Date: Fri, 29 Jun 2012 16:19:20 -0400 X-Google-Sender-Auth: xg-1zMI418YLXdz3Gbo65ih9Rao Message-ID: From: Kerry Lynn To: Ralph Droms Content-Type: multipart/alternative; boundary=e89a8ff24b3bd68bcb04c3a22995 Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:19:22 -0000 --e89a8ff24b3bd68bcb04c3a22995 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 4:09 PM, Ralph Droms wrote: > > On Jun 29, 2012, at 3:58 PM 6/29/12, james woodyatt wrote: > > > On Jun 29, 2012, at 11:27 , Michael Thomas wrote: > >> > >> Maybe I can add some fuel to Olafur's fire. I'd like to say that the > homenet name service MUST be DNS. > > > > Let's go further. Let's say that it must be DNS-Based Service Discovery > [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for > 199 days at this point, so one imagines that it stands a decent chance of > being a published RFC by the time HOMENET finishes its first round of major > work. > > Hear, hear! > Well, DNS-Based Service Discovery addresses just one kind of requirement: > listing entities that provide a certain kind of service; perhaps > generalizable to resolution based on a characteristic or set of > characteristics that might return more than one response to the resolution > request. At some point, there needs to be a mechanism for resolving an > identity to a single IP address. > > Actually, a Multicast DNS responder (mDNS is the multicast version of DNS-SD) will allow you to resolve A, AAAA records: Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @224.0.0.251 _http._tcp.local PTR <<<< We first discover web servers ; <<>> DiG 9.7.3-P3 <<>> -p 5353 @224.0.0.251 _http._tcp.local PTR ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33690 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;_http._tcp.local. IN PTR ;; ANSWER SECTION: _http._tcp.local. 10 IN PTR Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local. ;; ADDITIONAL SECTION: Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local. 10 IN SRV 0 0 80 HP4C0EA4.local. Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local. 10 IN TXT "" HP4C0EA4.local. 10 IN A 192.168.1.31 HP4C0EA4.local. 10 IN AAAA fe80::dad3:85ff:fe4c:ea4 ;; Query time: 20 msec ;; SERVER: 192.168.1.31#5353(224.0.0.251) ;; WHEN: Fri Jun 29 16:13:10 2012 ;; MSG SIZE rcvd: 168 Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @224.0.0.251 HP4C0EA4.local A <<<< We can also resolve the host record ; <<>> DiG 9.7.3-P3 <<>> -p 5353 @224.0.0.251 HP4C0EA4.local A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40117 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;HP4C0EA4.local. IN A ;; ANSWER SECTION: HP4C0EA4.local. 10 IN A 192.168.1.31 ;; Query time: 1 msec ;; SERVER: 192.168.1.31#5353(224.0.0.251) ;; WHEN: Fri Jun 29 16:13:39 2012 ;; MSG SIZE rcvd: 48 Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @192.168.1.31 HP4C0EA4.local A <<<< We can just as easily unicast the query ; <<>> DiG 9.7.3-P3 <<>> -p 5353 @192.168.1.31 HP4C0EA4.local A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32090 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;HP4C0EA4.local. IN A ;; ANSWER SECTION: HP4C0EA4.local. 10 IN A 192.168.1.31 ;; Query time: 2 msec ;; SERVER: 192.168.1.31#5353(192.168.1.31) ;; WHEN: Fri Jun 29 16:17:47 2012 ;; MSG SIZE rcvd: 48 > - Ralph > > > > > > > -- > > james woodyatt > > member of technical staff, core os networking > > > > [*] > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > --e89a8ff24b3bd68bcb04c3a22995 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 4:09 PM, Ralph Droms <rdroms.ietf@gmail.com> wrote:

On Jun 29, 2012, at 3:58 PM 6/29/12, james woodyatt wrote:

> On Jun 29, 2012, at 11:27 , Michael Thomas <mike@mtcc.com> wrote:
>>
>> Maybe I can add some fuel to Olafur's fire. I'd like to sa= y that the homenet name service MUST be DNS.
>
> Let's go further. =A0Let's say that it must be DNS-Based Servi= ce Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor= Queue for 199 days at this point, so one imagines that it stands a decent = chance of being a published RFC by the time HOMENET finishes its first roun= d of major work.

Hear, hear!
=A0
Well, DNS-Based Service Discovery addresses just one kind of requirem= ent: listing entities that provide a certain kind of service; perhaps gener= alizable to resolution based on a characteristic or set of characteristics = that might return more than one response to the resolution request. =A0At s= ome point, there needs to be a mechanism for resolving an identity to a sin= gle IP address.

Actually, a Multicast DNS responder (mDNS is the multicast version = of DNS-SD)
will allow you to resolve A, AAAA records:

Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @224.0.0.251 _http._tcp.local PTR =A0 =A0 <<<&l= t; We first discover web servers

; <<>>= ; DiG 9.7.3-P3 <<>> -p 5353 @224= .0.0.251 _http._tcp.local PTR
; (1 server found)
;; global options: +cmd
;; Got = answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERRO= R, id: 33690
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, = ADDITIONAL: 4

;; QUESTION SECTION:
;_http._tcp.local. IN PTR

;; ANSWER SECTION:
_http._tcp.local. 10 IN PTR Officejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.loca= l.

;; ADDITIONAL SECTION:
Officejet\032Pro\03285= 00\032A909g\032[4C0EA4]._http._tcp.local. 10 IN SRV 0 0 80 HP4C0EA4.local.
O= fficejet\032Pro\0328500\032A909g\032[4C0EA4]._http._tcp.local. 10 IN TXT ""= ;
HP4C0EA4.local. 10 IN A 192.168.1.31
HP4C0EA4.local. 10 IN AAAA<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> fe80::dad3:= 85ff:fe4c:ea4

;; Query time: 20 msec
;; SERVER: 192.168.1.3= 1#5353(224.0.0.251)
;; WHEN: Fri Jun 29 16:13:10 2012
;= ; MSG SIZE =A0rcvd: 168



Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @224.0.0.251 HP4C0EA4.local A =A0 =A0 <<<< We can also= resolve the host record

; <<>> DiG 9.= 7.3-P3 <<>> -p 5353 @224.0.0.251= HP4C0EA4.local A
; (1 server found)
;; global options: +cmd
;; Got = answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERRO= R, id: 40117
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, = ADDITIONAL: 0

;; QUESTION SECTION:
;HP4C0EA4.local. IN A

;; ANSWER SECTION:
HP4C0EA4.local. 10 IN A 192.168.1.31

;; Query time: 1 msec
;; SERVER: 192.168.1.31= #5353(224.0.0.251)
;; WHEN: Fri Jun 29 16:13:39 2012
;;= MSG SIZE =A0rcvd: 48



Kerrys-MacBook-Pro:6in4 kerlyn$ dig -p 5353 @192.168.1.31 HP4C0EA4.local A =A0 =A0<<<< We can jus= t as easily unicast the query

; <<>> D= iG 9.7.3-P3 <<>> -p 5353 @192.1= 68.1.31 HP4C0EA4.local A
; (1 server found)
;; global options: +cmd
;; Got = answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERRO= R, id: 32090
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, = ADDITIONAL: 0

;; QUESTION SECTION:
;HP4C0EA4.local. IN A

;; ANSWER SECTION:
HP4C0EA4.local. 10 IN A 192.168.1.31

;; Query time: 2 msec
;; SERVER: 192.168.1.31= #5353(192.168.1.31)
;; WHEN: Fri Jun 29 16:17:47 2012
;= ; MSG SIZE =A0rcvd: 48

=A0
- Ralph

>
>
> --
> james woodyatt <jhw@apple.com&= gt;
> member of technical staff, core os networking
>
> [*] <http://datatracker.ietf.org/doc/draft-cheshir= e-dnsext-dns-sd/>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

--e89a8ff24b3bd68bcb04c3a22995-- From rdroms.ietf@gmail.com Fri Jun 29 13:26:10 2012 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 542B221F88F9 for ; Fri, 29 Jun 2012 13:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.572 X-Spam-Level: X-Spam-Status: No, score=-103.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEGbnLCv56ww for ; Fri, 29 Jun 2012 13:26:09 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA021F88F5 for ; Fri, 29 Jun 2012 13:26:08 -0700 (PDT) Received: by qcac10 with SMTP id c10so1053408qca.31 for ; Fri, 29 Jun 2012 13:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aiUuNvSoPcqbtAtKghQl4k9WZ/ZuVq0veYKB34hEK5E=; b=m24BKorno8m1GSgkjm42bu0NaJ1mQ6US+Jp0d1cMTCzEe4hqSeS5u02f4xOqepx6Gl O1RkgCIpZZLNb1sELHT5F09VfhGSfgJoKfl6ri2ikMBVC4GB3IyyjeKrvkdZJXdHUV2x Du2Lakqt45oPSJIe3Vi0HC0X8Y2kMp/1h/KOUZvzpM/09uBCEoREIv7nuYPNL6+fULoo vQuQE0/kUbuCQQ8Z/xVWVzCGBSO2S2WzFpziujBmcxFpSYHnuiWWBWC04agMnAV961Ux U54RyIPUpzB+NzFojYJTmqOe04xnSq7WLihudlKBn5KxdQPy4E+2b+okklrigefT5SiW tXrA== Received: by 10.224.214.72 with SMTP id gz8mr6472503qab.88.1341001568355; Fri, 29 Jun 2012 13:26:08 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id dz4sm12408813qab.4.2012.06.29.13.26.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:26:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: Date: Fri, 29 Jun 2012 16:26:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1F751695-448F-46ED-B042-CCB72D7926E3@gmail.com> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> To: Kerry Lynn X-Mailer: Apple Mail (2.1278) Cc: homenet@ietf.org, Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:26:10 -0000 On Jun 29, 2012, at 4:07 PM 6/29/12, Kerry Lynn wrote: > On Fri, Jun 29, 2012 at 11:34 AM, Ralph Droms = wrote: > So, let's compare this with what I talked about during the Paris WG = meeting: >=20 > * Disconnected operation ("fate sharing"): name resolution for = reachable > devices continues if the local network is disconnected from the global > Internet >=20 > * Relative name resolution: some naming convention that allows name > resolution while mitigating the need to know an absolute location in = the > global DNS namespace >=20 > * Representation in the global DNS namespace, for access from off-net >=20 > * Unmanaged operation >=20 > * Efficient message utilization: for example, keep unwanted traffic > off of an IEEE802.15.4 network >=20 > Merging those points with comments in-line... >=20 >=20 > On Jun 29, 2012, at 11:06 AM 6/29/12, Olafur Gudmundsson wrote: >=20 >> > After the Homenet meeting in Paris I realized that the group needs >> > good principles for its name-space work. The principles in -arch-02 = are >> > a good start but IMHO not sufficient. >> > It makes not sense to be proposing/evaluating solutions when there >> > are no agreed upon principles/requirements. >> > >> > The chairs have been bugging me to follow up with a contribution. >> > Below is my attempt at defining as compactly/broadly as >> > possible design principles for Name services: >> > >> You don't state the usual "strong bias toward existing = standards/running code", > so I assume it goes without saying ;-)=20 > =20 >> > a) Homenet name-service MUST NOT interfere with Internet = name-service >>=20 >> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >> better word. Users want a single interface into naming and don't >> want to have to differentiate between "naming stuff on my local = network" >> and "naming stuff in the Internet". Ted Lemon raised this issue much >> more eloquently during the WG meeting. >>=20 > I'd go further and say users want a single way to THINK about local = and > wide-area names and resolution. Some of us with a strong bias toward = a > DNS-like solution have been looking at this issue for 2+ years in = other > contexts. Yes ... which is roughly the message I took from Ted's contribution at = the WG meeting. That way of thinking about local and non-local names = might even be a GUI or some other way of presenting a list of choices to = a user. As long as there as the information is "just right" (not too = much and not too little), the underlying resolution methods can be = hidden. =20 >=20 >> I'll add my first bullet here, rephrased a little: >>=20 >> a.1) Relative name resolution: some naming convention that allows = name >> resolution while mitigating the need to know an absolute location in = the >> Internet name-service >>=20 > Is the desire here to preserve the "main" element of the name (e.g. = the > leftmost label of a FQDN)? Roughly speaking. I think what's needed is some equivalent of RFC 1918 = addressing: a way of doing name resolution that has a "local" context = without needing to have a globally unique name for that context. > =20 >> > b) Homenet name-service MUST NOT be in Internet name space. >>=20 >> How are things in the home identified from outside the homenet? >>=20 > It would be helpful Olafur if you could provide some motivation for = these > requirements. I agree that local naming and discovery should be = possible > without requiring a directory server. But if I can access = myHost.myDomain.net > from outside, why not from inside the home net? > =20 >> > e) Homenet name-service MUST function throughout the whole "site" >> > >> > c) Homenet name-service SHOULD support both lookups and discovery >>=20 >> What do you mean by "lookups and discovery"? Are they different >> forms of name resolution? >>=20 >> > d) Homenet name-service SHOULD be considerate of bandwidth usage >> > > Could this be restated as "the bandwidth requirement for discovery = should remain > relatively constant as the network scales"? The cost of achieving = this may be > to add additional elements like proxies or directory servers to the = network. Or, perhaps, bandwidth requirement scales with the number of devices = interested in the specific queries and responses. Assuming the = name-service functions across the whole site, I was thinking in = particular of the case of an IEEE 802.15.4 network of constrained = devices that don't need to see all the name-service traffic for = printers, mobile devices, etc. >=20 >> > e) Homenet name-service MUST allow segmentation of "name space" for >> > different classes/groups/cliques of applications/devices >>=20 >> What requirements is this segmentation intended to satisfy? >>=20 > This may be tricky in practice, and should be prioritized relative to = other requirements. > We discuss methods in = http://tools.ietf.org/html/draft-vanderstok-core-dna. If > this requirement must be met by a multicast protocol, the fact is that = many OSs > only support a handful of multicast addresses. > =20 >> > g) Homenet name-service SHOULD allow both broadcast service as well = as >> > more traditional lookup service. >>=20 >> Seems like an implementation detail to support a higher level = requirement >> like "must not require a centralized registration/resolution = service". >>=20 > An important point here is that existing discovery protocols are not = going away any > time soon and could be leveraged to "seed" a directory server with = records. >=20 >> Two operational points from my list: >>=20 >> h) Disconnected operation ("fate sharing"): name resolution for = reachable >> devices continues if the local network is disconnected from the = global >> Internet >>=20 > And if the local directory server goes down... ...if there is one. > =20 > i) Unmanaged operation >=20 > Yes!!! A universal point of agreement? - Ralph >=20 > -K- > =20 > > > > I'm expecting a lively discussion on this topic :-) >=20 > OK, I've contributed to the discussion. >=20 > - Ralph >=20 >=20 >=20 > > > > Olafur > > _______________________________________________ > > homenet mailing list > > homenet@ietf.org > > https://www.ietf.org/mailman/listinfo/homenet >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >=20 From v6ops@globis.net Fri Jun 29 13:30:24 2012 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 A7E0221F8828 for ; Fri, 29 Jun 2012 13:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.654 X-Spam-Level: *** X-Spam-Status: No, score=3.654 tagged_above=-999 required=5 tests=[AWL=6.253, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjlC-3Gf2Ul3 for ; Fri, 29 Jun 2012 13:30:23 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 057BA21F88E0 for ; Fri, 29 Jun 2012 13:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 8F91F8700B3; Fri, 29 Jun 2012 22:30:21 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSQ+TvYoE79n; Fri, 29 Jun 2012 22:30:16 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 8C2F387007D; Fri, 29 Jun 2012 22:30:16 +0200 (CEST) Message-ID: <4FEE1057.1030005@globis.net> Date: Fri, 29 Jun 2012 22:30:15 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Michael Thomas References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> In-Reply-To: <4FEDF39D.8060909@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:30:25 -0000 Michael Thomas wrote: > On 06/29/2012 08:34 AM, Ralph Droms wrote: >> >> a) Homenet name-service MUST NOT interfere with Internet name-service >> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >> better word. Users want a single interface into naming and don't >> want to have to differentiate between "naming stuff on my local network" >> and "naming stuff in the Internet". Ted Lemon raised this issue much >> more eloquently during the WG meeting. >> >> I'll add my first bullet here, rephrased a little: >> >> a.1) Relative name resolution: some naming convention that allows name >> resolution while mitigating the need to know an absolute location in the >> Internet name-service >> >>> b) Homenet name-service MUST NOT be in Internet name space. >> How are things in the home identified from outside the homenet? >> > > Maybe I can add some fuel to Olafur's fire. I'd like to say that the > homenet name service MUST be DNS. > > This may sound like heresy, but here's my reason: I want the ability > to transition from a private name space to a public name space with > minimal fuss. I don't want a different naming mechanism that has > its own oddities just because I can't think up a clever domain name > for my home net that goes into the global DNS when I'm forced to > install my router. When I'm finally inspired, I want to be able to make > that transition and then worry about the split horizon implications > (if I even get around to caring about such a thing). > > So perhaps, we can make use of statistically unique naming to keep > things from bumping into one another, etc... this is sort of off the > cuff, > but the real point is not having to transmogrify one naming scheme into > another. Yuck. > > Mike > There are a number of parallels from Homenet to small and large enterprises who declared UDI from the global DNS (and set up their own private root servers) for any number of reasons. Similarly for WINS and mDNS users. So maybe a useful approach would be to ask "what's wrong with DNS today that it can't satisfy all of the requirements mentioned" or "Why did these people declare UDI in the first place?" or "Why did they invent that stuff?" and more to the point "Can it be fixed?" Some of my answers to those questions would be: 1. Availability: Undesirability of fate sharing I don't want my media streamer and other devices like a smoke alarm becoming locally unavailable because I change provider or the Internet link is down for an extended period. 2. Easy roll out and maintenance I can't see Homenet being able to implement DNSSEC today, so we have to be aware of cache poisoning in Homenet and how to address that if DNS is the chosen solution. 3. One single namespace for all destinations.Coexistence with global DNS. Strong desire to integrate into the global DNS naming tree. Single name space, single query type, no two way synchronization of separate name spaces. I make no statement of preference on whether the transport has to be native DNS within the home. 4. Support of Highly Mobile out of the shrinkwrap Changing environments can be especially problematic for highly mobile nodes with flexible tethering, such as iDevices. They should just work in and out of the home, as you move within range of your Homenet wireless. 5. Integrity: Integrated Security We should be aware of security issues with a .local style namespace over whatever transport (your iDevice connecting to my evil .local device posing as a friendly fileserver because you're walking past my open home network). So there would need to be some extra device pairing if a .local namespace is used, or see (5). 6. Independent Local Trust Anchor Strong desire to avoid a heavyweight trust anchor tied into the public DNS. That would be another important point for me if starting from scratch. Perhaps the ability to insert a private trust anchor at some nominal point on the DNS tree that I can use to authenticate between my own devices, other than being limited to a trust anchor derived from the DNS root. I'm pretty sure ISP's won't want to have people phoning their help desks asking about key rotation problems or with how-to questions about key signing keys in Homenet. 7. Integrated Low Power Version Ability for low power devices to sleep for extended periods built in from the get go (naming gateway? naming proxy responder?) 8. Confidentiality: Name space hiding Ability to "hide" a portion of the name space to discourage scanning. regards, RayH From dave.taht@gmail.com Fri Jun 29 13:52:43 2012 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 349AD21F84D2 for ; Fri, 29 Jun 2012 13:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJv3FUOzJvAB for ; Fri, 29 Jun 2012 13:52:41 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41EED21F84A5 for ; Fri, 29 Jun 2012 13:52:41 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2357403wgb.13 for ; Fri, 29 Jun 2012 13:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HABSF1ZnDrNJbQP4uhCznd00yHKxoqYh8z3SO+uL3IU=; b=PnbMvC6wXeLCm55Au1uO7aHM2cFWeIBTH3uItoJO9nsYeZn4ufWebX2V9VovG2XF5a 8XYTzXJ4n/WLcWgcI8Or7/poacZjIHFNl4uVjbsdGWiFa2tkVQ+zFoZw43OvnvCrNtGC GvnSvmTksIUU6Amqe2GTCRXrk0aXAIxhE+4ZILK9gjIq3UunMRG47Q7iUwToz5Eo58we ANtjEGwEvVQlYW2el9qgA0NylYFloAjd4FPEkMetGY01qLqegZOjWJzv09H2iUvPL/dQ AqubCa8gEFWuQjwdaeq4f+kMMZdlXQIfIs0l6U9MLHyixtgtoniZXIDkIK6sI+wohrdK aLDQ== MIME-Version: 1.0 Received: by 10.216.198.14 with SMTP id u14mr1509536wen.12.1341003160148; Fri, 29 Jun 2012 13:52:40 -0700 (PDT) Received: by 10.223.103.199 with HTTP; Fri, 29 Jun 2012 13:52:40 -0700 (PDT) In-Reply-To: <4FEE1057.1030005@globis.net> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <4FEE1057.1030005@globis.net> Date: Fri, 29 Jun 2012 13:52:40 -0700 Message-ID: From: Dave Taht To: Ray Hunter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:52:43 -0000 On Fri, Jun 29, 2012 at 1:30 PM, Ray Hunter wrote: > Michael Thomas wrote: >> >> On 06/29/2012 08:34 AM, Ralph Droms wrote: >>> >>> >>> a) Homenet name-service MUST NOT interfere with Internet name-service >>> "Internet name-service"? =A0Do you mean "DNS"? =A0"Co-exist" might be a >>> better word. =A0Users want a single interface into naming and don't >>> want to have to differentiate between "naming stuff on my local network= " >>> and "naming stuff in the Internet". =A0Ted Lemon raised this issue much >>> more eloquently during the WG meeting. >>> >>> I'll add my first bullet here, rephrased a little: >>> >>> a.1) Relative name resolution: some naming convention that allows name >>> resolution while mitigating the need to know an absolute location in th= e >>> Internet name-service >>> >>>> b) Homenet name-service MUST NOT be in Internet name space. >>> >>> How are things in the home identified from outside the homenet? >>> >> >> Maybe I can add some fuel to Olafur's fire. I'd like to say that the >> homenet name service MUST be DNS. >> >> This may sound like heresy, but here's my reason: I want the ability >> to transition from a private name space to a public name space with >> minimal fuss. I don't want a different naming mechanism that has >> its own oddities just because I can't think up a clever domain name >> for my home net that goes into the global DNS when I'm forced to >> install my router. When I'm finally inspired, I want to be able to make >> that transition and then worry about the split horizon implications >> (if I even get around to caring about such a thing). >> >> So perhaps, we can make use of statistically unique naming to keep >> things from bumping into one another, etc... this is sort of off the cuf= f, >> but the real point is not having to transmogrify one naming scheme into >> another. Yuck. >> >> Mike >> > There are a number of parallels from Homenet to small and large enterpris= es > who declared UDI from the global DNS (and set up their own private root > servers) for any number of reasons. Similarly for WINS and mDNS users. > > So maybe a useful approach would be to ask "what's wrong with DNS today t= hat > it can't satisfy all of the requirements mentioned" or "Why did these peo= ple > declare UDI in the first place?" or "Why did they invent that stuff?" and > more to the point "Can it be fixed?" > > Some of my answers to those questions would be: > > 1. Availability: Undesirability of fate sharing > > I don't want my media streamer and other devices like a smoke alarm becom= ing > locally unavailable because I change provider or the Internet link is dow= n > for an extended period. You shouldn't outsource your dns to your provider but be running a local cache and authorative server. As for the link being down for an extended period, that is something of a problem in the general case. I'd harden this requirement to your network should be able to boot and run independently of the internet being available or not. This is certainly the case with mdns, not so much with dns. > > 2. Easy roll out and maintenance > > I can't see Homenet being able to implement DNSSEC today, so we have to b= e > aware of cache poisoning in Homenet and how to address that if DNS is the > chosen solution. I'm puzzled. cerowrt and iscwrt have had dnssec for a year now... while bind is the most heavyweight daemon in the mix (about 10MB just to start, about 20MB with a full cache), it's certainly possible to run dnssec on your typical consumer router, and seems possible to add DNSSEC to something more lightweight like dnsmasq. At least a few applications implement dnssec too, there's a plugin for firefox that I know of. > > 3. One single namespace for all destinations.Coexistence with global DNS. > > Strong desire to integrate into the global DNS naming tree. Single name > space, single query type, no two way synchronization of separate name > spaces. I make no statement of preference on whether the transport has to= be > native DNS within the home. This sort of conflicts with 8 below. > 4. Support of Highly Mobile out of the shrinkwrap > > Changing environments can be especially problematic for highly mobile nod= es > with flexible tethering, such as iDevices. They should just work in and o= ut > of the home, as you move within range of your Homenet wireless. Hard problem that crosses not just dns, but applications, the network stack and cryptography. The app that I love that implements this functionality fairly well is mosh, and even then it only works presently on ipv4 and that with public ip addresses. > 5. Integrity: Integrated Security > > We should be aware of security issues with a .local style namespace over > whatever transport (your iDevice connecting to my evil .local device posi= ng > as a friendly fileserver because you're walking past my open home network= ). > So there would need to be some extra device pairing if a .local namespace= is > used, or see (5). Drive by wifi exists independently of the .local convention. It's a network, not naming problem. > 6. Independent Local Trust Anchor > > Strong desire to avoid a heavyweight trust anchor tied into the public DN= S. > That would be another important point for me if starting from scratch. > Perhaps the ability to insert a private trust anchor at some nominal poin= t > on the DNS tree that I can use to authenticate between my own devices, ot= her > than being limited to a trust anchor derived from the DNS root. I'm prett= y > sure ISP's won't want to have people phoning their help desks asking abou= t > key rotation problems or with how-to questions about key signing keys in > Homenet. Having a decent trust anchor to start with with any system would be good. One of my own issues is that the cert system is so broke that the most secure certs are the ones you generate yourself, but those throw an error in your browser by default. > 7. Integrated Low Power Version > > Ability for low power devices to sleep for extended periods built in from > the get go (naming gateway? naming proxy responder?) > > 8. Confidentiality: Name space hiding > > Ability to "hide" a portion of the name space to discourage scanning. > regards, > RayH > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!" From mike@mtcc.com Fri Jun 29 13:57:18 2012 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 9517611E8085 for ; Fri, 29 Jun 2012 13:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFy0CiGXC2B9 for ; Fri, 29 Jun 2012 13:57:17 -0700 (PDT) Received: from mtcc.com (mtcc.com [50.0.18.224]) by ietfa.amsl.com (Postfix) with ESMTP id 848AC11E8086 for ; Fri, 29 Jun 2012 13:57:17 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q5TKvFLw028549 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 29 Jun 2012 13:57:15 -0700 Message-ID: <4FEE16AB.5040309@mtcc.com> Date: Fri, 29 Jun 2012 13:57:15 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: james woodyatt References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1364; t=1341003436; x=1341867436; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[homenet]=20Name=20service=20design=20p rinciples=3A=20a=20proposal |Sender:=20 |To:=20james=20woodyatt=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=vM7FM25y5U0cLgIK9pwrYHUtjVO+rn89r1xbCckJWJE=; b=mNsv++HiZKPwL4RC6TbqdoB5nJgANl7Od9P4+/79zNaFSuArUc4O2TUkzW PQcBwSXB7/gYuyAUZIKitQemH88mRfyLzGfircJMMekJvsyi56siKNEBVFC1 2d8YuSSIUSiwKTH8BIndCWcohLOuj5oJlOqCmfto7PEHNLQcrqmaY=; Authentication-Results: mtcc.com; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: "homenet@ietf.org Group" Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:57:18 -0000 On 06/29/2012 12:58 PM, james woodyatt wrote: > On Jun 29, 2012, at 11:27 , Michael Thomas wrote: >> Maybe I can add some fuel to Olafur's fire. I'd like to say that the homenet name service MUST be DNS. > Let's go further. Let's say that it must be DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for 199 days at this point, so one imagines that it stands a decent chance of being a published RFC by the time HOMENET finishes its first round of major work. > > James -- I'm not that familiar with dns-sd and it's been 1000 years since i've thought about nbp, but services aren't the only thing I have in my home. Or at least I wouldn't necessarily think of some things grouped together as named services like, oh say, my light switches. Maybe I'd want to think of them that way, but maybe I wouldn't. So I'm not sure that I'd be comfortable saying that it's a particular flavor of DNS like DNS-sd. That, and I can't tell whether this makes it easier, harder or neutral on my original request that making the transition from a private name space to a public one trivial. Can I use service discovery from across the Internet to get back to things in my home assuming that I have a registered domain? Sorry for the ignorance, but nbp was a decidedly localized protocol. Mike From touch@isi.edu Fri Jun 29 14:10:41 2012 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 2F2C221F875E for ; Fri, 29 Jun 2012 14:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.585 X-Spam-Level: X-Spam-Status: No, score=-105.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdZdeM-LgRJc for ; Fri, 29 Jun 2012 14:10:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5349821F875D for ; Fri, 29 Jun 2012 14:10:40 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TL9vJt011664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 14:09:57 -0700 (PDT) Message-ID: <4FEE19A5.1020503@isi.edu> Date: Fri, 29 Jun 2012 14:09:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Ralph Droms References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <7EFFABA0-F840-4A86-AECF-1D2C2B10B217@gmail.com> In-Reply-To: <7EFFABA0-F840-4A86-AECF-1D2C2B10B217@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:10:41 -0000 On 6/29/2012 1:09 PM, Ralph Droms wrote: > > On Jun 29, 2012, at 3:58 PM 6/29/12, james woodyatt wrote: > >> On Jun 29, 2012, at 11:27 , Michael Thomas wrote: >>> >>> Maybe I can add some fuel to Olafur's fire. I'd like to say that the homenet name service MUST be DNS. >> >> Let's go further. Let's say that it must be DNS-Based Service Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for 199 days at this point, so one imagines that it stands a decent chance of being a published RFC by the time HOMENET finishes its first round of major work. > > Well, DNS-Based Service Discovery addresses just one kind of requirement: listing entities that provide a certain kind of service; perhaps generalizable to resolution based on a characteristic or set of characteristics that might return more than one response to the resolution request. At some point, there needs to be a mechanism for resolving an identity to a single IP address. Why? if the DNS gives multiple answers, they're intended to be equivalent for that service. Joe From touch@isi.edu Fri Jun 29 14:11:33 2012 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 2905C21F87EA for ; Fri, 29 Jun 2012 14:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.629 X-Spam-Level: X-Spam-Status: No, score=-105.629 tagged_above=-999 required=5 tests=[AWL=0.970, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUkgDxCXNTNs for ; Fri, 29 Jun 2012 14:11:32 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 35C4C21F875D for ; Fri, 29 Jun 2012 14:11:32 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q5TLAmQx011717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 Jun 2012 14:10:48 -0700 (PDT) Message-ID: <4FEE19D8.6010202@isi.edu> Date: Fri, 29 Jun 2012 14:10:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Benjamin Kerensa References: <4FEDC46C.8070205@ogud.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: homenet@ietf.org, Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:11:33 -0000 Hi, all, Not a bad list - but I wonder why it applies to Homenet, and not the Internet in general? Is there anything here that's homenet-specific? Either way, it'd be useful to be clear about that... Joe On 6/29/2012 10:48 AM, Benjamin Kerensa wrote: > > > On Fri, Jun 29, 2012 at 8:06 AM, Olafur Gudmundsson > wrote: > > After the Homenet meeting in Paris I realized that the group needs > good principles for its name-space work. The principles in -arch-02 are > a good start but IMHO not sufficient. > It makes not sense to be proposing/evaluating solutions when there > are no agreed upon principles/requirements. > > The chairs have been bugging me to follow up with a contribution. > Below is my attempt at defining as compactly/broadly as > possible design principles for Name services: > > a) Homenet name-service MUST NOT interfere with Internet name-service > > b) Homenet name-service MUST NOT be in Internet name space. > > e) Homenet name-service MUST function throughout the whole "site" > > c) Homenet name-service SHOULD support both lookups and discovery > > d) Homenet name-service SHOULD be considerate of bandwidth usage > > e) Homenet name-service MUST allow segmentation of "name space" for > different classes/groups/cliques of applications/devices > > g) Homenet name-service SHOULD allow both broadcast service as well as > more traditional lookup service. > > I'm expecting a lively discussion on this topic :-) > > Olafur > _________________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/__listinfo/homenet > > > > > I think the above design principles seem pretty precise and common sense > I guess my only question is in the case of segmentation of "name space" > for various classes is there going to be limitations to the segmentation > or policies surrounding cases where segmentation occurs in the "name space". > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > From rdroms.ietf@gmail.com Fri Jun 29 14:12:04 2012 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 E13C911E80BE for ; Fri, 29 Jun 2012 14:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqLAxZFmKjCV for ; Fri, 29 Jun 2012 14:12:03 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id F2BE611E80A6 for ; Fri, 29 Jun 2012 14:12:02 -0700 (PDT) Received: by qadz3 with SMTP id z3so918168qad.10 for ; Fri, 29 Jun 2012 14:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5M/d6TWEtLwn+N3fiWpjsIZ/wALyyQRwppldBMw+7MY=; b=wutGFrRObhXPuXL8OiojPan4Y+mUfuzqLwSEsVH1uEgH2Drjd8f/9XNHlGOssrxd8E 1yycUykFTqvit8pKrAb/On2olhFSTA0dkuqocrL5wuUOnde0C0H0P1eR/dxHZqf9e6wz FCsOo4wmZXMLieo5rNy8U3WAU3ppZbybrsaaY/YGH2TXqOXKVPvE9oKK7m3JrNo25+ei ZatPaTGmCOCvaU75L3y4HmFc5EgSf6axecz4zS7GPuW7VdOP5oF+4F6cktB6ctj7W0GP ULoW2JuHgedsH8wP6OK///WVf9xj8KuK/pI0100pa6N5hlsTLw6X1PbdgWUS0wnd/aW2 QBJg== Received: by 10.229.135.199 with SMTP id o7mr1771011qct.0.1341004322430; Fri, 29 Jun 2012 14:12:02 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id n2sm12650020qap.10.2012.06.29.14.12.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 14:12:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: <4FEE19A5.1020503@isi.edu> Date: Fri, 29 Jun 2012 17:11:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2156C3C7-C335-4996-8A86-B1321271948D@gmail.com> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <7EFFABA0-F840-4A86-AECF-1D2C2B10B217@gmail.com> <4FEE19A5.1020503@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1278) Cc: "homenet@ietf.org Group" , Ralph Droms , james woodyatt Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:12:04 -0000 On Jun 29, 2012, at 5:09 PM 6/29/12, Joe Touch wrote: >=20 >=20 > On 6/29/2012 1:09 PM, Ralph Droms wrote: >>=20 >> On Jun 29, 2012, at 3:58 PM 6/29/12, james woodyatt wrote: >>=20 >>> On Jun 29, 2012, at 11:27 , Michael Thomas wrote: >>>>=20 >>>> Maybe I can add some fuel to Olafur's fire. I'd like to say that = the homenet name service MUST be DNS. >>>=20 >>> Let's go further. Let's say that it must be DNS-Based Service = Discovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor = Queue for 199 days at this point, so one imagines that it stands a = decent chance of being a published RFC by the time HOMENET finishes its = first round of major work. >>=20 >> Well, DNS-Based Service Discovery addresses just one kind of = requirement: listing entities that provide a certain kind of service; = perhaps generalizable to resolution based on a characteristic or set of = characteristics that might return more than one response to the = resolution request. At some point, there needs to be a mechanism for = resolving an identity to a single IP address. >=20 > Why? if the DNS gives multiple answers, they're intended to be = equivalent for that service. Sure...I should have said "resolve an identity to an IP address or = address(es)". - Ralph >=20 > Joe From kerlyn2001@gmail.com Fri Jun 29 14:21:48 2012 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 4E4D611E80AD for ; Fri, 29 Jun 2012 14:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.045 X-Spam-Level: X-Spam-Status: No, score=-101.045 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VV1LiaJ5C6Ub for ; Fri, 29 Jun 2012 14:21:47 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5512A11E80A0 for ; Fri, 29 Jun 2012 14:21:47 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5225566pbc.31 for ; Fri, 29 Jun 2012 14:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=j+V8bVy4dLjW9GGyvc/E3DdXM85XFEcofuL5+DrEdJI=; b=sUT54M5DEkAd70ejS4Mc9cEDx2gHvA9lodThX77CmFfAZBhFdFNQ9FFJfUePaSwkMR fPqnScKJlg2EhKGbgoHAvpXE1xpsoVZbm62oviHhVg3dKCd403+ZDUTBTApx8b2OkDSh iIQvUKcf6k5m5Eu6S8Nxu0IbbbpXoaKd30k+rBC2Ar1+8UVuJu/Jd3bjHW6/f6xq2I2I FaQQqdWxrIOstzabG6SpRIrxbJ6QfMYVmVxRZVYiKK4xyPezOUAiH2B2SCHg2gfgHpIi c2OU1KdTFtJJvzWY/SmNRsB5B3nxT4XKHNmFVO2ImYLh5UTuSQm0xlLXROtp0tV1EP6c 5wmw== MIME-Version: 1.0 Received: by 10.68.195.167 with SMTP id if7mr10670785pbc.16.1341004907146; Fri, 29 Jun 2012 14:21:47 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.142.47.11 with HTTP; Fri, 29 Jun 2012 14:21:46 -0700 (PDT) In-Reply-To: <4FEE16AB.5040309@mtcc.com> References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <4FEE16AB.5040309@mtcc.com> Date: Fri, 29 Jun 2012 17:21:46 -0400 X-Google-Sender-Auth: NFAgTOG0t69Du7IggB7YUG9wsnM Message-ID: From: Kerry Lynn To: Michael Thomas Content-Type: multipart/alternative; boundary=047d7b10ce6321ed5d04c3a3098c Cc: "homenet@ietf.org Group" , james woodyatt Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 21:21:48 -0000 --047d7b10ce6321ed5d04c3a3098c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jun 29, 2012 at 4:57 PM, Michael Thomas wrote: > On 06/29/2012 12:58 PM, james woodyatt wrote: > >> On Jun 29, 2012, at 11:27 , Michael Thomas wrote: >> >>> Maybe I can add some fuel to Olafur's fire. I'd like to say that the >>> homenet name service MUST be DNS. >>> >> Let's go further. Let's say that it must be DNS-Based Service Discovery >> [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queue for >> 199 days at this point, so one imagines that it stands a decent chance of >> being a published RFC by the time HOMENET finishes its first round of major >> work. >> >> >> > James -- I'm not that familiar with dns-sd and it's been 1000 years since > i've > Well, you're in luck. There's an O'Reilly book called "Zero Configuration Networking" that explains all... > thought about nbp, but services aren't the only thing I have in my home. Or > at least I wouldn't necessarily think of some things grouped together as > named > services like, oh say, my light switches. Maybe I'd want to think of them > that > way, but maybe I wouldn't. So I'm not sure that I'd be comfortable saying > that > it's a particular flavor of DNS like DNS-sd. > > Here's a short list of services that are already defined: http://www.dns-sd.org/ServiceTypes.html I will shortly be refreshing http://tools.ietf.org/html/draft-lynn-core-discovery-mapping/ to describe a way to use mDNS/DNS-SD to discover REST web service interfaces within a device. So if you think of your light switches in that way, you're covered. > That, and I can't tell whether this makes it easier, harder or neutral on > my > original request that making the transition from a private name space to a > public one trivial. Can I use service discovery from across the Internet > to get > back to things in my home assuming that I have a registered domain? Sorry > for the ignorance, but nbp was a decidedly localized protocol. > > I can point you to http://tools.ietf.org/html/draft-cheshire-dnsext-nbpfor historical background, but best to just read up on DNS-SD. As far as transitioning from private to public domains, that's where resolve.conf helps. Also, see http://dyn.com/support/bonjour-and-dns-discovery/ -K- Mike > > ______________________________**_________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/**listinfo/homenet > --047d7b10ce6321ed5d04c3a3098c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Jun 29, 2012 at 4:57 PM, Michael Thomas <mike@mtcc.com> = wrote:
On 06/29/2012 12:58 PM, james woodyatt wrote:
On Jun 29, 2012, at 11:27 , Michael Thomas <mike@mtcc.com> wrote:
Maybe I can add some fuel to Olafur's fire. I'd like to say that th= e homenet name service MUST be DNS.
Let's go further. =A0Let's say that it must be DNS-Based Service Di= scovery [I-D.cheshire-dnsext-dns-sd], which has been in the RFC Editor Queu= e for 199 days at this point, so one imagines that it stands a decent chanc= e of being a published RFC by the time HOMENET finishes its first round of = major work.



James -- I'm not that familiar with dns-sd and it's been 1000 years= since i've

Well, you're in luc= k. =A0There's an O'Reilly book called "Zero Configuration
Networking" that explains all...
=A0
thought about nbp, but services aren't the only thing I have in my home= . Or
at least I wouldn't necessarily think of some things grouped together a= s named
services like, oh say, my light switches. Maybe I'd want to think of th= em that
way, but maybe I wouldn't. So I'm not sure =A0that I'd be comfo= rtable saying that
it's a particular flavor of DNS like DNS-sd.

Here's a short list of services that are already = defined:

to describe a way to use mDNS/DNS-SD to discover REST web service
interfaces within a device. =A0So if you think of your light switches= in that way,
you're covered.
=A0
That, and I can't tell whether this makes it easier, harder or neutral = on my
original request that making the transition from a private name space to a<= br> public one trivial. Can I use service discovery from across the Internet to= get
back to things in my home assuming that I have a registered domain? Sorry for the ignorance, but nbp was a decidedly localized protocol.

background, but best to just read up = on DNS-SD. =A0As far as transitioning from
private to public domains, that's where resolve.conf helps. =A0Als= o, see

-K-

Mike

_______________________________________________
homenet mailing list
homenet@ietf.org<= br> https://www.ietf.org/mailman/listinfo/homenet

--047d7b10ce6321ed5d04c3a3098c-- From jhw@apple.com Fri Jun 29 15:07:48 2012 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 5524F21F8565 for ; Fri, 29 Jun 2012 15:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIP8nhuG9Q3n for ; Fri, 29 Jun 2012 15:07:47 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA7ED21F853F for ; Fri, 29 Jun 2012 15:07:47 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M6E00BUVG3XVAN2@mail-out.apple.com> for homenet@ietf.org; Fri, 29 Jun 2012 15:07:30 -0700 (PDT) X-AuditID: 11807112-b7f826d000004103-66-4fee2721c123 Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 4F.C5.16643.1272EEF4; Fri, 29 Jun 2012 15:07:29 -0700 (PDT) From: james woodyatt In-reply-to: <4FEE16AB.5040309@mtcc.com> Date: Fri, 29 Jun 2012 15:07:29 -0700 Message-id: References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <4FEE16AB.5040309@mtcc.com> To: "homenet@ietf.org Group" X-Mailer: Apple Mail (2.1482) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42IRPMjroKuo/s7f4OUTK4v3iw6xODB6LFny kymAMYrLJiU1J7MstUjfLoEro3PWH7aCCfwV3+9vZmlgbOHpYuTkkBAwkbiz5wgLhC0mceHe erYuRi4OIYHZTBJPHv1jBkkwC2hJ3Pj3kgnE5hXQk7i3/QaYLSzgKLHlzTc2EJtNQEXi2+W7 YHFOAQ2Jo3tnsIPYLAKqEit2TWCHmKMtsWzha2aIOTYS+16uZodYdpBRor/1DytIQkRAX+Lp kV9sEBfJSvzevpxlAiPfLCR3zEJyxywkcxcwMq9iFCxKzUmsNDTXSywoyEnVS87P3cQICqaG QqEdjPd36R1iFOBgVOLh3XT1rb8Qa2JZcWXuIUYJDmYlEd6Hi4FCvCmJlVWpRfnxRaU5qcWH GKU5WJTEef9XvPYXEkhPLEnNTk0tSC2CyTJxcEo1MEqxyKgWbPw8l/2CWNEvtUz70/Nvrrdz s9jKojNV0uH6Bf4/Iv0e4RNWGMt9rBLuyTYw87YP1p4Qbvri7N0pXS8CJi4UaXK5vv/0mZyP iT6dlq8znl4L+n/190Keuh+pM7snbDMw7OIz13m49E+9cm2hj2jm00l/m+aa14o8Tr8fd51Z Y1IMtxJLcUaioRZzUXEiAGyrB7AiAgAA Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 22:07:48 -0000 On Jun 29, 2012, at 13:57 , Michael Thomas wrote: > > Can I use service discovery from across the Internet to get back to things in my home assuming that I have a registered domain? Last login: Fri Jun 29 14:52:05 on ttys000 zephyr ~ 501$ ssh -p 22 jhw@zeece.303183.members.btmm.icloud.com. Last login: Fri Jun 29 14:55:24 2012 from fd3a:a6fe:48b6:8b35:c1aa:9b69:17ce:fb01 zeece ~ 501$ I could post pictures of what it looks like when I go to configure my Time Capsule at home remotely from my desk in Cupertino, but that would be a waste of valuable IETF remailer resources. Suffice to say it works like this: p1. Launch the AirPort Utility (which is used for configuring Time Capsule). p2. Click on "Other Base Stations" button in the upper right of the main window. p3. Choose "James's Home Time Capsule" from the pop-up menu. p4. A configuration window opens. Make changes. Click "Save" and the window closes. Step p2 above starts the browse for AirPort and Time Capsule configuration services in the list of domains my system is automatically configured to search, which includes my iCloud member domain, but it could include any other domains. The browse operation queries for PTR records containing names of SRV records, and it results in the list presented in the pop-up menu. Step p3 above starts the locate for the chosen Time Capsule service instance. The locate operation queries for SRV records, as well as the A and/or AAAA records corresponding to the hostname part of the service resources. Step p4 above starts parallel TCP connections to one or more of the destination addresses returned by the locate operation, in a sensible order and possibly in parallel, until one of them connects or they all fail. -- james woodyatt member of technical staff, core os networking From brian.e.carpenter@gmail.com Sat Jun 30 00:08:25 2012 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 B3B3621F8599 for ; Sat, 30 Jun 2012 00:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.988 X-Spam-Level: X-Spam-Status: No, score=-100.988 tagged_above=-999 required=5 tests=[AWL=0.703, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plimMzour36Y for ; Sat, 30 Jun 2012 00:08:24 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7995221F854A for ; Sat, 30 Jun 2012 00:08:24 -0700 (PDT) Received: by eekd4 with SMTP id d4so1781058eek.31 for ; Sat, 30 Jun 2012 00:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3UAnanKVTfs+N496a8e9eB056qPmLHiW/BKPHDAb7iA=; b=lppvVCdOqGgVwUozfYv8D5uU8DUGbU0JZGtsPjMVlgPzkgAEO9xdLVij/pdxqRsG5p G/0nkYgj7x87yYTfU/VNZvup7qh2SibTAH4NdXSILLk/sJ+f5hA1fnsmiCMievngfKLE TQSFXZIi1fctO0m12zbuv6ZEiUYWi3mp+/4kqnUPNfEadlb0GR4egs1+sMmTgQi5uleV lLTFdS/BJbEKtv3hqQaseXPPNJ75DkIfFpTNbbiZAG15k0H3K0L3+kfUr8KjXHuHDMhN wmcFnZ7yzSnbnvGyd1X+O7v4UXQQSdxhy5UBtoqqje1YqRUBQZEoNnCIz1MZYh3wU3iJ S8Ug== Received: by 10.14.99.202 with SMTP id x50mr1282715eef.19.1341040103489; Sat, 30 Jun 2012 00:08:23 -0700 (PDT) Received: from [192.168.1.66] (host-2-102-219-139.as13285.net. [2.102.219.139]) by mx.google.com with ESMTPS id x52sm14561785eea.11.2012.06.30.00.08.21 (version=SSLv3 cipher=OTHER); Sat, 30 Jun 2012 00:08:22 -0700 (PDT) Message-ID: <4FEEA5DF.5060002@gmail.com> Date: Sat, 30 Jun 2012 08:08:15 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Olafur Gudmundsson References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF1B6.30401@ogud.com> In-Reply-To: <4FEDF1B6.30401@ogud.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Ralph Droms Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 07:08:25 -0000 On 2012-06-29 19:19, Olafur Gudmundsson wrote: ... >>> b) Homenet name-service MUST NOT be in Internet name space. >> >> How are things in the home identified from outside the homenet? > > They will have to have two names one internal and one externally visible. Exactly. This has been standard practice in enterprise networks using standard DNS software for years, and is exactly analogous to ULAs and globally-routeable GUAs. The internal name should IMHO be syntactically identical to an FQDN but will not resolve off-site. This does not need to break the hierarchical purity of the DNS name space, just as ULAs do not break the IPv6 address hierarchy. (By contrast, RFC 1918 and .local do break their respective hierarchies.) On 2012-06-29 20:18, Michael Thomas wrote: > On 06/29/2012 11:53 AM, Don Sturek wrote: >> Hi Michael, >> >> The difficulty with your proposal is that the homenet address space is now >> connected to the wider internet. > > It wasn't a proposal of a solution, so much as plea to not make my > life more difficult trying to keep track of the difference between > "in" and "out" naming systems. We've done a pretty good job of > teaching the world about fqdn's to the point that seeing unqualified > names makes me wonder what they are and whether they even refer > to anything Internet-like. And of course, I want to have a flip of > the switch if I decide to make them Internet-wide visible. +1 Brian From v6ops@globis.net Sat Jun 30 02:22:12 2012 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 6244021F8681 for ; Sat, 30 Jun 2012 02:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.403 X-Spam-Level: ** X-Spam-Status: No, score=2.403 tagged_above=-999 required=5 tests=[AWL=5.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yarcpN9EY0Qk for ; Sat, 30 Jun 2012 02:22:10 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id BD71C21F866A for ; Sat, 30 Jun 2012 02:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id B6FB98701FC; Sat, 30 Jun 2012 11:22:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17Q3S2Xh6C-s; Sat, 30 Jun 2012 11:22:02 +0200 (CEST) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id C04318701FB; Sat, 30 Jun 2012 11:22:02 +0200 (CEST) Message-ID: <4FEEC539.4040209@globis.net> Date: Sat, 30 Jun 2012 11:22:01 +0200 From: Ray Hunter User-Agent: Postbox 3.0.4 (Macintosh/20120616) MIME-Version: 1.0 To: Dave Taht References: <4FEDC46C.8070205@ogud.com> <07C6F7FE-8115-4B8E-867B-B92EB9932154@gmail.com> <4FEDF39D.8060909@mtcc.com> <4FEE1057.1030005@globis.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: homenet@ietf.org, Michael Thomas , Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 09:22:12 -0000 Thanks for the reply. See inline. > Dave Taht > 29 June 2012 22:52 > On Fri, Jun 29, 2012 at 1:30 PM, Ray Hunter wrote: >> Michael Thomas wrote: >>> On 06/29/2012 08:34 AM, Ralph Droms wrote: >>>> a) Homenet name-service MUST NOT interfere with Internet name-service >>>> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >>>> better word. Users want a single interface into naming and don't >>>> want to have to differentiate between "naming stuff on my local network" >>>> and "naming stuff in the Internet". Ted Lemon raised this issue much >>>> more eloquently during the WG meeting. >>>> >>>> I'll add my first bullet here, rephrased a little: >>>> >>>> a.1) Relative name resolution: some naming convention that allows name >>>> resolution while mitigating the need to know an absolute location in the >>>> Internet name-service >>>> >>>>> b) Homenet name-service MUST NOT be in Internet name space. >>>> How are things in the home identified from outside the homenet? >>>> >>> Maybe I can add some fuel to Olafur's fire. I'd like to say that the >>> homenet name service MUST be DNS. >>> >>> This may sound like heresy, but here's my reason: I want the ability >>> to transition from a private name space to a public name space with >>> minimal fuss. I don't want a different naming mechanism that has >>> its own oddities just because I can't think up a clever domain name >>> for my home net that goes into the global DNS when I'm forced to >>> install my router. When I'm finally inspired, I want to be able to make >>> that transition and then worry about the split horizon implications >>> (if I even get around to caring about such a thing). >>> >>> So perhaps, we can make use of statistically unique naming to keep >>> things from bumping into one another, etc... this is sort of off the cuff, >>> but the real point is not having to transmogrify one naming scheme into >>> another. Yuck. >>> >>> Mike >>> >> There are a number of parallels from Homenet to small and large enterprises >> who declared UDI from the global DNS (and set up their own private root >> servers) for any number of reasons. Similarly for WINS and mDNS users. >> >> So maybe a useful approach would be to ask "what's wrong with DNS today that >> it can't satisfy all of the requirements mentioned" or "Why did these people >> declare UDI in the first place?" or "Why did they invent that stuff?" and >> more to the point "Can it be fixed?" >> >> Some of my answers to those questions would be: >> >> 1. Availability: Undesirability of fate sharing >> >> I don't want my media streamer and other devices like a smoke alarm becoming >> locally unavailable because I change provider or the Internet link is down >> for an extended period. > > You shouldn't outsource your dns to your provider but be running a > local cache and authorative server. hmm. Ok in corporates. But SME & Homenet? > > As for the link being down for an extended period, that is something > of a problem in the general case. I'd harden this requirement to your > network should be able to boot and run independently of the internet > being available or not. This is certainly the case with mdns, not so > much with dns. Good point. Should be capable of working stand alone, or co-existent with global DNS. Perhaps I'm being naive, but I see no fundamental reason why the same zone file can't be mounted at two points on the DNS tree. Once for a .homenet. root (for local resolution independent of the global internet) and once for a globally derived root (for resolution from outside of Homenet). Resolvers would have two defaults in their search list, first .homenet space and then one for global name space. Isn't that better than trying to run/export/import/synch 2 completely independent name resolution protocols? >> 2. Easy roll out and maintenance >> >> I can't see Homenet being able to implement DNSSEC today, so we have to be >> aware of cache poisoning in Homenet and how to address that if DNS is the >> chosen solution. > > I'm puzzled. cerowrt and iscwrt have had dnssec for a year now... > while bind is the most heavyweight > daemon in the mix (about 10MB just to start, about 20MB with a full > cache), it's certainly possible to run dnssec on your typical consumer > router, and seems possible to add DNSSEC to something more lightweight > like dnsmasq. At least a few applications implement dnssec too, > there's a plugin for firefox > that I know of. Perhaps try explaining to your mom what she needs to do for best-practice zone management, and how to update key signing keys etc. when changing providers ? > >> 3. One single namespace for all destinations.Coexistence with global DNS. >> >> Strong desire to integrate into the global DNS naming tree. Single name >> space, single query type, no two way synchronization of separate name >> spaces. I make no statement of preference on whether the transport has to be >> native DNS within the home. > > This sort of conflicts with 8 below. Yes. These requirements are not always consistent. Perhaps that's why we have so many name resolution protocols. >> 4. Support of Highly Mobile out of the shrinkwrap >> >> Changing environments can be especially problematic for highly mobile nodes >> with flexible tethering, such as iDevices. They should just work in and out >> of the home, as you move within range of your Homenet wireless. > > Hard problem that crosses not just dns, but applications, the network > stack and cryptography. The app that I love that implements this > functionality fairly well is mosh, and even then it only works > presently on ipv4 and that with public ip addresses. True. But it's what consumers expect. >> 5. Integrity: Integrated Security >> >> We should be aware of security issues with a .local style namespace over >> whatever transport (your iDevice connecting to my evil .local device posing >> as a friendly fileserver because you're walking past my open home network). >> So there would need to be some extra device pairing if a .local namespace is >> used, or see (5). > > Drive by wifi exists independently of the .local convention. It's a > network, not naming > problem. Maybe we can agree that caching of a .local style namespace that is not uniquely globally identifiable is problematic (for highly mobile nodes) and needs to be addressed. >> 6. Independent Local Trust Anchor >> >> Strong desire to avoid a heavyweight trust anchor tied into the public DNS. >> That would be another important point for me if starting from scratch. >> Perhaps the ability to insert a private trust anchor at some nominal point >> on the DNS tree that I can use to authenticate between my own devices, other >> than being limited to a trust anchor derived from the DNS root. I'm pretty >> sure ISP's won't want to have people phoning their help desks asking about >> key rotation problems or with how-to questions about key signing keys in >> Homenet. > > Having a decent trust anchor to start with with any system would be > good. One of my own issues is that the cert system is so broke that > the most secure certs are the ones you generate yourself, but those > throw an error in your browser by default. I presume you're more than marginally acquainted with Active Directory. >> 7. Integrated Low Power Version >> >> Ability for low power devices to sleep for extended periods built in from >> the get go (naming gateway? naming proxy responder?) >> >> 8. Confidentiality: Name space hiding >> >> Ability to "hide" a portion of the name space to discourage scanning. > > >> regards, >> RayH > > > >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > > > > Ray Hunter > 29 June 2012 22:30 > > There are a number of parallels from Homenet to small and large > enterprises who declared UDI from the global DNS (and set up their own > private root servers) for any number of reasons. Similarly for WINS > and mDNS users. > > So maybe a useful approach would be to ask "what's wrong with DNS > today that it can't satisfy all of the requirements mentioned" or "Why > did these people declare UDI in the first place?" or "Why did they > invent that stuff?" and more to the point "Can it be fixed?" > > Some of my answers to those questions would be: > > 1. Availability: Undesirability of fate sharing > > I don't want my media streamer and other devices like a smoke alarm > becoming locally unavailable because I change provider or the Internet > link is down for an extended period. > > 2. Easy roll out and maintenance > > I can't see Homenet being able to implement DNSSEC today, so we have > to be aware of cache poisoning in Homenet and how to address that if > DNS is the chosen solution. > > 3. One single namespace for all destinations.Coexistence with global DNS. > > Strong desire to integrate into the global DNS naming tree. Single > name space, single query type, no two way synchronization of separate > name spaces. I make no statement of preference on whether the > transport has to be native DNS within the home. > > 4. Support of Highly Mobile out of the shrinkwrap > > Changing environments can be especially problematic for highly mobile > nodes with flexible tethering, such as iDevices. They should just work > in and out of the home, as you move within range of your Homenet > wireless. > > 5. Integrity: Integrated Security > > We should be aware of security issues with a .local style namespace > over whatever transport (your iDevice connecting to my evil .local > device posing as a friendly fileserver because you're walking past my > open home network). So there would need to be some extra device > pairing if a .local namespace is used, or see (5). > > 6. Independent Local Trust Anchor > > Strong desire to avoid a heavyweight trust anchor tied into the public > DNS. That would be another important point for me if starting from > scratch. Perhaps the ability to insert a private trust anchor at some > nominal point on the DNS tree that I can use to authenticate between > my own devices, other than being limited to a trust anchor derived > from the DNS root. I'm pretty sure ISP's won't want to have people > phoning their help desks asking about key rotation problems or with > how-to questions about key signing keys in Homenet. > > 7. Integrated Low Power Version > > Ability for low power devices to sleep for extended periods built in > from the get go (naming gateway? naming proxy responder?) > > 8. Confidentiality: Name space hiding > > Ability to "hide" a portion of the name space to discourage scanning. > > regards, > RayH > ------------------------------------------------------------------------ From curtis@occnc.com Sat Jun 30 19:27:53 2012 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 66E1D21F8491 for ; Sat, 30 Jun 2012 19:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b4efo40ikYo for ; Sat, 30 Jun 2012 19:27:52 -0700 (PDT) Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 37F9021F8449 for ; Sat, 30 Jun 2012 19:27:51 -0700 (PDT) Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q612Rhhm036301; Sat, 30 Jun 2012 19:27:44 -0700 (PDT) (envelope-from curtis@occnc.com) Message-Id: <201207010227.q612Rhhm036301@gateway.ipv6.occnc.com> To: Michael Thomas From: Curtis Villamizar In-reply-to: Your message of "Fri, 29 Jun 2012 11:27:41 PDT." <4FEDF39D.8060909@mtcc.com> Date: Sat, 30 Jun 2012 22:27:43 -0400 Cc: homenet@ietf.org, Ralph Droms , Olafur Gudmundsson Subject: Re: [homenet] Name service design principles: a proposal X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 02:27:53 -0000 In message <4FEDF39D.8060909@mtcc.com> Michael Thomas writes: > On 06/29/2012 08:34 AM, Ralph Droms wrote: > > > > a) Homenet name-service MUST NOT interfere with Internet name-service > > "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a > > better word. Users want a single interface into naming and don't > > want to have to differentiate between "naming stuff on my local network" > > and "naming stuff in the Internet". Ted Lemon raised this issue much > > more eloquently during the WG meeting. > > > > I'll add my first bullet here, rephrased a little: > > > > a.1) Relative name resolution: some naming convention that allows name > > resolution while mitigating the need to know an absolute location in the > > Internet name-service > > > >> b) Homenet name-service MUST NOT be in Internet name space. > > How are things in the home identified from outside the homenet? > > > > Maybe I can add some fuel to Olafur's fire. I'd like to say that the > homenet name service MUST be DNS. +1 > This may sound like heresy, but here's my reason: I want the ability > to transition from a private name space to a public name space with > minimal fuss. I don't want a different naming mechanism that has > its own oddities just because I can't think up a clever domain name > for my home net that goes into the global DNS when I'm forced to > install my router. When I'm finally inspired, I want to be able to make > that transition and then worry about the split horizon implications > (if I even get around to caring about such a thing). > > So perhaps, we can make use of statistically unique naming to keep > things from bumping into one another, etc... this is sort of off the cuff, > but the real point is not having to transmogrify one naming scheme into > another. Yuck. > > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet I'm not sure that some of the respondents later in this thread understand what DNS can do already with no changes. 1. An important domain that is visible to the outside world can also remain available even if the Internet is not available. Local hosts which use DHCP can be told to query a local DNS cache. That DNS cache can be a DNS secondary (or primary) to your enterprise's domain, or a local domain. As a primary, it never expires. As a DNS secondary it can continue to serve DNS queries for the domain when the Internet is unavailable until the zone file expires (typically days). Example: In every well run enterprise today, the local DNS caches are DNS primary or DNS secondary for the local domain. 2. A local domain can be either visible to the Internet or not visible. It is also possible to provide different results locally and to the Internet. You can create a .local domain that can't be reached except by The NS record available to the outside world can point to a different nameserver than the set of nameservers for that same domain that are used internally. This gets annoying for remote users when switching the enterprise VPN on and off, but otherwise it works just fine. [btw- An alternate that avoids the VPN issue is to create site specific subdomains that are not visible to the outside world.] Example: Most enterprises reuse their domain internally, serving up their name resolutions to private addresses, but only provide the name resolution for the hosts with global addresses to the outside world. 3. Devices can already register their own host name to IP address mapping. Dynamic DNS is far from a new concept. A DHCP client can provide its own host name when retrieving an address. The DHCP server can be coupled to a DNS cache which adds the forward (and optionally reverse) DNS mappings to the appropriate zones until the DHCP lease expires. Example: ISC dhcpd and ISC bind can be coupled in this way. [Not intended as an endorsement. No doubt many others can as well.] Others have suggested DNSSEC. That may conflict with the zero configuration goal unless a trust anchor is supplied at shipment time. Zero configuration and the existing cert hierarchy seem to me to be conflicting goals, but I'd be open to being told otherwise. The "zero configuration" goal implies that the default configuration for the homenet router in isolation (no other routers discovered) must be to serve as a DNS cache, offer a .local domain, and add an entry into the .local domain for any DHCP lease allocated. If other homenet routers are discovered, then some form of election is needed to figure out a DNS primary for the .local domain. One could argue that the homenet router could also get a proper domain name from the provider, but most providers will give their domain name in response to DHCP queries. If the provider is know to provide a useful domain name, then trusting the domain offerred by the provider can be a simple configuration override. Simple configuration could substitute a real domain name for the .local default name. Whether to supress providing local mappings to external queries could also be a simple configuration knob. We need a extremely strong motivation to reinvent the wheel on something as fundamental as name resolution. I don't see that we have any unmet requirement that can't be solved using DNS as the basis. I admit that we can't use any of the existing freely available DNS server software (that I am aware of) because it does not do anything useful in the absense of configuration and configuration is overly complex for homenet use. Curtis