Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC3411E80E8 for ; Fri, 11 Oct 2013 05:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.376 X-Spam-Level: X-Spam-Status: No, score=0.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.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 l8bpRi8EN378 for ; Fri, 11 Oct 2013 05:06:01 -0700 (PDT) Received: from smtp1.elserrat.org (109-69-9-53-guifi-gurb.ip4.guifi.net [109.69.9.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2800B11E8152 for ; Fri, 11 Oct 2013 05:05:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.elserrat.org (Postfix) with ESMTP id D69503401354 for ; Fri, 11 Oct 2013 14:05:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=guifi.net; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:from:from:date:date:message-id :received:received:received; s=dkim; t=1381493152; x=1383307553; bh=vwbfDs5vSHeYBe8GyJo6wBmGSjC6j/VmiJLdWgrd/rM=; b=Km6iuKtDdaFF x5hGDE1BVaBeY0St54Ub98vBquggD9yO46hSwNPjtRU0HcQxixr4JWj2zn2uX9vf kvqyPPv0hz0xk+zCGJRfVLPLDWZmqitk9GEJOu3eH3tDQAnX5cXsEsVtLt31rQ8R h8yy/8zARhiWz6vQ3lGveHafzs4RxBMBdoo1tlAC6mGuHDk1KuWeFElKndHnq35q nOtxpTHB1jhnV5eE31OJO2JojwuxRUuf5QqRQzd9nx99GtHtVBvnqCkjUWTLVOSv JtYxqBmGw3i2kBzp3NYPy4G5Kjl3B1XR10uF+iyEIvpV2H/WG6vDrMueMSBZStEV uI5pB+05Ww== X-Virus-Scanned: Scrollout F1 on Debian amavisd-new at elserrat.org Received: from smtp1.elserrat.org ([127.0.0.1]) by localhost (smtp1.elserrat.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lMZoNiXO3MFm for ; Fri, 11 Oct 2013 14:05:52 +0200 (CEST) Received: from mail.elserrat.org (109-69-9-9-guifi-gurb.ip4.guifi.net [109.69.9.9]) by smtp1.elserrat.org (Postfix) with ESMTP id C64CD3401340 for ; Fri, 11 Oct 2013 14:05:51 +0200 (CEST) Received: from [192.168.4.222] (81.202.101.225.dyn.user.ono.com [81.202.101.225]) by mail.elserrat.org (Postfix) with ESMTPSA id 7A1CE6A92BE for ; Fri, 11 Oct 2013 14:05:51 +0200 (CEST) Message-ID: <5257E99E.1050308@guifi.net> Date: Fri, 11 Oct 2013 14:05:50 +0200 From: =?ISO-8859-1?Q?Javi_Jim=E9nez?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mdnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [mdnsext] New participant from guifi.net Community Network and the Clommunity project X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:13:14 -0000 Greetings, Recently we got news about the WG in the mailing list of the Clommunity project [1] a project about building a cloud in a box for Community Networks. One subtask of the Clommunity project is related to the subject of the mdnsext mailing list. In the received message we were invited to participate in the current mailing list. We'd like to present a project [2] (ddnsc) related to the pourpose of this working group, we're in the first developing stages of the project and it's an script which publishes DNS registers to a global DNS server using the 'nsupdate' program. At the moment it's possible to publish and browse services, we need to test and improve it. The work is related to GNU/Linux and the Avahi Zeroconf implementation. We continue developing the idea, which is basically to publish the services of a Community Network in a DNS server reachable using an anycast address for all the distributed DNS servers, with the anycast address we can replicate the servers (we already replicate DNS servers in the CN using geographical zones), with the anycast we try to avoid the overloading of unique DNS servers. The services are in a particular subdomain, as for example 'guifi', and all the users could browse the services inside the Community Network. Related to the script, have to say that security is a problem, because right now anyone is allowed to update the bind DNS registers (allow-update {any}; it's aimed for all the users who want to publish services), perhaps we need an ACL to only allow to publish (only) new services pointing to the IP which is sending the publication. Due that reaseon, we've not public DNS service yet, it's being worked only under a development environment. We don't know if the linked code it could be useful but the linked project is part of current research. The referred code is a result of various documents, meetings and working groups present in the references and covers it in part. Personally I work for the "Fundació Privada per a la Xarxa Oberta, Lliure i Neutral guifi.net" [3] (guifi.net Foundation Network Common Open, Free and Neutral) Foundation about the guifi.net Community Network [4] with more than 22.000 nodes and we're participating in the Clommunity European project. I'm not representing but giving information, and with your permission, willing to participate in the mailing list discussing topics as best as I can. Best Regards. [1] http://clommunity-project.eu/ [2] https://github.com/javi-jimenez/ddnsc [3] http://blogs.guifi.net/fundacio/ [4] http://guifi.net/ - English: http://guifi.net/en/node/38392 -- Javi Jiménez Fundació Privada per a la Xarxa Oberta, Lliure i Neutral guifi.net Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E6321E813B for ; Sun, 6 Oct 2013 20:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 YeTaIcrQsdEP for ; Sun, 6 Oct 2013 20:47:01 -0700 (PDT) Received: from www.let.de (www.let.de [178.77.75.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3035021E8133 for ; Sun, 6 Oct 2013 20:47:00 -0700 (PDT) X-No-Relay: not in my network Received: from [192.168.1.101] (f048160138.adsl.alicedsl.de [78.48.160.138]) by www.let.de (Postfix) with ESMTPA id A5AB39E0C031 for ; Mon, 7 Oct 2013 05:46:37 +0200 (CEST) Message-ID: <52522EA4.5050207@let.de> Date: Mon, 07 Oct 2013 05:46:44 +0200 From: macbroadcast User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mdnsext@ietf.org References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 03:47:06 -0000 Am 03.10.2013 21:05, schrieb manning bill: > but the "To Subscribe" pointer is busted…. > > > /bill and your system time is incorrect ;) /marc -- Les enfants terribles / Marc Manthey 50823 Köln, germany Vogelsangerstr.97 Mobile : 0049-1577-3329231 Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512 Website: https://let.de Twitter: https://twitter.com/macbroadcast Facebook: https://www.facebook.com/opencu Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B521F9248; Thu, 3 Oct 2013 15:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 LE06FLcJGRZc; Thu, 3 Oct 2013 15:09:54 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0821F918C; Thu, 3 Oct 2013 15:09:49 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id q4so2122173qcx.26 for ; Thu, 03 Oct 2013 15:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=gS5pasxw9YsxQK97WN1Gdc8ktOO2njrhWnM/b+GXclU=; b=s0vd7n8K20TREX5RYqMiLzvg20np0kLEW5lJmCItGspRcieEtDXuTacIhE/gIFn7gq bJfWoFvW4r79w3AgfJGZEGQUqQPMk8vUgGL9zsvvubdbuQa7GApByDRYvhnjvxgv1wEl Mr94SRVxyPqmK/4JjvP4A1eKnffYD39xDhdAqidbhoMBFz8XvyHsTeV7XW4JTCS0kyok DqobyjfCR7B6D6BdvPFLqEvoE5flS98KH4spPdIy6BYdjKtqOTX7HJVOiBk4GxRZIeJ3 bpcgh6hwrM9K4+0pvh8tkG4f8xd3115au3f51ztzDGgmF0xdwnj0VwJbg6ba4oOk+NdO 01rQ== X-Received: by 10.224.22.202 with SMTP id o10mr4609550qab.117.1380838188204; Thu, 03 Oct 2013 15:09:48 -0700 (PDT) Received: from [192.168.1.116] (c-24-62-108-202.hsd1.ma.comcast.net. [24.62.108.202]) by mx.google.com with ESMTPSA id 4sm18910336qak.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 15:09:47 -0700 (PDT) References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> <201310031946.r93JkaUQ026289@bela.nlnetlabs.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <201310031946.r93JkaUQ026289@bela.nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <000F1B1E-93E6-432D-BC33-46D5E70B41E4@gmail.com> X-Mailer: iPhone Mail (10B350) From: Ralph Droms Date: Thu, 3 Oct 2013 18:09:45 -0400 To: Jaap Akkerhuis Cc: "mdnsext@ietf.org mdnsext" , Tim Chown , " Discussion" , IETF-Announce , manning bill Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 22:10:01 -0000 On Oct 3, 2013, at 3:46 PM, Jaap Akkerhuis wrote: >=20 > but the "To Subscribe" pointer is busted. >=20 > According to the list is supposed > to be . mdnsext@ietf.org was used for the two BoFs. The WG will be dnssd, and the m= ailing list will be dnssd@ietf.org (which, I air, is not what is shown in th= e charter header). - Ralph >=20 > jaap > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D6321E8114; Thu, 3 Oct 2013 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-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 afGPs0l2xEpL; Thu, 3 Oct 2013 13:05:09 -0700 (PDT) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 89AAA21F8319; Thu, 3 Oct 2013 12:47:12 -0700 (PDT) Received: from bela.nlnetlabs.nl (localhost [IPv6:::1]) by bela.nlnetlabs.nl (8.14.7/8.14.7) with ESMTP id r93JkaUQ026289; Thu, 3 Oct 2013 21:46:37 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Authentication-Results: bela.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl Message-Id: <201310031946.r93JkaUQ026289@bela.nlnetlabs.nl> To: manning bill From: Jaap Akkerhuis In-reply-to: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> Comments: In-reply-to manning bill message dated "Thu, 03 Oct 2013 12:05:51 -0700." Date: Thu, 03 Oct 2013 21:46:36 +0200 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [IPv6:::1]); Thu, 03 Oct 2013 21:46:38 +0200 (CEST) Cc: "mdnsext@ietf.org mdnsext" , Tim Chown , " Discussion" , IETF-Announce Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:05:21 -0000 but the "To Subscribe" pointer is busted. According to the list is supposed to be . jaap Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85B221E80CD; Thu, 3 Oct 2013 12:38:50 -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 djiYzGBJswee; Thu, 3 Oct 2013 12:38:38 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 4842221F9AD5; Thu, 3 Oct 2013 12:20:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUk3Da4V5OJa4j02DazmNSXOsrMlsSVJD@postini.com; Thu, 03 Oct 2013 12:20:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E1B1F1B82F0; Thu, 3 Oct 2013 12:20:10 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D53C2190075; Thu, 3 Oct 2013 12:20:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 12:20:10 -0700 From: Ted Lemon To: manning bill Thread-Topic: WG Review: Extensions for Scalable DNS Service Discovery (dnssd) Thread-Index: AQHOwF5B0GotrtN9IE6CWx+CuArZj5njxX0AgAAGRoCAAAQAAA== Date: Thu, 3 Oct 2013 19:20:10 +0000 Message-ID: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <42B3C02C1C0FEF49A973B7E2E4D67F36@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org mdnsext" , Tim Chown , " Discussion" , IETF-Announce , Ralph Droms Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:38:50 -0000 On Oct 3, 2013, at 3:05 PM, manning bill wrote: > but the "To Subscribe" pointer is busted=85. Correct. I should have gotten the information right before sending out th= e announcement, but I blew it=97sorry about that. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E857521E805D; Thu, 3 Oct 2013 12:34:36 -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=[AWL=0.000, 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 3isgxgE7Ee56; Thu, 3 Oct 2013 12:34:23 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 436CB21E80B0; Thu, 3 Oct 2013 12:17:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUk3Cq2iPwqHbr6JLwMpvairt29Ciwt9S@postini.com; Thu, 03 Oct 2013 12:17:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CB92F1B82EC; Thu, 3 Oct 2013 12:16:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 356C5190075; Thu, 3 Oct 2013 12:16:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 12:16:58 -0700 From: Ted Lemon To: Tim Chown Thread-Topic: WG Review: Extensions for Scalable DNS Service Discovery (dnssd) Thread-Index: AQHOwF5B0GotrtN9IE6CWx+CuArZj5njxX0AgAAJXwA= Date: Thu, 3 Oct 2013 19:16:57 +0000 Message-ID: <869EE259-1A87-447B-A3A8-2B8254FCB6CA@nominum.com> References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6059774F1402C9438CC2BDB1951A7395@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org mdnsext" , Ralph Droms , " Discussion" , IETF-Announce , manning bill Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:34:37 -0000 Discussion of IETF consensus activities is supposed to occur on the IETF ma= iling list, not on the working group mailing list, which doesn't yet exist.= We'll set up the new mailing list when the working group is approved. S= orry for the confusion. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD621F9AA1; Thu, 3 Oct 2013 12:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 Pqv-IN-fuCsB; Thu, 3 Oct 2013 12:19:56 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C321F9C7B; Thu, 3 Oct 2013 12:07:05 -0700 (PDT) Received: from [128.9.184.131] ([128.9.184.131]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r93J5pq2012326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Oct 2013 12:05:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Thu, 3 Oct 2013 12:05:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1283) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu X-Mailman-Approved-At: Sun, 06 Oct 2013 19:21:27 -0700 Cc: "mdnsext@ietf.org mdnsext" , Lemon Ted , " Discussion" , IETF-Announce , Ralph Droms Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:20:08 -0000 but the "To Subscribe" pointer is busted=85. /bill On 3October2013Thursday, at 11:43, Tim Chown wrote: > On 3 Oct 2013, at 18:07, manning bill wrote: >=20 >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 550 5.1.1 : Recipient address = rejected: User unknown in virtual alias table) >=20 > I think the active list is still mdnsext@ietf.org? > See: = http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html >=20 > And the 'header' information below should now probably read something = like this: >=20 > --- snip --- >=20 > Scalable DNS Service Discovery (dnssd) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > Ralph Droms > Tim Chown >=20 > Assigned Area Director: > Ted Lemon >=20 > Mailing list > Address: dnssd@ietf.org > To Subscribe: dnssd-request@ietf.org > Archive: http://www.ietf.org/mail-archive/web/dnssd > Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext=20 >=20 >=20 > --- snip --- >=20 > Tim >=20 >>=20 >>=20 >>=20 >> On 3October2013Thursday, at 8:42, The IESG wrote: >>=20 >>> A new IETF working group has been proposed in the Internet Area. The = IESG >>> has not made any determination yet. The following draft charter was >>> submitted, and is provided for informational purposes only. Please = send >>> your comments to the IESG mailing list (iesg at ietf.org) by = 2013-10-10. >>>=20 >>> Extensions for Scalable DNS Service Discovery (dnssd) >>> ------------------------------------------------ >>> Current Status: Proposed WG >>>=20 >>> Chairs: >>> Ralph Droms >>> Tim Chown >>>=20 >>> Assigned Area Director: >>> Ted Lemon >>>=20 >>> Mailing list >>> Address: dnssdext@ietf.org >>> To Subscribe: dnssdext-request@ietf.org >>> Archive: http://www.ietf.org/mail-archive/web/dnssdext >>>=20 >>> Charter: >>>=20 >>> Background >>> ---------- >>>=20 >>> Zero configuration networking protocols are currently well suited to >>> discover services within the scope of a single link. In particular, >>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes >>> referred to using Apple Computer Inc.'s trademark, Bonjour) are >>> widely used for DNS-based service discovery and host name resolution >>> on a single link. >>>=20 >>> The DNS-SD/mDNS protocol suite is used in many scenarios including >>> home, campus, and enterprise networks. However, the zero = configuration >>> mDNS protocol is constrained to link-local multicast scope by = design, >>> and therefore cannot be used to discover services on remote links. >>>=20 >>> In a home network that consists of a single (possibly bridged) link, >>> users experience the expected discovery behavior; available services >>> appear because all devices share a common link. However, in = multi-link >>> home networks (as envisaged by the homenet WG) or in routed campus = or >>> enterprise networks, devices and users can only discover services on >>> the same link, which is a significant limitation. This has led to >>> calls, such as the Educause petition, to develop an appropriate = service >>> discovery solution to span multiple links or to perform discovery = across >>> a wide area, not necessarily on directly connected links. >>>=20 >>> In addition, the "Smart Energy Profile 2 Application Protocol = Standard", >>> published by ZigBee Alliance and HomePlug Powerline Alliance = specifies >>> the DNS-SD/mDNS protocol suite as the basis for its method of zero >>> configuration service discovery. However, its use of wireless mesh >>> multi-link subnets in conjunction with traditional routed networks = will >>> require extensions to the DNS-SD/mDNS protocols to allow operation >>> across multiple links. >>>=20 >>> The scenarios in which multi-link service discovery is required may >>> be zero configuration environments, environments where = administrative >>> configuration is supported, or a mixture of the two. >>>=20 >>> As demand for service discovery across wider area routed networks >>> grows, some vendors are beginning to ship proprietary solutions. It >>> is thus both timely and important that efforts to develop improved,=20= >>> scalable, autonomous service discovery solutions for routed networks=20= >>> are coordinated towards producing a single, standards-based = solution. >>>=20 >>> The WG will consider the tradeoffs between reusing/extending = existing >>> protocols and developing entirely new ones. It is highly desirable >>> that any new solution is backwardly compatible with existing = DNS-SD/mDNS >>> deployments. Any solution developed by the dnssd WG must not = conflict >>> or interfere with the operation of other zero-configuration service = and >>> naming protocols such as uPnP or LLMNR. Integration with such = protocols >>> is out of scope for this WG. >>>=20 >>> The focus of the WG is to develop a solution for extended, scalable=20= >>> DNS-SD. This work is likely to highlight problems and challenges = with=20 >>> naming protocols, as some level of coexistence will be required = between=20 >>> local zero configuration name services and those forming part of the=20= >>> global DNS. It is important that these issues are captured and=20 >>> documented for further analysis; solving those problems is however = not=20 >>> within the scope of this WG. >>>=20 >>> Working Group Description >>> ------------------------- >>>=20 >>> To that end, the primary goals of the dnssd WG are as follows: >>>=20 >>> 1. To document a set of requirements for scalable, autonomous >>> DNS-based service discovery in routed, multi-link networks in the >>> following five scenarios: >>>=20 >>> (A) Personal Area networks, e.g., one laptop and one printer. >>> This is the simplest example of a service discovery network, >>> and may or may not have external connectivity.=20 >>>=20 >>> (B) Home networks, as envisaged by the homenet WG, consisting of=20 >>> one or more exit routers, with one or more upstream providers=20= >>> or networks, and an arbitrary internal topology with=20 >>> heterogeneous media where routing is automatically configured.=20= >>> The home network would typically be a single zero configuration=20= >>> administrative domain with a relatively limited number of=20 >>> devices.=20 >>>=20 >>> (C) Wireless 'hotspot' networks, which may include wireless = networks >>> made available in public places, or temporary or permanent >>> infrastructures targeted towards meeting or conference style >>> events, e.g., as provided for IETF meetings. In such >>> environments other devices may be more likely to be 'hostile' >>> to the user. >>>=20 >>> (D) Enterprise networks, consisting of larger routed networks,=20 >>> with large numbers of devices, which may be deployments=20 >>> spanning over multiple sites with multiple upstreams, and >>> one more more administrative domains (depending on internal >>> administrative delegation). The large majority of the=20 >>> forwarding and security devices are configured. These may >>> be commercial or academic networks, with differing levels=20 >>> of administrative control over certain devices on the network, >>> and BYOD devices commonplace in the campus scenario. >>>=20 >>> (E) Mesh networks such as RPL/6LoWPAN, with one or more links per >>> routable prefix, which may or may not have external = connectivity. >>> The topology may use technologies including 802.11 wireless,=20 >>> HomePlug AV and GP, and ZigBee IP.=20 >>>=20 >>> In the above scenarios, the aim is to facilitate service discovery=20= >>> across the defined site. It is also desirable that a user or = device,=20 >>> when away from such a site, is still able to discover services=20 >>> within that site, e.g. a user discovering services in their home=20 >>> network while remote from it. >>>=20 >>> It is also desirable that multiple discovery scopes are supported, >>> from the point of view of announcements and discovery, be the >>> scope 'site', 'building', or 'room'. A user for example may only >>> be interested in devices in the same room. >>>=20 >>> 2. To develop an improved, scalable solution for service discovery=20= >>> that can operate in multi-link networks, where devices may be >>> in neighboring or non-neighboring links, applicable to >>> the scenarios above. The solution will consider tradeoffs between >>> reusing/extending existing protocols and developing entirely new >>> protocols.=20 >>>=20 >>> The solution should include documentation or definition of the >>> interfaces that can be implemented, separately to transport of=20 >>> the information. >>>=20 >>> 3. To document challenges and problems encountered in the = coexistence=20 >>> of zero configuration and global DNS name services in such=20 >>> multi-link networks, including consideration of both the name=20 >>> resolution mechanism and the namespace. >>>=20 >>> It is important that the dnssd WG takes input from stakeholders in >>> the scenarios it is considering. For example, the homenet WG is >>> currently evaluating its own requirements for naming and service >>> discovery; it is up to the homenet WG as to whether it wishes to >>> recommend adoption of the solution developed in the dnssd WG, but >>> coordination between the WGs is desirable. >>>=20 >>> Deliverables: >>>=20 >>> The WG will produce three documents: an Informational RFC on the >>> requirements for service discovery protocols operating on = potentially >>> non-neighboring multi-link networks as described above; a Standards >>> Track RFC documenting an extended, scalable service discovery = solution=20 >>> that is applicable to those scenarios; and an Informational RFC=20 >>> describing the problems arising when developing the extended SD = solution=20 >>> and how it affects the integration of local zero configuration and = global >>>=20 >>> DNS name services. >>>=20 >>> Milestones: >>> Sep 2013 - Formation of the WG >>> Oct 2013 - Adopt requirements draft as WG document >>> Jan 2014 - Submit requirements draft to the IESG as an Informational >>> RFC >>> Mar 2014 - Adopt wide-area service discovery solution draft as WG >>> document=20 >>> Mar 2014 - Adopt Informational document on the problems and = challenges >>> arising for zeroconf and unicast DNS name services >>> Sep 2014 - Submit wide-area service discovery solution draft to the >>> IESG as Standards Track RFC=20 >>> Sep 2014 - Submit the zeroconf and unicast DNS "problems and >>> challenges" draft to the IESG as Informational. >>>=20 >>>=20 >>=20 >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11AD021F8D62; Thu, 3 Oct 2013 11:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=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 qYpzdwZq6bDc; Thu, 3 Oct 2013 11:51:51 -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 F2C3021F8984; Thu, 3 Oct 2013 11:43:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r93IhUjm025455; Thu, 3 Oct 2013 19:43:30 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r93IhUjm025455 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1380825810; bh=SXHCY0EZOq8r7Nj75r+vIh08TRE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=NSs5dihBz9bfSTNDxdWxzh6rfqfmSGHaa6AlFhqio/w74KdGwTkYb7rf+jZLXSebq Mpteu7h18+wbsZ3SWet31Vhneol8gCfNFL1qOInKxu71QSaNC+d654ffrZxKH/Nz8Q duelj2QUfvzDTYK2Wd6qUxJHHkwYjwOVDanvYrjY= 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 (valid=N/A) id p92JhU0544563631dS ret-id none; Thu, 03 Oct 2013 19:43:30 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r93IhO3B031347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Oct 2013 19:43:25 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> Date: Thu, 3 Oct 2013 19:43:24 +0100 Message-ID: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> To: manning bill X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p92JhU054456363100; tid=p92JhU0544563631dS; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r93IhUjm025455 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "mdnsext@ietf.org mdnsext" , Lemon Ted , " Discussion" , IETF-Announce , Ralph Droms Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 18:52:06 -0000 --Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Oct 2013, at 18:07, manning bill wrote: > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 : Recipient address = rejected: User unknown in virtual alias table) I think the active list is still mdnsext@ietf.org? See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html And the 'header' information below should now probably read something = like this: --- snip --- Scalable DNS Service Discovery (dnssd) ------------------------------------------------ Current Status: Proposed WG Chairs: Ralph Droms Tim Chown Assigned Area Director: Ted Lemon Mailing list Address: dnssd@ietf.org To Subscribe: dnssd-request@ietf.org Archive: http://www.ietf.org/mail-archive/web/dnssd Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext=20 --- snip --- Tim >=20 >=20 >=20 > On 3October2013Thursday, at 8:42, The IESG wrote: >=20 >> A new IETF working group has been proposed in the Internet Area. The = IESG >> has not made any determination yet. The following draft charter was >> submitted, and is provided for informational purposes only. Please = send >> your comments to the IESG mailing list (iesg at ietf.org) by = 2013-10-10. >>=20 >> Extensions for Scalable DNS Service Discovery (dnssd) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Chairs: >> Ralph Droms >> Tim Chown >>=20 >> Assigned Area Director: >> Ted Lemon >>=20 >> Mailing list >> Address: dnssdext@ietf.org >> To Subscribe: dnssdext-request@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/dnssdext >>=20 >> Charter: >>=20 >> Background >> ---------- >>=20 >> Zero configuration networking protocols are currently well suited to >> discover services within the scope of a single link. In particular, >> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes >> referred to using Apple Computer Inc.'s trademark, Bonjour) are >> widely used for DNS-based service discovery and host name resolution >> on a single link. >>=20 >> The DNS-SD/mDNS protocol suite is used in many scenarios including >> home, campus, and enterprise networks. However, the zero = configuration >> mDNS protocol is constrained to link-local multicast scope by design, >> and therefore cannot be used to discover services on remote links. >>=20 >> In a home network that consists of a single (possibly bridged) link, >> users experience the expected discovery behavior; available services >> appear because all devices share a common link. However, in = multi-link >> home networks (as envisaged by the homenet WG) or in routed campus or >> enterprise networks, devices and users can only discover services on >> the same link, which is a significant limitation. This has led to >> calls, such as the Educause petition, to develop an appropriate = service >> discovery solution to span multiple links or to perform discovery = across >> a wide area, not necessarily on directly connected links. >>=20 >> In addition, the "Smart Energy Profile 2 Application Protocol = Standard", >> published by ZigBee Alliance and HomePlug Powerline Alliance = specifies >> the DNS-SD/mDNS protocol suite as the basis for its method of zero >> configuration service discovery. However, its use of wireless mesh >> multi-link subnets in conjunction with traditional routed networks = will >> require extensions to the DNS-SD/mDNS protocols to allow operation >> across multiple links. >>=20 >> The scenarios in which multi-link service discovery is required may >> be zero configuration environments, environments where administrative >> configuration is supported, or a mixture of the two. >>=20 >> As demand for service discovery across wider area routed networks >> grows, some vendors are beginning to ship proprietary solutions. It >> is thus both timely and important that efforts to develop improved,=20= >> scalable, autonomous service discovery solutions for routed networks=20= >> are coordinated towards producing a single, standards-based solution. >>=20 >> The WG will consider the tradeoffs between reusing/extending existing >> protocols and developing entirely new ones. It is highly desirable >> that any new solution is backwardly compatible with existing = DNS-SD/mDNS >> deployments. Any solution developed by the dnssd WG must not = conflict >> or interfere with the operation of other zero-configuration service = and >> naming protocols such as uPnP or LLMNR. Integration with such = protocols >> is out of scope for this WG. >>=20 >> The focus of the WG is to develop a solution for extended, scalable=20= >> DNS-SD. This work is likely to highlight problems and challenges = with=20 >> naming protocols, as some level of coexistence will be required = between=20 >> local zero configuration name services and those forming part of the=20= >> global DNS. It is important that these issues are captured and=20 >> documented for further analysis; solving those problems is however = not=20 >> within the scope of this WG. >>=20 >> Working Group Description >> ------------------------- >>=20 >> To that end, the primary goals of the dnssd WG are as follows: >>=20 >> 1. To document a set of requirements for scalable, autonomous >> DNS-based service discovery in routed, multi-link networks in the >> following five scenarios: >>=20 >> (A) Personal Area networks, e.g., one laptop and one printer. >> This is the simplest example of a service discovery network, >> and may or may not have external connectivity.=20 >>=20 >> (B) Home networks, as envisaged by the homenet WG, consisting of=20 >> one or more exit routers, with one or more upstream providers=20 >> or networks, and an arbitrary internal topology with=20 >> heterogeneous media where routing is automatically configured.=20= >> The home network would typically be a single zero configuration=20= >> administrative domain with a relatively limited number of=20 >> devices.=20 >>=20 >> (C) Wireless 'hotspot' networks, which may include wireless networks >> made available in public places, or temporary or permanent >> infrastructures targeted towards meeting or conference style >> events, e.g., as provided for IETF meetings. In such >> environments other devices may be more likely to be 'hostile' >> to the user. >>=20 >> (D) Enterprise networks, consisting of larger routed networks,=20 >> with large numbers of devices, which may be deployments=20 >> spanning over multiple sites with multiple upstreams, and >> one more more administrative domains (depending on internal >> administrative delegation). The large majority of the=20 >> forwarding and security devices are configured. These may >> be commercial or academic networks, with differing levels=20 >> of administrative control over certain devices on the network, >> and BYOD devices commonplace in the campus scenario. >>=20 >> (E) Mesh networks such as RPL/6LoWPAN, with one or more links per >> routable prefix, which may or may not have external = connectivity. >> The topology may use technologies including 802.11 wireless,=20 >> HomePlug AV and GP, and ZigBee IP.=20 >>=20 >> In the above scenarios, the aim is to facilitate service discovery=20= >> across the defined site. It is also desirable that a user or = device,=20 >> when away from such a site, is still able to discover services=20 >> within that site, e.g. a user discovering services in their home=20 >> network while remote from it. >>=20 >> It is also desirable that multiple discovery scopes are supported, >> from the point of view of announcements and discovery, be the >> scope 'site', 'building', or 'room'. A user for example may only >> be interested in devices in the same room. >>=20 >> 2. To develop an improved, scalable solution for service discovery=20 >> that can operate in multi-link networks, where devices may be >> in neighboring or non-neighboring links, applicable to >> the scenarios above. The solution will consider tradeoffs between >> reusing/extending existing protocols and developing entirely new >> protocols.=20 >>=20 >> The solution should include documentation or definition of the >> interfaces that can be implemented, separately to transport of=20 >> the information. >>=20 >> 3. To document challenges and problems encountered in the coexistence=20= >> of zero configuration and global DNS name services in such=20 >> multi-link networks, including consideration of both the name=20 >> resolution mechanism and the namespace. >>=20 >> It is important that the dnssd WG takes input from stakeholders in >> the scenarios it is considering. For example, the homenet WG is >> currently evaluating its own requirements for naming and service >> discovery; it is up to the homenet WG as to whether it wishes to >> recommend adoption of the solution developed in the dnssd WG, but >> coordination between the WGs is desirable. >>=20 >> Deliverables: >>=20 >> The WG will produce three documents: an Informational RFC on the >> requirements for service discovery protocols operating on potentially >> non-neighboring multi-link networks as described above; a Standards >> Track RFC documenting an extended, scalable service discovery = solution=20 >> that is applicable to those scenarios; and an Informational RFC=20 >> describing the problems arising when developing the extended SD = solution=20 >> and how it affects the integration of local zero configuration and = global >>=20 >> DNS name services. >>=20 >> Milestones: >> Sep 2013 - Formation of the WG >> Oct 2013 - Adopt requirements draft as WG document >> Jan 2014 - Submit requirements draft to the IESG as an Informational >> RFC >> Mar 2014 - Adopt wide-area service discovery solution draft as WG >> document=20 >> Mar 2014 - Adopt Informational document on the problems and = challenges >> arising for zeroconf and unicast DNS name services >> Sep 2014 - Submit wide-area service discovery solution draft to the >> IESG as Standards Track RFC=20 >> Sep 2014 - Submit the zeroconf and unicast DNS "problems and >> challenges" draft to the IESG as Informational. >>=20 >>=20 >=20 --Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii bmanning@isi.edu> = wrote:
 ----- The following = addresses had permanent fatal errors -----
<dnssdext-request@ietf.org>= ;
  (reason: 550 5.1.1 <dnssdext-request@ietf.org>= ;: Recipient address rejected: User unknown in virtual alias = table)

I think the active list is still = mdnsext@ietf.org?
See: = ;http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html

And the 'header' information below should now = probably read something like this:

--- snip = ---

Scalable DNS Service Discovery =  (dnssd)
------------------------------------------------
Curre= nt Status: Proposed WG

Chairs:
 Ralph Droms <rdroms.ietf@gmail.com>
&nb= sp;Tim Chown <tjc@ecs.soton.ac.uk>

Ass= igned Area Director:
 Ted Lemon <ted.lemon@nominum.com>
Mailing list
 Address: dnssd@ietf.org
 To = Subscribe: dnssd-request@ietf.org
&n= bsp;Archive: http://www.ietf.org/ma= il-archive/web/dnssd
 Pre-WG BoF Archive: http://www.ietf.org/mail-ar= chive/web/mdnsext 


--- = snip ---

Tim




On 3October2013Thursday, at 8:42, The IESG = wrote:

A new IETF working group has = been proposed in the Internet Area. The IESG
has not made any = determination yet. The following draft charter was
submitted, and is = provided for informational purposes only. Please send
your comments = to the IESG mailing list (iesg at ietf.org) by 2013-10-10.

Extensions = for Scalable DNS Service Discovery =  (dnssd)
------------------------------------------------
Curre= nt Status: Proposed WG

Chairs:
Ralph Droms <rdroms.ietf@gmail.com>
= Tim Chown <tjc@ecs.soton.ac.uk>

Ass= igned Area Director:
Ted Lemon <ted.lemon@nominum.com>
Mailing list
Address: dnssdext@ietf.org
To = Subscribe: dnssdext-request@ietf.org Archive: http://www.ietf.org= /mail-archive/web/dnssdext

Charter:

Background
------= ----

Zero configuration networking protocols are currently well = suited to
discover services within the scope of a single link. =  In particular,
the DNS-SD [RFC 6763] and mDNS [RFC6762] = protocol suite (sometimes
referred to using Apple Computer Inc.'s = trademark, Bonjour) are
widely used for DNS-based service discovery = and host name resolution
on a single link.

The DNS-SD/mDNS = protocol suite is used in many scenarios including
home, campus, and = enterprise networks.  However, the zero configuration
mDNS = protocol is constrained to link-local multicast scope by design,
and = therefore cannot be used to discover services on remote links.

In = a home network that consists of a single (possibly bridged) = link,
users experience the expected discovery behavior; available = services
appear because all devices share a common link. =  However, in multi-link
home networks (as envisaged by the = homenet WG) or in routed campus or
enterprise networks, devices and = users can only discover services on
the same link, which is a = significant limitation.  This has led to
calls, such as the = Educause petition, to develop an appropriate service
discovery = solution to span multiple links or to perform discovery across
a wide = area, not necessarily on directly connected links.

In addition, = the "Smart Energy Profile 2 Application Protocol Standard",
published = by ZigBee Alliance and HomePlug Powerline Alliance specifies
the = DNS-SD/mDNS protocol suite as the basis for its method of = zero
configuration service discovery.  However, its use of = wireless mesh
multi-link subnets in conjunction with traditional = routed networks will
require extensions to the DNS-SD/mDNS protocols = to allow operation
across multiple links.

The scenarios in = which multi-link service discovery is required may
be zero = configuration environments, environments where = administrative
configuration is supported, or a mixture of the = two.

As demand for service discovery across wider area routed = networks
grows, some vendors are beginning to ship proprietary = solutions.  It
is thus both timely and important that efforts to = develop improved,
scalable, autonomous service discovery solutions = for routed networks
are coordinated towards producing a single, = standards-based solution.

The WG will consider the tradeoffs = between reusing/extending existing
protocols and developing entirely = new ones.  It is highly desirable
that any new solution is = backwardly compatible with existing DNS-SD/mDNS
deployments. =  Any solution developed by the dnssd WG must not conflict
or = interfere with the operation of other zero-configuration service = and
naming protocols such as uPnP or LLMNR.  Integration with = such protocols
is out of scope for this WG.

The focus of the = WG is to develop a solution for extended, scalable
DNS-SD. =  This work is likely to highlight problems and challenges with =
naming protocols, as some level of coexistence will be required = between
local zero configuration name services and those forming = part of the
global DNS.  It is important that these issues are = captured and
documented for further analysis; solving those problems = is however not
within the scope of this WG.

Working Group = Description
-------------------------

To that end, the primary = goals of the dnssd WG are as follows:

1. To document a set of = requirements for scalable, autonomous
 DNS-based service = discovery in routed, multi-link networks in the
 following five = scenarios:

 (A) Personal Area networks, e.g., one laptop = and one printer.
     This is the simplest = example of a service discovery network,
=      and may or may not have external = connectivity.

 (B) Home networks, as envisaged by the = homenet WG, consisting of
     one or more = exit routers, with one or more upstream providers
=      or networks, and an arbitrary internal = topology with
     heterogeneous media = where routing is automatically configured.
=      The home network would typically be a = single zero configuration
=      administrative domain with a relatively = limited number of
     devices.

=  (C) Wireless 'hotspot' networks, which may include wireless = networks
     made available in public = places, or temporary or permanent
=      infrastructures targeted towards meeting = or conference style
     events, e.g., as = provided for IETF meetings.  In such
=      environments other devices may be more = likely to be 'hostile'
     to the = user.

 (D) Enterprise networks, consisting of larger routed = networks,
     with large numbers of = devices, which may be deployments
=      spanning over multiple sites with multiple = upstreams, and
     one more more = administrative domains (depending on internal
=      administrative delegation).  The = large majority of the
     forwarding and = security devices are configured.  These may
=      be commercial or academic networks, with = differing levels
     of administrative = control over certain devices on the network,
=      and BYOD devices commonplace in the campus = scenario.

 (E) Mesh networks such as RPL/6LoWPAN, with one = or more links per
     routable prefix, = which may or may not have external connectivity.
=      The topology may use technologies = including 802.11 wireless,
     HomePlug = AV and GP, and ZigBee IP.

 In the above scenarios, the aim = is to facilitate service discovery
 across the defined site. =  It is also desirable that a user or device,
 when away = from such a site, is still able to discover services
 within = that site, e.g. a user discovering services in their home
=  network while remote from it.

 It is also desirable = that multiple discovery scopes are supported,
 from the point = of view of announcements and discovery, be the
 scope 'site', = 'building', or 'room'.  A user for example may only
 be = interested in devices in the same room.

2. To develop an = improved, scalable solution for service discovery
 that can = operate in multi-link networks, where devices may be
 in = neighboring or non-neighboring links, applicable to
 the = scenarios above.  The solution will consider tradeoffs between
=  reusing/extending existing protocols and developing entirely = new
 protocols.

 The solution should include = documentation or definition of the
 interfaces that can be = implemented, separately to transport of
 the = information.

3. To document challenges and problems encountered = in the coexistence
 of zero configuration and global DNS name = services in such
 multi-link networks, including consideration = of both the name
 resolution mechanism and the = namespace.

It is important that the dnssd WG takes input from = stakeholders in
the scenarios it is considering.  For example, = the homenet WG is
currently evaluating its own requirements for = naming and service
discovery; it is up to the homenet WG as to = whether it wishes to
recommend adoption of the solution developed in = the dnssd WG, but
coordination between the WGs is = desirable.

Deliverables:

The WG will produce three = documents: an Informational RFC on the
requirements for service = discovery protocols operating on potentially
non-neighboring = multi-link networks as described above; a Standards
Track RFC = documenting an extended, scalable service discovery solution
that is = applicable to those scenarios; and an Informational RFC
describing = the problems arising when developing the extended SD solution
and = how it affects the integration of local zero configuration and = global

DNS name services.

Milestones:
Sep 2013 - = Formation of the WG
Oct 2013 - Adopt requirements draft as WG = document
Jan 2014 - Submit requirements draft to the IESG as an = Informational
RFC
Mar 2014 - Adopt wide-area service discovery = solution draft as WG
document
Mar 2014 - Adopt Informational = document on the problems and challenges
arising for zeroconf and = unicast DNS name services
Sep 2014 - Submit wide-area service = discovery solution draft to the
IESG as Standards Track RFC
Sep = 2014 - Submit the zeroconf and unicast DNS "problems and
challenges" = draft to the IESG as = Informational.




<= /html>= --Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089-- From rdroms@cisco.com Tue Oct 15 15:25:49 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5FB21F9FAB; Tue, 15 Oct 2013 15:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 y8I1yR1gm7kf; Tue, 15 Oct 2013 15:25:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 275D821F9B0D; Tue, 15 Oct 2013 15:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=859; q=dns/txt; s=iport; t=1381875943; x=1383085543; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=cScFz384upxpIGUqxwnKbte3cDc3gl3SVVIYnN9EVxM=; b=gGaD4tARopCwPvFl3N8mNAmRljSqaSoXombW3vre3P8Vxu3sGB/0y/7k 18a+VhcEwRegUslNR0F7gK46DgyUKh5AYxr+sG+wzzkq1JAQddvm8m8XZ qka6fLaX/iLzB2QADPsNoQFu8CPqtT0vp1D0fFKOQptjHVAvE4ZfbFwvB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkGAKK/XVKtJV2Y/2dsb2JhbABagwc4UsIqgSIWbQeCJwEEOjQLEgEqAxFCJwQOBQiHfr4BjxkxgyaBBgOZM5BTgySCKQ X-IronPort-AV: E=Sophos;i="4.93,503,1378857600"; d="scan'208";a="272506911" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 15 Oct 2013 22:25:42 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9FMPgNU005020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 22:25:42 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 17:25:41 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Announcing the dnssd WG and mailing list Thread-Index: AQHOyfV6aUIA1DJGsUaya+W/6ZXNSQ== Date: Tue, 15 Oct 2013 22:25:40 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA301BE28B5@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.136.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <9755738A8755DF4FA581786BD027DFDC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org mdnsext" Subject: [dnssd] Announcing the dnssd WG and mailing list X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:25:49 -0000 Welcome to the dnssd@ietf.org mailing list. In conjunction with the formation of the dnssd WG, the dnssd@ietf.org mailing list has been created. It has been initially populated with the subscription list from the mdnsext@ietf.org mailing list. mdnsext@ietf.org will be closed, and the archive will be retained for reference. The dnssd WG will be formally created before IETF 88. Tim Chown and I are the dnssd WG co-chairs. Thanks to Tim for taking on the co-chair job and thanks to Ted Lemon for his help and guidance as AD to get the dnssd WG chartered. dnssd will hold it first meeting in Vancouver. The agenda for the meeting is available at datatracker.ietf.org/meeting/88/agenda/dnssd We're looking for volunteers to take minutes and act as jabber scribes. Please contact Tim or me to sign up for one of those jobs. - Ralph From stokcons@xs4all.nl Thu Oct 17 04:48:17 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3202921F9DB0 for ; Thu, 17 Oct 2013 04:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 pyaiTjZeFp40 for ; Thu, 17 Oct 2013 04:48:12 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id D483921F9D99 for ; Thu, 17 Oct 2013 04:48:08 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r9HBlnVJ007281 for ; Thu, 17 Oct 2013 13:47:54 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-109-86.w90-0.abo.wanadoo.fr ([90.0.84.86]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 17 Oct 2013 13:47:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Oct 2013 13:47:48 +0200 From: peter van der Stok To: dnssd@ietf.org Organization: vanderstok consultancy Mail-Reply-To: consultancy@vanderstok.org Message-ID: <6d5b1a83daa9eb83f6f7f755cabfb642@xs4all.nl> X-Sender: stokcons@xs4all.nl (j9KiyIEK6mlh3hjhMEWWNE9MovY/KMDp) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: [dnssd] Fwd: New Version Notification for draft-vanderstok-dnssd-building-requirements-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 11:48:17 -0000 Dear dnssd, Kerry and I have submitted a draft which describes the requirements on multi-link discovery from a building control perspective. This draft is complementary to the existing requirements draft. Given a more constrained environment, requirements can be made in reasonable detail. Looking forward to comments, Peter and kerry -------- Oorspronkelijke bericht -------- Onderwerp: New Version Notification for draft-vanderstok-dnssd-building-requirements-00.txt Datum: 2013-10-17 13:42 Afzender: internet-drafts@ietf.org Ontvanger: Peter van der Stok , Kerry Lynn , Peter Van der Stok A new version of I-D, draft-vanderstok-dnssd-building-requirements-00.txt has been successfully submitted by Peter van der Stok and posted to the IETF repository. Filename: draft-vanderstok-dnssd-building-requirements Revision: 00 Title: Building control requirements Creation date: 2013-10-17 Group: Individual Submission Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-vanderstok-dnssd-building-requirements-00.txt Status: http://datatracker.ietf.org/doc/draft-vanderstok-dnssd-building-requirements Htmlized: http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requirements-00 Abstract: The draft describes an interface to the discovery of services on a bounded network segment from a building control perspective. Building control has special boundary conditions related to: (1) management of devices and services, (2) an installation involving stand-alone networks (3) (dis)connecting network (from) to Internet without renaming services and devices. Roaming devices are not considered in this version. Note Discussion and suggestions for improvement are requested, and should be sent to dnssd@ietf.org. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From kerlyn2001@gmail.com Mon Oct 21 17:36:05 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E4111E82BC for ; Mon, 21 Oct 2013 17:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 yxZcCQOEJtIv for ; Mon, 21 Oct 2013 17:36:04 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9084D11E80F2 for ; Mon, 21 Oct 2013 17:35:40 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so7388112wes.15 for ; Mon, 21 Oct 2013 17:35:39 -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:message-id:subject :from:to:content-type; bh=PoXPFg2nHvi4PjeXr66ZLDNEdVV4Wpq3jirS1GACuRM=; b=yd5Z51mqzJD1lSQp69LFwgivbhsVWLUov2zzqcjR/Wfb12ZODT91mczO35cli6xcLF PcuvEQlQweXql8JcPz0FQcztzpBMIy6kBZKUyhb+ynfPqnJB/e6k9sOEp/FUWn2j35Qf ifk/kyiLhP0wHXRJNtg/93paK+L2nED0It1IM0fU+vno0pa4QxWiloW+yLwdYGklz3C1 +dfpTtkc3Atn1ngUvLHoMNV+g7bzxEtW0zKQUSMDd0tPUIIJkM/Y/AxVhdkthWW5KobN ABojE1+GYP3Y7D6Bq2uCIC8lXvChqYnDTQqQ6z4ayN51fnHTYjndjfysFC0DDE/shIZJ 8S8A== MIME-Version: 1.0 X-Received: by 10.194.78.78 with SMTP id z14mr7616003wjw.32.1382402139416; Mon, 21 Oct 2013 17:35:39 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.216.227.132 with HTTP; Mon, 21 Oct 2013 17:35:39 -0700 (PDT) In-Reply-To: <20131021235033.32482.36001.idtracker@ietfa.amsl.com> References: <20131021235033.32482.36001.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 20:35:39 -0400 X-Google-Sender-Auth: a9SWqC3avyaO9bFYgwlVpxNH7HU Message-ID: From: Kerry Lynn To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=047d7bf0d52474ef2704e949943c Subject: [dnssd] Fwd: New Version Notification for draft-lynn-dnssd-requirements-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 00:36:05 -0000 --047d7bf0d52474ef2704e949943c Content-Type: text/plain; charset=ISO-8859-1 Greetings, This draft of the requirements is a minor update on the previous version. Not all of the suggestions made at the last BoF could be recovered from the meeting notes prompts, so please start a thread using this version as a basis if your comments at the BoF were not adequately addressed. Please also note that the WG page is not set up yet, so New Version Notifications are not automatically going out to . In particular, I'd like to call your attention to: http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile, and http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requirements Regards, -K- ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 7:50 PM Subject: New Version Notification for draft-lynn-dnssd-requirements-00.txt To: Stuart Cheshire , Kerry Lynn A new version of I-D, draft-lynn-dnssd-requirements-00.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-dnssd-requirements Revision: 00 Title: Requirements for Scalable DNS-SD/mDNS Extensions Creation date: 2013-10-22 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-lynn-dnssd-requirements-00.txt Status: http://datatracker.ietf.org/doc/draft-lynn-dnssd-requirements Htmlized: http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00 Abstract: DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --047d7bf0d52474ef2704e949943c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings,

This draft of = the requirements is a minor update on the previous version.

No= t all of the suggestions made at the last BoF could be recovered from
the meeting notes prompts, so please start a thread using this version
a= s a basis if your comments at the BoF were not adequately addressed.
Please also note that the WG page is not set up yet, so New Ver= sion
Notifications are not automatically going out to <dnssd@ietf.org>.=A0 In
Regards, -K-


---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: Mon, Oct 21, 2013 at 7:50 = PM
Subject: New Version Notification for draft-lynn-dnssd-requirements-00.txt<= br>To: Stuart Cheshire <cheshire@a= pple.com>, Kerry Lynn <kerlyn@= ieee.org>



A new version of I-D, draft-lynn-dnssd-requirements-00.txt
has been successfully submitted by Kerry Lynn and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-lynn-dnssd-requirements
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Requirements for Scalable DNS-SD/mDNS Extensions=
Creation date: =A0 2013-10-22
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 10
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-lynn-dnssd-requirements-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc= /draft-lynn-dnssd-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ly= nn-dnssd-requirements-00


Abstract:
=A0 =A0DNS-SD/mDNS is widely used today for discovery and resolution of
=A0 =A0services and names on a local link, but there are use cases to exten= d
=A0 =A0DNS-SD/mDNS to enable service discovery beyond the local link. =A0Th= is
=A0 =A0document provides a problem statement and a list of requirements.



Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7bf0d52474ef2704e949943c-- From ajs@anvilwalrusden.com Mon Oct 21 19:50:23 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562CD11E810F for ; Mon, 21 Oct 2013 19:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 EI1QEwBjhzjw for ; Mon, 21 Oct 2013 19:50:18 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9A10C11E80F5 for ; Mon, 21 Oct 2013 19:50:18 -0700 (PDT) Received: from crankycanuck.ca (unknown [203.83.33.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D251E8A031 for ; Tue, 22 Oct 2013 02:50:16 +0000 (UTC) Date: Mon, 21 Oct 2013 22:50:13 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20131022025012.GB7319@crankycanuck.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dnssd] request for review [internet-drafts@ietf.org: New Version Notification for draft-sullivan-dnssd-label-miprofile-00.txt] X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 02:50:23 -0000 Dear colleagues, One of the issues I've raised more than once has to do with the way resolultion of names in the DNS and resolution of names under mDNS are different in practice, particularly as applications and even OSes use IDNA2008. The draft mentioned below is an effort to suggest a common, interoperable subset of label patterns that would permit seamless use of a given name in mDNS and DNS. It's particularly written with an eye to internationalization, though that's not the only possible area where there's an issue. As I understand it, the actual lookup mechanism for DNS-SD is outside of our charter, so this draft is strictly off-topic for the WG. I'm only posting this here as a solicitation for feedback. If you have comments, please send them directly to me. Thanks, A ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sat, 19 Oct 2013 12:20:19 -0700 From: internet-drafts@ietf.org To: Andrew Sullivan Subject: New Version Notification for draft-sullivan-dnssd-label-miprofile-00.txt A new version of I-D, draft-sullivan-dnssd-label-miprofile-00.txt has been successfully submitted by Andrew Sullivan and posted to the IETF repository. Filename: draft-sullivan-dnssd-label-miprofile Revision: 00 Title: Using Labels With DNS-Based Service Discovery, mDNS, and DNS Creation date: 2013-10-18 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-sullivan-dnssd-label-miprofile-00.txt Status: http://datatracker.ietf.org/doc/draft-sullivan-dnssd-label-miprofile Htmlized: http://tools.ietf.org/html/draft-sullivan-dnssd-label-miprofile-00 Abstract: Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Different name systems use different conventions for the characters allowed in any name. In order for DNS-SD to be used effectively in environments where multiple different name systems are in use, it is important to follow a common set of conventions for naming. This memo presents a convention for maximizing such interoperability. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----- End forwarded message ----- -- Andrew Sullivan ajs@anvilwalrusden.com From kerlyn2001@gmail.com Thu Oct 24 12:40:26 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEC311E8210 for ; Thu, 24 Oct 2013 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 nAwlSYIYRuWW for ; Thu, 24 Oct 2013 12:40:22 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD7411E8152 for ; Thu, 24 Oct 2013 12:40:22 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id k14so2942776oag.29 for ; Thu, 24 Oct 2013 12:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=wODHZxSTN5k8Wwo6DZ8Cg2/Seyh1wQ2hDuQvCd8rQLo=; b=PIR71NdIrypEQ8L3oUm4IPZGWYWzeL0wQtLCu9XrmUE+/5E+g/InKBcGdpKq7GUA5m sI7dgYuD+ACrxu1fqtqX16XW+XlHDOJPabdeYkqzhUviZFXAobWG3BWb39C/Kw1Oq1rc xSKkAeT3QBSrMSl7BfpiscJBbiOtHgiw1Be7LLlNmnq3VONsdwUtnupRxVCwxxEn3sAr z+mqtagsmaTcuU69S+NwtkqN7J7XKAuRKydaL3Ih+9pxKEHdgY0iP6RF7NNlGNU1QhqS iZXSwd3CIaEF7fnHBzFRbY01rbD4el0Fv9NLNnQywCgNk2KstOYXAJpIIvKsyJkEqzyE /+Bg== MIME-Version: 1.0 X-Received: by 10.182.215.202 with SMTP id ok10mr2727835obc.62.1382643620736; Thu, 24 Oct 2013 12:40:20 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Thu, 24 Oct 2013 12:40:20 -0700 (PDT) Date: Thu, 24 Oct 2013 15:40:20 -0400 X-Google-Sender-Auth: b-e1g4XvvXbE74PnOcvfopL6WDA Message-ID: From: Kerry Lynn To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=001a11c24a52dd789704e981cdc3 Subject: [dnssd] Discovery Scope(s) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:40:26 -0000 --001a11c24a52dd789704e981cdc3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Greetings, I'd like to prompt some discussion of Discovery Scope(s) in advance of the dnssd WG meeting. I know there was discussion of this at the last BoF but I attended remotely and didn't get a feeling for any consensus. So please, add your comments below or add new issues to this thread. I would ultimately like the WG to prioritize the requirements in order of importance. I think this will help us to resolve the inevitable tradeoffs. So how does this one rank for you? Currently, http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00 REQ3 states: For use cases D and E, there should be a way to configure the scope of the discovery and also support both smaller (ex: department) and larger (ex: campus-wide) discovery scopes. I think this requirement is driven primarily by building control applications http://tools.ietf.org/html/draft-vanderstok-dnssd-building-requirements-00. For example, it is easy to imagine wanting to control all of the lights in = a room/floor/building. - How important is this requirement in other applications? - How would it be accomplished in normal DNS? - What are the various ways this could be implemented with DNS-SD/mDNS extensions? - What is the additional configuration burden, if any? - Is the perceived benefit of this feature worth the extra cost (measured a= s config burden, extra code, or other metrics)? I also became aware after the draft update was submitted that Dave Thaler and Ralph Droms had a sidebar on this topic during the BoF: RD: 3a) There should be multiple, potentially orthogonal, scopes? DT: =93multiple=94 is ambiguous. What are the requirements? 2? Arbitrary number? E.g. if you have 1000 custom scopes (say one per person in an organization) is that ok? Is the *ability* to nest required to support if one desires? If so, how many levels of nesting must be supported? RD: 3b) Scopes should be definable on geographic or organizational boundaries? DT: ...or topological boundaries=85 ? RD: 3c) The scope or scopes into which a discoverable entity is placed should be configurable by the network administrator, the entity or the user? DT: Re 3b and c. Can the advertiser configure their own scope or are they limited to scopes predefined by a network admin? Are these the right questions? Are we missing any? Other thoughts on the topic? Thanks, -K- --001a11c24a52dd789704e981cdc3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Greetings,

I'd l= ike to prompt some discussion of Discovery Scope(s) in advance of the
dn= ssd WG meeting.=A0 I know there was discussion of this at the last BoF but<= br>
I attended remotely and didn't get a feeling for any consens= us.=A0 So please,
add your comments below or add new issues t= o this thread.

I would ultimately like the WG to prioriti= ze the requirements in order of
importance.=A0 I think this will help us to resolve the inevitab= le tradeoffs.=A0 So
how does this one rank for you?


Currently, http://tools.ietf.org/html/dra= ft-lynn-dnssd-requirements-00
REQ3 states:

=A0=A0=A0 =A0=A0=A0 For use cases D and E, there should= be a way to configure the
=A0=A0=A0=A0=A0=A0=A0 scope of the discovery = and also support both smaller (ex:
=A0=A0=A0=A0=A0=A0=A0 department) and= larger (ex: campus-wide) discovery scopes.


I think this requirement is driven primarily by building= control applications
http://tools.ietf.org/html/= draft-vanderstok-dnssd-building-requirements-00.
For example, it is easy to imagine wanting to control all of the lights in = a
room/floor/building.

- How important is this requirement in other appl= ications?

- How would it be accomplished in normal DNS?
<= /font>- What are the various ways this could be implemented with DNS-SD/mDN= S
=A0 extensions?

- What is the additional confi= guration burden, if any?

- Is the perceived benefit of th= is feature worth the extra cost (measured as
=A0 config burde= n, extra code, or other metrics)?


I also became aware after the draft update was sub= mitted that Dave Thaler
and Ralph Droms had a sidebar on this topi= c during the BoF:

RD: 3a) There should be multiple= , potentially orthogonal, scopes?
DT: =93multiple=94 is ambiguous.=A0 What are the requirements?=A0 2?=A0 Arbitrary number? E.g. if you have 1000 custom scopes (say one per person in an organization)=20 is
that ok?=A0=A0 Is the *ability* to nest required to support if one=20 desires?=A0 If so, how
many levels of nesting must be supported?

=
RD: 3b) Scopes should be defina= ble on geographic or organizational boundaries?
DT: ...or= topological boundaries=85 ?

RD: 3c) The sco= pe or scopes into which a=20 discoverable entity is placed should
be configurable by the network=20 administrator, the entity or the user?
DT: Re 3b= and c.=A0 Can the advertiser configure their own scope or are they limited= to scopes predefined by a network admin?


Are these the right questions?=A0 Are we missing any?=A0= Other thoughts on the topic?

Thanks, -K-
--001a11c24a52dd789704e981cdc3-- From kerlyn2001@gmail.com Thu Oct 24 12:40:27 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4319511E8152 for ; Thu, 24 Oct 2013 12:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 ArhDd0yJU8zN for ; Thu, 24 Oct 2013 12:40:26 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id EA1F511E8209 for ; Thu, 24 Oct 2013 12:40:23 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id n12so2852005oag.26 for ; Thu, 24 Oct 2013 12:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=/XyaIu4WEjck+gX93ju6Rk4WWurAU6YTxQm6fJrPymQ=; b=jSTx5ztH7uETIDXDDf4njoluJBmH5iY0wghNLy1qQ+CBjzoqgOfiVEODNMpOujLqRE XNtnLDKfuKauun4i8qQgXKLxuTwrugmgOiQYV4FZejn//4t6gh9EhAo/78zh8bGhrE6+ xS8ddUs091jDI3OkWNBQ1Ctpp6t4S2lHCZgrYAgXQo5BD4e+UKP3w6Gwaj1NxcjcJBTD uqBSngLYrTXjm8OMZCqToabya3ARV16qRQn5dCztcTmiwX6lEYNUZLW2/p/wPJVhPTaa Sc+bBX2iWDrhm5+jMc+cu0NrWGdqjjqZBzFGm0448uMlKohCoIcolYbbRSWVq0hzNfkd w5Dw== MIME-Version: 1.0 X-Received: by 10.182.38.228 with SMTP id j4mr325036obk.94.1382643623101; Thu, 24 Oct 2013 12:40:23 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.73.6 with HTTP; Thu, 24 Oct 2013 12:40:23 -0700 (PDT) Date: Thu, 24 Oct 2013 15:40:23 -0400 X-Google-Sender-Auth: jhoz61iZOpoWJ2y4wNsSkc6iwlU Message-ID: From: Kerry Lynn To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=001a11c2f3a6018e7404e981ceb7 Subject: [dnssd] Security Issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:40:28 -0000 --001a11c2f3a6018e7404e981ceb7 Content-Type: text/plain; charset=ISO-8859-1 Greetings, I'd like to prompt some discussion of Security Issues in advance of the dnssd WG meeting. I expect the security requirements will expand well beyond what's in the current draft: http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00 I'd like us to thoroughly understand the security implications of DNS-SD/ mDNS extensions, but also to be mindful about which problems we address and how. I added a few paragraphs to the current draft based mainly on off-list conversations: DNSSEC can assert the validity but not the veracity of records in a zone file. The trust model of the global DNS relies on the fact that human administrators either a) manually enter resource records into a zone file, or b) configure the DNS server to authenticate a trusted device (e.g., a DHCP server) that can automatically maintain such records. By contrast, the "plug-and-play" nature of mDNS devices has up to now depended only on physical connectivity. If a device is visible via mDNS then it is assumed to be trusted. This is no longer likely to be the case in larger networks. Still, the new solution SHOULD leverage existing security solutions and not invent new ones. Mobile devices such as smart phones that can expose the location of their owners by registering services in arbitrary zones pose a risk to privacy. Such devices MUST NOT register their services in arbitrary zones without the approval of their operators. However, it SHOULD be possible to configure one or more "home" zones, e.g., based on subnet prefix, in which mobile devices may automatically register their services. Are there other significant topics that we are missing from the current draft? Thanks, -K- --001a11c2f3a6018e7404e981ceb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Greetings,

I'd like to prompt some discuss= ion of Security Issues in advance of the
dnssd WG meeting.=A0 I expect t= he security requirements will expand well
beyond what's in the curre= nt draft:
http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00<= /a>

off-list conversations:
   DNSSEC can =
assert the validity but not the veracity of records in a
   zone file.  The trust model of the global DNS relies on the fact that
   human administrators either a) manually enter resource records into a
   zone file, or b) configure the DNS server to authenticate a trusted
   device (e.g., a DHCP server) that can automatically maintain such
   records.

   By contrast, the "plug-and-play" nature of mDNS devices has up=
 to now
   depended only on physical connectivity.  If a device is visible via
   mDNS then it is assumed to be trusted.  This is no longer likely to
   be the case in larger networks.  Still, the new solution SHOULD
   leverage existing security solutions and not invent new ones.

   Mobile devices such as smart phones that can expose the location of
   their owners by registering services in arbitrary zones pose a risk
   to privacy.  Such devices MUST NOT register their services in
   arbitrary zones without the approval of their operators.  However, it
   SHOULD be possible to configure one or more "home" zones, e.g.=
, based
   on subnet prefix, in which mobile devices may automatically register
   their services.


Are there other signifi=
cant topics that we are missing from the current draft?

Thanks, -K-
--001a11c2f3a6018e7404e981ceb7-- From mcr+ietf@sandelman.ca Fri Oct 25 05:58:02 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D8E11E818B for ; Fri, 25 Oct 2013 05:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[AWL=0.153, 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 wFCzCNG0fL6l for ; Fri, 25 Oct 2013 05:58:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BFDCE11E82F4 for ; Fri, 25 Oct 2013 05:57:43 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B2B4E201B0; Fri, 25 Oct 2013 10:08:38 -0400 (EDT) From: Michael Richardson To: Kerry Lynn In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.5; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Cc: dnssd@ietf.org Subject: Re: [dnssd] Discovery Scope(s) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 12:58:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kerry Lynn wrote: > I'd like to prompt some discussion of Discovery Scope(s) in advance of > the dnssd WG meeting.=C2=A0 I know there was discussion of this at th= e last > BoF but I attended remotely and didn't get a feeling for any > consensus.=C2=A0 So please, add your comments below or add new issues= to > this thread. > I would ultimately like the WG to prioritize the requirements in order > of importance.=C2=A0 I think this will help us to resolve the inevita= ble > tradeoffs.=C2=A0 So how does this one rank for you? > Currently, http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00 > REQ3 states: > =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 For use cases D and E, there sh= ould be a way to configure the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scope of the discovery and= also support both smaller (ex: > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 department) and larger (ex= : campus-wide) discovery scopes. When you say "discovery scopes" I think of two things, and this might be a result of the "scope 3" discussion over in ROLL. a) how far would the service request travel. (this is a plumbing question) b) what devices would reply because they believe they are in scope. I think you mean (b), but I wonder if your question doesn't have some of (a) in it as well. The two boundaries may often coinside, particularly for the "site" boundary. For the floor/department boundary might be very different: a printer located on the floor, shared by two departments, might on in the *building* LAN, but configured to answer queries from either department's discovery scope. > I think this requirement is driven primarily by building control > applications > For example, it is easy to imagine wanting to control all of the ligh= ts > in a room/floor/building. First, that's use case F, which true, does include C,D and E. Second, I don't think building control is the primary concern. That's because in enterprise/commercial buildings, I think that there will be few direct connections to buildings from departments (they will go through a gateway. Finding that *gateway* is in scope) I think it's about finding a printer in your building/floor, or the appropriate service proxy of some sort. > - How would it be accomplished in normal DNS? How would *I* build this in normal DNS? Some series of SRV records that I'm not awake enough to write leading to: _lights.floor1.site12.locationB.example.com IN AAAA FF05::dead:beef e.g: I think that I would have a site-wite multicast address for each floor. If instead, there was a controller that I should talk to, it would list itself as a unicast address. It might be good if we used the term "discovery scope" =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUmpqvoqHRg3pndX9AQLPsQP/eYr14gBxA+N/3WUXv1nIKQ+E8S4FlzOL PaewoGAeFvK6NF/DiSkRqRY8fEnA+n+XGiATI+XpNasx0Uwcf/dbej1o3ssUlGHu 0Yt5lGtNS5TdCg3YkkCOMY5GuH1h2sTyv+2oDiiMMHTMrEFEgO+knlZfrtM7qow+ l/7NY+2qKGU= =t68y -----END PGP SIGNATURE----- --=-=-=-- From mcr+ietf@sandelman.ca Fri Oct 25 06:17:18 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D9911E83AF for ; Fri, 25 Oct 2013 06:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.142, 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 RSBhO+d-r3Xb for ; Fri, 25 Oct 2013 06:17:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BFAF911E83F4 for ; Fri, 25 Oct 2013 06:17:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E683201B0; Fri, 25 Oct 2013 10:28:16 -0400 (EDT) From: Michael Richardson To: Kerry Lynn In-Reply-To: References: X-Mailer: MH-E 8.2; nmh 1.5; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Cc: dnssd@ietf.org Subject: Re: [dnssd] Security Issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 13:17:18 -0000 --=-=-= Kerry Lynn wrote: > Mobile devices such as smart phones that can expose the location of > their owners by registering services in arbitrary zones pose a risk to > privacy. Such devices MUST NOT register their services in arbitrary > zones without the approval of their operators. However, it SHOULD be > possible to configure one or more "home" zones, e.g., based on subnet > prefix, in which mobile devices may automatically register their > services. I don't think this quite goes far enough. I think that when one configures a "home" zone, that one also has to configure what services appear, and by what name. The device might well be told to configure and announce it's services under some either deterministic or pseudo-random name. For instance, my device could well present it's offer of a chess match under the name, "purple-bearded-guy-in-window" when I'm in the StarBucks' at 5th Avenue and Broadway. But, at the StarBucks' where AA meets, I'm "wishIwassober435234", and the number changes every time. While this sounds like a device specific feature, and not a protocol concern, there are some important IPv6 privacy extensions ideas which need to be brought up a layer here. In particular, it might be appropriate to bind the service announcement to a long-lived, but private address which is reused. (draft-rafiee-6man-ssas might be useful) -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUmpvWIqHRg3pndX9AQJSBwP6AsWvCg64kP2J8m5g2bVWXEOH8/XeGAYE NqaF7cwV5PS8tLkPMgmT2NJyrln3i1XO0aQ6ItOkdylo8O2xokL2qQdJuQA4pTbW uM/vZf8ksC+jV+al0l28tEGIw6avr7uvzDLtzl8JpJdwPHvokIaroEvelwz9azAV G9LDUujUOfs= =c+9/ -----END PGP SIGNATURE----- --=-=-=-- From iesg-secretary@ietf.org Fri Oct 25 10:06:47 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FA311E8327; Fri, 25 Oct 2013 10:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 pc0zAq+m-JmZ; Fri, 25 Oct 2013 10:06:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C743011E8330; Fri, 25 Oct 2013 10:06:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.81 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131025170640.20750.43877.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2013 10:06:40 -0700 Cc: dnssd WG Subject: [dnssd] WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:06:48 -0000 A new IETF working group has been formed in the Internet Area. For additional information please contact the Area Directors or the WG Chairs. Extensions for Scalable DNS Service Discovery (dnssd) ------------------------------------------------ Current Status: Proposed WG Chairs: Ralph Droms Tim Chown Assigned Area Director: Ted Lemon Mailing list Address: dnssd@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd Archive: http://www.ietf.org/mail-archive/web/dnssd Charter: Background ---------- Zero configuration networking protocols are currently well suited to discover services within the scope of a single link. In particular, the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes referred to using Apple Computer Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery and host name resolution on a single link. The DNS-SD/mDNS protocol suite is used in many scenarios including home, campus, and enterprise networks. However, the zero configuration mDNS protocol is constrained to link-local multicast scope by design, and therefore cannot be used to discover services on remote links. In a home network that consists of a single (possibly bridged) link, users experience the expected discovery behavior; available services appear because all devices share a common link. However, in multi-link home networks (as envisaged by the homenet WG) or in routed campus or enterprise networks, devices and users can only discover services on the same link, which is a significant limitation. This has led to calls, such as the Educause petition, to develop an appropriate service discovery solution to span multiple links or to perform discovery across a wide area, not necessarily on directly connected links. In addition, the "Smart Energy Profile 2 Application Protocol Standard", published by ZigBee Alliance and HomePlug Powerline Alliance specifies the DNS-SD/mDNS protocol suite as the basis for its method of zero configuration service discovery. However, its use of wireless mesh multi-link subnets in conjunction with traditional routed networks will require extensions to the DNS-SD/mDNS protocols to allow operation across multiple links. The scenarios in which multi-link service discovery is required may be zero configuration environments, environments where administrative configuration is supported, or a mixture of the two. As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship proprietary solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towards producing a single, standards-based solution. Working Group Description ------------------------- The focus of the WG is to develop a solution for extended, scalable DNS-SD. This work is likely to highlight problems and challenges with naming protocols, as some level of coexistence will be required between local zero configuration name services and those forming part of the global DNS. It is important that these issues are captured and documented for further analysis; solving those problems is however not within the scope of this WG. The WG will consider the tradeoffs between reusing/extending existing protocols and developing entirely new ones. It is highly desirable that any new solution is backwardly compatible with existing DNS-SD/mDNS deployments. Any solution developed by the dnssd WG must not conflict or interfere with the operation of other zero-configuration service and naming protocols such as uPnP or LLMNR. Integration with such protocols is out of scope for this WG. Current zero configuration discovery protocols are constrained to operate within a single link, which implicitly limits the scope of discovery. In extending service discovery protocols to operate over multiple links, devices will inherently become discoverable over a wider area, which may introduce security or privacy concerns. The WG will consider such concerns when exploring the solution space for multi-link service discovery. To that end, the primary goals of the dnssd WG are as follows: 1. To document a set of requirements for scalable, autonomous DNS-based service discovery in routed, multi-link networks in the following five scenarios: (A) Personal Area networks, e.g., one laptop and one printer. This is the simplest example of a service discovery network, and may or may not have external connectivity. (B) Home networks, as envisaged by the homenet WG, consisting of one or more exit routers, with one or more upstream providers or networks, and an arbitrary internal topology with heterogeneous media where routing is automatically configured. The home network would typically be a single zero configuration administrative domain with a relatively limited number of devices. (C) Wireless 'hotspot' networks, which may include wireless networks made available in public places, or temporary or permanent infrastructures targeted towards meeting or conference style events, e.g., as provided for IETF meetings. In such environments other devices may be more likely to be 'hostile' to the user. (D) Enterprise networks, consisting of larger routed networks, with large numbers of devices, which may be deployments spanning over multiple sites with multiple upstreams, and one more more administrative domains (depending on internal administrative delegation). The large majority of the forwarding and security devices are configured. These may be commercial or academic networks, with differing levels of administrative control over certain devices on the network, and BYOD devices commonplace in the campus scenario. (E) Mesh networks such as RPL/6LoWPAN, with one or more links per routable prefix, which may or may not have external connectivity. The topology may use technologies including 802.11 wireless, HomePlug AV and GP, and ZigBee IP. In the above scenarios, the aim is to facilitate service discovery across the defined site. It is also desirable that a user or device, when away from such a site, is still able to discover services within that site, e.g. a user discovering services in their home network while remote from it. It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a specified scope or advertisement within a specified scope, and being able to discover (enumerate) the set of scopes such that an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus might have no correlation to network topology. 2. To develop an improved, scalable solution for service discovery that can operate in multi-link networks, where devices may be in neighboring or non-neighboring links, applicable to the scenarios above. The solution will consider tradeoffs between reusing/extending existing protocols and developing entirely new protocols. The solution should include documentation or definition of the interfaces that can be implemented, separately to transport of the information. 3. To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. It is important that the dnssd WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the dnssd WG, but coordination between the WGs is desirable. Milestones: Sep 2013 - Formation of the WG Oct 2013 - Adopt requirements draft as WG document Jan 2014 - Submit requirements draft to the IESG as an Informational RFC Mar 2014 - Adopt wide-area service discovery solution draft as WG document Mar 2014 - Adopt Informational document on the problems and challenges arising for zeroconf and unicast DNS name services Sep 2014 - Submit wide-area service discovery solution draft to the IESG as Standards Track RFC Sep 2014 - Submit the zeroconf and unicast DNS "problems and challenges" draft to the IESG as Informational. From tjc@ecs.soton.ac.uk Sun Oct 27 09:02:52 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D069E21F9D9C for ; Sun, 27 Oct 2013 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 f4Pb7c9nZFFT for ; Sun, 27 Oct 2013 09:02:52 -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 3A0A021E80F8 for ; Sun, 27 Oct 2013 09:02:31 -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 r9RG2RAU015028 for ; Sun, 27 Oct 2013 16:02:27 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9RG2RAU015028 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382889747; bh=WqREQPY4DU4IIN41zj6hGNXLVow=; h=From:Subject:Date:To:Mime-Version:References; b=ZCSfGl488RCXPlv9fJzPHAhUWM0fLNAXVjHPxWydPtunNyVtxMmfXC4uNg+6mqBja gLrCS9eOEtle0Y7FnPLQl8TAx93zG0MiUSjKJ3A8AJoM4w+aYyLJMTeIS0Gm2ef9ZV hzMlYxnBEnYNxMWch2bwxHXGg0fOlICW7ijcLWkQ= 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 (valid=N/A) id p9QG2R0959618777vC ret-id none; Sun, 27 Oct 2013 16:02:27 +0000 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9RG2NK0016390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 27 Oct 2013 16:02:24 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5" Message-ID: Date: Sun, 27 Oct 2013 16:02:21 +0000 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p9QG2R095961877700; tid=p9QG2R0959618777vC; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r9RG2RAU015028 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [dnssd] WG tools page set up X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 16:02:52 -0000 --Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, The dnssd WG tools page is now available at: http://tools.ietf.org/wg/dnssd/ Authors of individual drafts have been kind enough to renam their = drafts, such that they automatically get listed here. I will ask for = these to be linked back to the previously named versions where = necessary. Many thanks as ever to Henrik and the tools team. Tim= --Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,

The dnssd WG tools page is now available at:

Authors of individual drafts have been kind enough to renam their drafts, such that they automatically get listed here.  I will ask for these to be linked back to the previously named versions where necessary.

Many thanks as ever to Henrik and the tools team.

Tim
--Apple-Mail=_C931A122-0B9D-4308-A3D4-223B69F757E5-- From tjc@ecs.soton.ac.uk Sun Oct 27 13:57:33 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB411E82BA for ; Sun, 27 Oct 2013 13:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 gi+4ABt6sRTy for ; Sun, 27 Oct 2013 13:57:32 -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 7DD6D11E8198 for ; Sun, 27 Oct 2013 13:57:31 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9RKvP05002442; Sun, 27 Oct 2013 20:57:25 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9RKvP05002442 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382907447; bh=uStAUku1m2E1x7kxjS06r5v6j0g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=bslEVt5JWu0VnLj2ySLUUWnC7nlelLxkVbf+U1i4zZVOTKlCSHYrC3o5zEP86O0O4 BBXyoVztfVPOi/SdFtmM0EnChlXce81jutnJa65gmAHCaUGTiKoYNADDb2ph6Ywfcw uMaZ62S5Fr5iv6mrskfu8wR3ktlim+bb8d7hVGgk= 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 (valid=N/A) id p9QKvP0959619942Hm ret-id none; Sun, 27 Oct 2013 20:57:26 +0000 Received: from [192.168.1.107] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9RKvKBt016958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Oct 2013 20:57:21 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: <13195.1382705857@obiwan.sandelman.ca> Date: Sun, 27 Oct 2013 20:57:16 +0000 Message-ID: References: <13195.1382705857@obiwan.sandelman.ca> <98F72E79-E703-43CE-81DF-41414D3CCCFF@ecs.soton.ac.uk> To: Michael Richardson X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p9QKvP095961994200; tid=p9QKvP0959619942Hm; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r9RKvP05002442 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Kerry Lynn , dnssd@ietf.org Subject: Re: [dnssd] Discovery Scope(s) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 20:57:33 -0000 --Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Thanks for starting this discussion Kerry. On 25 Oct 2013, at 13:57, Michael Richardson = wrote: > Kerry Lynn wrote: >=20 >> Currently, = http://tools.ietf.org/html/draft-lynn-dnssd-requirements-00 >> REQ3 states: >=20 >> For use cases D and E, there should be a way to configure the >> scope of the discovery and also support both smaller (ex: >> department) and larger (ex: campus-wide) discovery scopes. >=20 > When you say "discovery scopes" I think of two things, and this might = be a > result of the "scope 3" discussion over in ROLL. Here, I'd refer the discussion to the Charter, which says: "It is also desirable that multiple discovery scopes are supported, from the point of view of either performing discovery within a=20 specified scope or advertisement within a specified scope, and=20 being able to discover (enumerate) the set of scopes such that=20 an application could then choose to do either. It should be noted that scope in this sense might refer to 'building' or 'room' and thus=20 might have no correlation to network topology." So that sets the context. Which I think means REQ3 isn't sufficient. > a) how far would the service request travel. (this is a plumbing = question) > b) what devices would reply because they believe they are in scope. > I think you mean (b), but I wonder if your question doesn't have some = of > (a) in it as well. >=20 > The two boundaries may often coinside, particularly for the "site" = boundary. > For the floor/department boundary might be very different: a printer > located on the floor, shared by two departments, might on in the = *building* > LAN, but configured to answer queries from either department's = discovery > scope. Right, should we be saying that scope can be expressed in terms of = physical space (e.g., the same room), or administratively (e.g., the = same department) rather than being treated similarly to multicast = propagation? This is what the Charter implies. >> I think this requirement is driven primarily by building control >> applications >=20 >> For example, it is easy to imagine wanting to control all of the = lights >> in a room/floor/building. >=20 > First, that's use case F, which true, does include C,D and E. > Second, I don't think building control is the primary concern. > That's because in enterprise/commercial buildings, I think that there > will be few direct connections to buildings from departments (they = will go > through a gateway. Finding that *gateway* is in scope) Our university has some "interesting" ways of plumbing/trunking VLANs. = I'm not sure what assumptions it's safe to make. > I think it's about finding a printer in your building/floor, or the > appropriate service proxy of some sort. Or a display in the same room. Or a printer in the room you're going = to. Or perhaps web information about a department. >> - How would it be accomplished in normal DNS? >=20 > How would *I* build this in normal DNS? > Some series of SRV records that I'm not awake enough to write leading = to: > _lights.floor1.site12.locationB.example.com IN AAAA FF05::dead:beef >=20 > e.g: I think that I would have a site-wite multicast address for each = floor. > If instead, there was a controller that I should talk to, it would = list > itself as a unicast address. Treading a bit into solution space... > It might be good if we used the term "discovery scope" OK, but as per charter we also need to consider the advertisement scope = as well as the discovery scope. Tim > -- > Michael Richardson , Sandelman Software Works >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Thanks for starting this = discussion Kerry.

On 25 Oct 2013, at 13:57, = Michael Richardson <mcr+ietf@sandelman.ca> = wrote:

Kerry Lynn <kerlyn@ieee.org> = wrote:

Currently, http:= //tools.ietf.org/html/draft-lynn-dnssd-requirements-00
REQ3 = states:

    =     For use cases D and E, there should be a way to = configure the
        scope of the = discovery and also support both smaller = (ex:
        department) and = larger (ex: campus-wide) discovery scopes.

When you = say "discovery scopes" I think of two things, and this might be = a
result of the "scope 3" discussion over in = ROLL.

Here, I'd refer the discussion to = the Charter, which says:

"It is also desirable that multiple = discovery scopes are supported,
from the point of view of = either performing discovery within a 
specified scope or = advertisement within a specified scope, and 
being = able to discover (enumerate) the set of scopes such that 
an = application could then choose to do either. It should be noted
that = scope in this sense might refer to 'building' or 'room' and = thus 
might have no correlation to network = topology."

So that = sets the context.  Which I think means REQ3 isn't = sufficient.

a) how far would the = service request travel. (this is a plumbing question)
b) what devices = would reply because they believe they are in scope.
I think you mean = (b), but I wonder if your question doesn't have some of
(a) in it as = well.

The two boundaries may often coinside, particularly for the = "site" boundary.
For the floor/department boundary might be very = different: a printer
located on the floor, shared by two departments, = might on in the *building*
LAN,  but configured to answer = queries from either department's = discovery
scope.

Right, should we be = saying that scope can be expressed in terms of physical space (e.g., the = same room), or administratively (e.g., the same department) rather than = being treated similarly to multicast propagation?  This is what the = Charter implies.

I think this requirement is = driven primarily by building = control
applications

For = example, it is easy to imagine wanting to control all of the = lights
in a room/floor/building.

First, that's = use case F, which true, does include C,D and E.
Second, I don't think = building control is the primary concern.
That's because in = enterprise/commercial buildings, I think that there
will be few = direct connections to buildings from departments (they will = go
through a gateway. Finding that *gateway* is in = scope)

Our university has some = "interesting" ways of plumbing/trunking VLANs.  I'm not sure what = assumptions it's safe to make.

I = think it's about finding a printer in your building/floor, or = the
appropriate service proxy of some = sort.

Or a display in the same room. =  Or a printer in the room you're going to.  Or perhaps web = information about a department.


--
Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software = Works


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

= --Apple-Mail=_45A99785-7424-421E-A919-08172EDB33A3-- From tjc@ecs.soton.ac.uk Sun Oct 27 14:46:30 2013 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B20A11E81CC for ; Sun, 27 Oct 2013 14:46:29 -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=[AWL=0.000, 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 ybcdytolDnes for ; Sun, 27 Oct 2013 14:46:28 -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 45CF011E82AA for ; Sun, 27 Oct 2013 14:46:02 -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 r9RLjt24011295; Sun, 27 Oct 2013 21:45:55 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r9RLjt24011295 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1382910355; bh=Uy+31Oh/0RhONoxW2NzTpfBSbrY=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=afofVm35Bg7bu6Y77Z3ATV1B8A2ZdoOkouQ2AL2a5Rqjbtf2d5mvYeADHxSJ0oocQ 5FqZlV3ZIdpA0NsnV5PI+mOJwANYrdTnqawmdO6pQ+5zSP8SDykBgJAP0CKpc1xmEv 3UrLuBdG6JYkqOkpQKcbP6CCvoQcJxpx2zlvmncg= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p9QLjy09596201327g ret-id none; Sun, 27 Oct 2013 21:45:55 +0000 Received: from [192.168.1.107] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r9RLjnIM028473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 27 Oct 2013 21:45:50 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: <17163.1382707034@obiwan.sandelman.ca> Date: Sun, 27 Oct 2013 21:45:49 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <17163.1382707034@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p9QLjy095962013200; tid=p9QLjy09596201327g; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r9RLjt24011295 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Kerry Lynn , dnssd@ietf.org Subject: Re: [dnssd] Security Issues X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Oct 2013 21:46:30 -0000 Hi, Again, thanks for starting the discussion Kerry. On 25 Oct 2013, at 14:17, Michael Richardson = wrote: > Kerry Lynn wrote: >> Mobile devices such as smart phones that can expose the location of >> their owners by registering services in arbitrary zones pose a risk = to >> privacy. Such devices MUST NOT register their services in arbitrary >> zones without the approval of their operators. However, it SHOULD be >> possible to configure one or more "home" zones, e.g., based on subnet >> prefix, in which mobile devices may automatically register their >> services. >=20 > I don't think this quite goes far enough. A reminder of the charter text for this subject, to frame the = discussion: "Current zero configuration discovery protocols are constrained to operate within a single link, which implicitly limits the scope of discovery. In extending service discovery protocols to operate over multiple links, devices will inherently become discoverable over a wider area, which may introduce security or privacy concerns. The WG will consider such concerns when exploring the solution space for multi-link service discovery." > I think that when one configures a "home" zone, that one also has to > configure what services appear, and by what name. >=20 > The device might well be told to configure and announce it's services = under > some either deterministic or pseudo-random name. >=20 > For instance, my device could well present it's offer of a chess match > under the name, "purple-bearded-guy-in-window" when I'm in the = StarBucks' > at 5th Avenue and Broadway. But, at the StarBucks' where AA meets, > I'm "wishIwassober435234", and the number changes every time. >=20 > While this sounds like a device specific feature, and not a protocol = concern, > there are some important IPv6 privacy extensions ideas which need to = be > brought up a layer here. In particular, it might be appropriate to = bind > the service announcement to a long-lived, but private address which is > reused. (draft-rafiee-6man-ssas might be useful) So one thing here is that, as per Charter, we have the notion of = discovery scope and advertisement scope, and an API to allow an = application to control that. So part of that could be a cautious = default advertisement scope, for example. =20 As was pointed out in IESG charter review, there's the potential for a = vendor device to try to harvest information about devices over a much = bigger scope than previously. Kerry has captured this in one of his = paragraphs, but maybe it could be made more explicit, The homenet view might be, for example, devices in the guest net only by = default discovering other devices in the guest net.=20 We also need to be careful about how far we stray towards naming issues, = but I agree the ability to choose a name depending on locale may be = useful. There's also the potential for a device to have a "nice name", = stored on the device, like "Home Office Printer", as well as its network = name. I suggest we document the above considerations, so we have a record that = they have been considered, regardless of whether they are deemed = significant when we distill the resulting requirements. Tim=