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 9A0DB21F997B for ; Wed, 31 Jul 2013 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRsowMNpalIe for ; Wed, 31 Jul 2013 08:41:33 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C638B21F9702 for ; Wed, 31 Jul 2013 08:41:32 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so1611289obc.24 for ; Wed, 31 Jul 2013 08:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9z54Tu3NmXUNV4M+w3gXXb8D8PytuP4Ir0PIhb3dBsA=; b=Boh3txYQJjkofjawP3plLiZsKoBT7T08XpFkQMsTj24aYx/Zc7YMIfREg9I63P+RPi kSxaWf4fatLLQ9iAl2TKxKRhl8xdijglM0j/mo1mbP0cY41C1hLQbJTGcrDQzBIVWLmm 1/CqeSuGGqU0PTGTZcoEghQx0B0UEDSxQy8qbaKu8TGsxuHsQeRC8bfAvnywyDmv0Je1 POid2gGWmaQY2LgY+hKka2UCDSSW1W0Cgah/fflF6EpE1N4p9ptBxnczvv8H6jvAJu9U LBOYC57zO2qLdZaNbda/v/Tt3V5CFRHgsJZv4I38Ql0iRXe/Twi1G94S5SzaKR3RRqHW +luA== MIME-Version: 1.0 X-Received: by 10.60.38.164 with SMTP id h4mr67605438oek.22.1375285292202; Wed, 31 Jul 2013 08:41:32 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Wed, 31 Jul 2013 08:41:32 -0700 (PDT) In-Reply-To: <51F8DF87.6000209@computer.org> References: <51F8DF87.6000209@computer.org> Date: Wed, 31 Jul 2013 11:41:32 -0400 X-Google-Sender-Auth: u6nN_WocbwfYlmbRSZzGsOl-ATY Message-ID: From: Kerry Lynn To: "Charles E. Perkins" Content-Type: multipart/alternative; boundary=089e0149bf724e820b04e2d08fb6 Cc: mdnsext@ietf.org Subject: Re: [mdnsext] A few questions from a new participant 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: Wed, 31 Jul 2013 15:41:33 -0000 --089e0149bf724e820b04e2d08fb6 Content-Type: text/plain; charset=ISO-8859-1 Hi Charlie, I'll take a stab at answering your questions below... On Wed, Jul 31, 2013 at 5:57 AM, Charles E. Perkins wrote: > Hello folks, > > I've just joined the mailing list, so my questions may already have been > answered... > > - Why use the terminology "wide-area"? It usually means a large > area, much more than even the (small?) enterprise scenario under > discussion. What about re-using the terminology "site"? > > Let's begin with the distinction between DNS-SD (DNS-Based Service Discovery [RFC6763]) and mDNS (Multicast DNS [RFC6762]). DNS-SD is a conventional use of existing DNS RRs (SRV, TXT, PTR, A/AAAA) for the purpose of discovering services (which are roughly akin to service access points). The use of "wide-area" usually applies to DNS-SD, which can be deployed in any DNS zone in the Internet and is accessed using standard DNS. (However, Andrew Sullivan and others have pointed out that DNS labels must be LDH or IDNA-encoded, while DNS-SD permits arbitrary NFC UTF-8. That was the discussion around point 3 of the charter.) mDNS can be thought of as an optimized transport for DNS-SD, but it is really more than that. Unlike DNS, it will return *all* the relevant RRs for a particular query and operates over local links using link-local mcast and distributed responders. - Is it assumed that only a low volume of service discovery operations > will be initiated (per unit time)? This "builds on" the zeroconf / > single link case, but might be important to state explicitly. > > I have to go back and read the requirements draft, but a figure of merit is that the total percentage of bandwidth used for discovery on a given link should remain constant (or decrease) as the system scales across the use cases. - I guess the constraint on the number of networks has to do > with trying to limit the traffic load from multicast packets. > Is multicast assumed? > > It will probably be part of the eventual solution (especially as we have the requirement not to break current functionality) but I expect it will be relied upon to a lesser extent (or not at all) for off-link queries. HTH, -K- > -- > Regards, > Charlie P. > > ______________________________**_________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/mdnsext > --089e0149bf724e820b04e2d08fb6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie,

I'll take a stab at answering your questions below..= .

On Wed, Jul 31, 2013 at 5:57 AM, Charle= s E. Perkins <charliep@computer.org> wrote:
Hello folks,

I've just joined the mailing list, so my questions may already have bee= n answered...

- Why use the terminology "wide-area"? =A0It usually means a larg= e
=A0 area, much more than even the (small?) enterprise scenario under
=A0 discussion. =A0What about re-using the terminology "site"?
Let's begin with the distinction between DNS-SD (= DNS-Based Service
Discovery [RFC6763]) and mDNS (Multicast DNS [RFC6762]= ).=A0 DNS-SD
is a conventional use of existing DNS RRs (SRV, TXT, PTR, A= /AAAA) for
the purpose of discovering services (which are roughly akin to service
a= ccess points).=A0 The use of "wide-area" usually applies to DNS-S= D, which
can be deployed in any DNS zone in the Internet and is accessed= using
standard DNS.=A0 (However, Andrew Sullivan and others have pointed out
t= hat DNS labels must be LDH or IDNA-encoded, while DNS-SD permits
arbitra= ry NFC UTF-8.=A0 That was the discussion around point 3 of the
charter.)=

mDNS can be thought of as an optimized transport for DNS-SD, but it
= is really more than that.=A0 Unlike DNS, it will return *all* the relevant = RRs
for a particular query and operates over local links using link-loca= l mcast
and distributed responders.

- Is it assumed that only a low volume of service discovery operations
=A0 will be initiated (per unit time)? =A0This "builds on" the ze= roconf /
=A0 single link case, but might be important to state explicitly.

I have to go back and read the requirements draft, bu= t a figure of merit
is that the total percentage of bandwidth used for d= iscovery on a given
link should remain constant (or decrease) as the sys= tem scales across
the use cases.

- I guess the constraint on the number of networks has to do
=A0 with trying to limit the traffic load from multicast packets.
=A0 Is multicast assumed?

It will probably be part of the eventua= l solution (especially as we have
the requirement not to break current f= unctionality) but I expect it will be
relied upon to a lesser extent (or= not at all) for off-link queries.

HTH, -K-
=A0
--
Regards,
Charlie P.

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

--089e0149bf724e820b04e2d08fb6-- 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 1FF8521F9DB4 for ; Wed, 31 Jul 2013 02:57:42 -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 5FZEqCgcaMj4 for ; Wed, 31 Jul 2013 02:57:41 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id D896F21F9DB2 for ; Wed, 31 Jul 2013 02:57:41 -0700 (PDT) Received: from [130.129.16.71] by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1V4TA3-0002Lu-Fs for mdnsext@ietf.org; Wed, 31 Jul 2013 05:57:39 -0400 Message-ID: <51F8DF87.6000209@computer.org> Date: Wed, 31 Jul 2013 02:57:27 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: mdnsext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86e48c923e8d8dd60dbb2df405e283b782350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.16.71 Subject: [mdnsext] A few questions from a new participant 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: Wed, 31 Jul 2013 09:57:42 -0000 Hello folks, I've just joined the mailing list, so my questions may already have been answered... - Why use the terminology "wide-area"? It usually means a large area, much more than even the (small?) enterprise scenario under discussion. What about re-using the terminology "site"? - Is it assumed that only a low volume of service discovery operations will be initiated (per unit time)? This "builds on" the zeroconf / single link case, but might be important to state explicitly. - I guess the constraint on the number of networks has to do with trying to limit the traffic load from multicast packets. Is multicast assumed? -- Regards, Charlie P. 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 2EC9A21F9F21 for ; Wed, 31 Jul 2013 00:16:22 -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=[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 dDETK3OTxYEM for ; Wed, 31 Jul 2013 00:16:21 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A816221F9F5C for ; Wed, 31 Jul 2013 00:16:21 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id er7so696871obc.17 for ; Wed, 31 Jul 2013 00:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=Crmwfv9/f33rFV2fcdJ6odsyN7xF/e0nPLGaDnWfT8o=; b=oHjZ8arfqndRS5lukVZiJrtQQq1sDu+0O8kkguWu96QUn+TKbvOkWD/mcaneDchqOu utoixyHDvggtPtPavM7bDPfyx1mooFznC+Qf/f/6PXYD74OmSca9YTtTZBD39DfAi9XN ml6SQXydmGTfrNFuonawLSTs0x3Rd9kTi0/KWTrqPwJttzUsc/4PiVsvk2JJtve3XzAM SfdMIIa4cVNOXZamMC6Hei2FBMXVc066HAloFwWKBVKJ8ePoB+qsOweKmg6xKM3WYSzO XnNVs0kTE7R0nz1QUok3gqAi/xznvT70AbwkOmWpfzWQxRGnCYVMTVC4axrE56rnVQL9 H83g== MIME-Version: 1.0 X-Received: by 10.182.34.166 with SMTP id a6mr60073041obj.102.1375254981102; Wed, 31 Jul 2013 00:16:21 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Wed, 31 Jul 2013 00:16:20 -0700 (PDT) Date: Wed, 31 Jul 2013 03:16:20 -0400 X-Google-Sender-Auth: m75sqZOhHUagj7t45IVyaVPXCOc Message-ID: From: Kerry Lynn To: mdnsext@ietf.org, Ralph Droms , Tim Chown , Stuart Cheshire Content-Type: multipart/alternative; boundary=001a11c208d49fda4a04e2c98097 Subject: [mdnsext] Additional charter item for consideration 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: Wed, 31 Jul 2013 07:16:22 -0000 --001a11c208d49fda4a04e2c98097 Content-Type: text/plain; charset=ISO-8859-1 4. To consider extensions to DNS-SD that improve its suitability for M2M and/or Aggregated Services Discovery. Rationale: in the ZigBee Smart Energy Profile 2 Application Specification it became clear there was a need for 1) fine-grained discovery, e.g., of different REST APIs within a server, and 2) a discovery-based method for a host to discover its default settings for other services it depends on. Regards, -K- --001a11c208d49fda4a04e2c98097 Content-Type: text/html; charset=ISO-8859-1 4. To consider extensions to DNS-SD that improve its suitability for M2M and/or Aggregated Services Discovery.

Rationale: in the ZigBee Smart Energy Profile 2 Application Specification it became clear there was a need for
1) fine-grained discovery, e.g., of different REST APIs within a server, and 2) a discovery-based method for a
host to discover its default settings for other services it depends on.

Regards, -K-
--001a11c208d49fda4a04e2c98097-- 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 CC11021F9DBA for ; Mon, 29 Jul 2013 08:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SbXeVf+WJDF for ; Mon, 29 Jul 2013 08:19:20 -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 4226721F997B for ; Mon, 29 Jul 2013 08:19:19 -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 r6TFJFwH013370 for ; Mon, 29 Jul 2013 16:19:15 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r6TFJFwH013370 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1375111156; bh=a/MeP1Uz63SRCEBN9KID456bqTc=; h=From:Subject:Date:To:Mime-Version:References; b=079ygalF3c4EpGB4JeveEpVi6lFAn9eFIllpwe6rRjMNsCeB645StNkCWJuV9rxuQ kixItlmNeU8vTlbRfk9N2bFSkOsQMFhpw21rNX/wdbKn+X2NOrkG01bUleMl1y5IBo x4UBbrYYX0xBEO/8u6+H+SoecFcN51SDhJQpLFy4= 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 p6SGJF0544532042KV ret-id none; Mon, 29 Jul 2013 16:19:16 +0100 Received: from dhcp-4759.meeting.ietf.org (dhcp-4759.meeting.ietf.org [130.129.71.89]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r6TFHsAc013547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Jul 2013 16:17:55 +0100 From: Tim Chown Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-ID: Date: Mon, 29 Jul 2013 16:17:50 +0100 To: "mdnsext@ietf.org mdnsext" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p6SGJF054453204200; tid=p6SGJF0544532042KV; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r6TFJFwH013370 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [mdnsext] Request for minute-taker and jabber relay 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, 29 Jul 2013 15:19:23 -0000 Hi, Ralph and I would be very grateful for a volunteer to take minutes for = the dnssdext BoF on Wednesday at 9am. A jabber relay would also be very welcome. Thanks in advance, Tim= 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 AB3A721F9433 for ; Thu, 25 Jul 2013 13:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] 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 lRzHMEp6EEn6 for ; Thu, 25 Jul 2013 13:35:17 -0700 (PDT) Received: from nm1-vm7.access.bullet.mail.gq1.yahoo.com (nm1-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.179]) by ietfa.amsl.com (Postfix) with ESMTP id 69D1721F943C for ; Thu, 25 Jul 2013 13:35:16 -0700 (PDT) Received: from [216.39.60.173] by nm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000 Received: from [98.138.104.100] by tm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000 Received: from [127.0.0.1] by smtp120.sbc.mail.ne1.yahoo.com with NNFMP; 25 Jul 2013 20:35:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1374784515; bh=gFfL75VOOcFtFnI3SO4TK7carOhKF8DwLxdC3en5d0o=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=yBpXzKWXavTv63XX6T273AojozZa6B7DLjFngMNEFQZgb2/Zm5tYUgeKCZyNFspa64JGgC4ozv3WgMbfXjTNXfDp0h/vMP8cwMDtky4cEp2D2Y7W+W8cZ9wh4xQl9PBF7ClujjZJKE72J2WCS/t8rpFsIHg85kq9O7hxzseQSuI= X-Yahoo-Newman-Id: 759979.79855.bm@smtp120.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: q97k1zcVM1kP9LsDFgSrjW3oE8XDnzWrNHIO5_QVkwvUoEA xr4kwfa6T35RUxumJZe3EYHN.AEKYD8F40FfTTO1Gqzq_tRYSpEWiOt3U5q9 v1_uwDryw7.CBQ3aiGG7CT5y0LhZE11SEQ0BmPnxBxMJKFGfpN.59VhFM5Ui J_2Yez.q6n1baQ8lje8CHQOevoJirLAPQtwl.Q8Qb2bkCU29D6QCtfx9sX3U tMuGQuY.FzyF_CTUdlcAJgLbtmegYyoVkYVaO2BJKNbcqJv5GMtVEtO1R.iY nHHEQXMgXvQoddxCT5H1qWbjY3RPROxtu3HbH5c05pbiWBPM8.Ngac4VAmRU ZGQARRmBv7dCXTQoPNcR2PLJrGFgPL_8qfZ5m23ptRe3jDSxctK6HGAjxW2j BBrgPWFpW5TfwnS2iWypvSSPdZmxYnC1Rjk41YOt_RiBLwtIbsOxbMf0M2eF vLoIW.ep1HAxRIhbJFJ8H0CkF0FAb1YPB8U2byKEPf1Cnq0GKk2FLKMXzc2z bDrfU1HGZOK5QEB3HBcPSi117hNP2q8tyYw_0arYvHixbPB7SPlXPlviuRpS jzc6J.qf3SCVGg779YeimXXNpye_8NjpRsIJ8BMxi.GVWec.5NHsq6wGiM3J Kig-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.231 with login) by smtp120.sbc.mail.ne1.yahoo.com with SMTP; 25 Jul 2013 20:35:15 +0000 UTC User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Thu, 25 Jul 2013 13:35:12 -0700 From: Don Sturek To: Tim Chown Message-ID: Thread-Topic: Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0) In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Sun, 28 Jul 2013 08:31:43 -0700 Cc: mdnsext@ietf.org, Routing Over Low power and Lossy networks , "6man@ietf.org" <6man@ietf.org> Subject: [mdnsext] Discovery requirements for Smart Energy Profile 2.0 (SEP 2.0) 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, 25 Jul 2013 20:35:22 -0000 Hi Tim, Don Sturek, chair for the ZigBee Alliance Core Stack Group which developed ZigBee IP in support of Smart Energy Profile 2.0. Here is a synopsis of the requirements: 1) Support Resource Discovery over a topology that includes Wi-Fi, HomePlug AV and GP and ZigBee IP (ZigBee IP is a multi-hop solution using ROLL RPL) connected via border routers 2) No device vendor wanted responsibility for a centralized DNS or uPNP repository that would be guaranteed to exist in all deployment scenarios. Ideally then services (resources) are self describing and locate-able through client directed queries (DNS-SD was a great solution for this) 3) mDNS was a great choice then for discovery, however, due to the use of ROLL RPL (or really any multi-hop route over solution), the use of link locals would not guarantee discovery of all services (resources). Hence, the extension of mDNS with this now outdated draft (captured in the requirements Kerry created for mdnsext I believe): http://tools.ietf.org/html/draft-lynn-dnsext-site-mdns-01 The DNS-SD draft (RFC 6763) was used in our application without change. We would have welcomed the use of mDNS (RFC 6762) but that would not work with ULAs (which we had to use due to the multi-hop subnet) Again, in some settings there could be a box doing DNS (as long as that platform was good with other vendor solutions posting DNS records into it!). In some settings (where say the electricity meter is the only common platform), most utilities don't want responsibility (or the risk) in having untrusted devices posting anything to them. I like the ideas in Homenet around gathering service information into centralized DNS repositories where such a service exists. By the way, if ULA's continue to be the addressing mechanism, then there are a couple of additional issues: 1) In a border router, clear rules on the propagation of ULA prefixes (eg, which interfaces, ideally those that face inward in the site topology and not to the ISP!) 2) What to do if a border router discovers the existance of other ULA prefixes I think these topics were detailed in this old draft presented in V6OPS sometime ago: http://tools.ietf.org/html/draft-herbst-v6ops-cpeenhancements-00 Don On 7/25/13 1:11 PM, "Tim Chown" wrote: >On 25 Jul 2013, at 19:03, Don Sturek wrote: > >> Hi Ulrich, >> >> Let me say as an implementer of ROLL RPL (and Trickle Multicast) the >>topic >> of multi-link subnets and the general topic of multicast address scope >> continues to be a major concern. For example, we needed to extend mDNS >>to >> cover site specific addressing for this reason as well as need to define >> another draft describing ULA prefix delegation rules and forwarding >>rules >> for border routers (yet to be done). > >Hi, > >It would be great to get requirements for this - hopefully this can be >raised in the dnssdext BoF next week, and contributed into the >draft-lynn-mdnsext-requirements-02 work by Kerry and Stuart. Currently >the dnssdext charter includes this use case. > >Tim 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 A566A11E80D5 for ; Thu, 18 Jul 2013 00:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 eL5a1Ypj9lu2 for ; Thu, 18 Jul 2013 00:13:24 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by ietfa.amsl.com (Postfix) with ESMTP id 982F211E80AE for ; Thu, 18 Jul 2013 00:13:23 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.13.6/8.13.6) with ESMTP id r6I7DGQw027553; Thu, 18 Jul 2013 09:13:16 +0200 Received: from DEFTHW99ET9MSX.ww902.siemens.net ([157.163.148.60]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r6I7DFV2013861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Jul 2013 09:13:16 +0200 Received: from DENBGAT9ERNMSX.ww902.siemens.net (139.22.70.144) by DEFTHW99ET9MSX.ww902.siemens.net (157.163.148.60) with Microsoft SMTP Server (TLS) id 8.3.298.1; Thu, 18 Jul 2013 09:13:15 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.109]) by DENBGAT9ERNMSX.ww902.siemens.net ([139.22.70.144]) with mapi id 14.03.0146.000; Thu, 18 Jul 2013 09:13:14 +0200 From: "Albrecht, Harald" To: Kerry Lynn Thread-Topic: [mdnsext] Hierarchical (host) domain names in mDNS? Thread-Index: Ac6CGBuBlctNJJX5QF6LGwWoRFhvmQACsLGAAADkbwAAJZRPwAAKkmGAACd6q+A= Date: Thu, 18 Jul 2013 07:13:14 +0000 Message-ID: References: <20130716151444.GE23286@mx1.yitter.info> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.37] Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB5037503902C406DEFTHW99EK5MSXww9_" MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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, 18 Jul 2013 07:13:29 -0000 --_000_E36F274013087B4EA05E08EB5037503902C406DEFTHW99EK5MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, thanks for the valuable feedback. I have no problem with explicitly appendi= ng ".local.", in fact, I would even like to make this explicit, so that "lo= cal" connections also need to use "controller.machine1.local.". This way, u= sers will learn right from the start which names will trigger which resolut= ion technologies. My (negative) experience comes from experimenting with the mDNS tools in th= e Apple *nix package (if I remember correctly, the exact tests did a collea= gue of mine). The problem was that these command line tools reject any host= domain name that doesn't fit into the "single-dns-label.localhost" templat= e. So that is where my question and hesitation comes from. Of course, we ma= y have done something wrong and the error is on our side. Anyway, I'm curio= us to learn more here in order to better understand the full picture. So, from what you wrote I will ask my colleague to run the checks again not= using the command line tools but using the mDNS resolver instead. It will = be interesting what the results will be... looks as if there is a differenc= e between the resolver and the command line tools. With best regards, Harald Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 Von: kerlyn2001@gmail.com [mailto:kerlyn2001@gmail.com] Im Auftrag von Kerr= y Lynn Gesendet: Mittwoch, 17. Juli 2013 16:13 An: Albrecht, Harald Cc: mdnsext@ietf.org Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS? On Wed, Jul 17, 2013 at 3:13 AM, Albrecht, Harald > wrote: Thanks for the reply, control over the software stack is right down to one of the problems: there= is not a single software stack, there are multiple ones, so while we may h= ave control over some of our own stacks, we won't have over the ones alread= y out in the wild and which we want to interoperate with. Maybe a change wo= uld be possible, but my view is that this would first need consensus (where= exactly? here in this group?) and in the "worst cast" an update to the RFC= . Would this be a feasible approach at all? Harald, As I said previously, if your application provides a qualified domain name = ending in ".local" or ".local." then what you propose should work fine with an mDNS-a= ware resolver. It is the TLD ".local" that triggers the behavior to multicast t= he request to port 5353. What an mDNS-aware resolver won't do is to append ".local" to a= multi- label host name if your application omits it. IMO, this does not constitute "full control of the stack", nor is an update= to RFC 6762 required. This is not a difficult experiment to set up; I have tried it wi= th OS X and Ubuntu LTS. You can ensure it works on Windows by installing Bonjour for W= indows. -K- With best regards, Harald Albrecht Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 > -----Urspr=FCngliche Nachricht----- > Von: mdnsext-bounces@ietf.org [mailto:md= nsext-bounces@ietf.org] Im > Auftrag von Andrew Sullivan > Gesendet: Dienstag, 16. Juli 2013 17:15 > An: mdnsext@ietf.org > Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS? > > On Tue, Jul 16, 2013 at 10:49:11AM -0400, Kerry Lynn wrote: > > > the hen house. One should still expect "controller.machine2.local." > > to resolve properly, > > Yes, if you tried to resolve "controller.machine2.local.", then it _would= _ > resolve correctly. The difficulty, however, is that most resolving appli= cations > don't actually work truly fully-qualified that way (i.e. by appending the= final > dot). So it will work fine if you have special name-handling code to mak= e > sure that everything is actually really fully qualified always in local. = I think it > would be extremely wise to test how well that works in practice, but thos= e > who have complete control over their application stack and so on might be > able to do it. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext _______________________________________________ mdnsext mailing list mdnsext@ietf.org https://www.ietf.org/mailman/listinfo/mdnsext --_000_E36F274013087B4EA05E08EB5037503902C406DEFTHW99EK5MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

thanks for= the valuable feedback. I have no problem with explicitly appending “= .local.”, in fact, I would even like to make this explicit, so that “local” connections also need to use “controller.machine= 1.local.”. This way, users will learn right from the start which name= s will trigger which resolution technologies.

 = ;

My (negati= ve) experience comes from experimenting with the mDNS tools in the Apple *n= ix package (if I remember correctly, the exact tests did a colleague of mine). The problem was that these command line tools reject a= ny host domain name that doesn’t fit into the “single-dns-label= .localhost” template. So that is where my question and hesitation com= es from. Of course, we may have done something wrong and the error is on our side. Anyway, I’m curious to learn more here= in order to better understand the full picture.

 = ;

So, from w= hat you wrote I will ask my colleague to run the checks again not using the= command line tools but using the mDNS resolver instead. It will be interesting what the results will be… looks as if there is a= difference between the resolver and the command line tools.

 = ;

With best = regards,

Harald

 <= /p>

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 N=FCrnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:harald.albrecht@sieme= ns.com

Siemens Aktiengesellschaft: Vorsitzender d= es Aufsichtsrats: Gerhard Cromme; Vorstand: Peter L=F6scher, Vorsitzender; = Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Mich= ael S=FC=DF; Sitz der Gesellschaft: Berlin und M=FCnchen, Deutschland; Regi= stergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684; WEEE-Re= g.-Nr. DE 23691322

 <= /p>

 <= /p>

 

Von: kerlyn200= 1@gmail.com [mailto:kerlyn2001@gmail.com] Im Auftrag von Kerry Lynn
Gesendet: Mittwoch, 17. Juli 2013 16:13
An: Albrecht, Harald
Cc: mdnsext@ietf.org
Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS?

 

On Wed, Jul 17, 2013 at 3:13 AM, Albrecht, Harald &l= t;harald.a= lbrecht@siemens.com> wrote:

Thanks for the reply,

control over the software stack is right down to one of the problems: there= is not a single software stack, there are multiple ones, so while we may h= ave control over some of our own stacks, we won't have over the ones alread= y out in the wild and which we want to interoperate with. Maybe a change would be possible, but my view is tha= t this would first need consensus (where exactly? here in this group?) and = in the "worst cast" an update to the RFC. Would this be a feasibl= e approach at all?

 

Harald,

As I said previously, if your application provides a qualified domain name = ending in
".local" or ".local." then what you propose should work= fine with an mDNS-aware
resolver.  It is the TLD ".local" that triggers the behavior= to multicast the request to
port 5353.  What an mDNS-aware resolver won't do is to append ".l= ocal" to a multi-
label host name if your application omits it.

IMO, this does not constitute "full control of the stack", nor is= an update to RFC 6762
required.  This is not a difficult experiment to set up; I have tried = it with OS X and
Ubuntu LTS.  You can ensure it works on Windows by installing Bonjour = for Windows.

-K-
 

With best regards, Harald Albrecht

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 N=FCrnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:harald.albrecht@sieme= ns.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M=FCnchen, Deutschland; Registergericht:= Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23= 691322


> -----Urspr=FCngliche Nachricht-----
> Von: mdnsext-bounces@ietf.= org [mailto:mdnsext-bounces= @ietf.org] Im
> Auftrag von Andrew Sullivan
> Gesendet: Dienstag, 16. Juli 2013 17:15
> An: mdnsext@ietf.org
> Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS?<= /o:p>

>
> On Tue, Jul 16, 2013 at 10:49:11AM -0400, Kerry Lynn wrote:
>
> > the hen house.  One should still expect "controller.mac= hine2.local."
> > to resolve properly,
>
> Yes, if you tried to resolve "controller.machine2.local.", t= hen it _would_
> resolve correctly.  The difficulty, however, is that most resolvi= ng applications
> don't actually work truly fully-qualified that way (i.e. by appending = the final
> dot).  So it will work fine if you have special name-handling cod= e to make
> sure that everything is actually really fully qualified always in loca= l.  I think it
> would be extremely wise to test how well that works in practice, but t= hose
> who have complete control over their application stack and so on might= be
> able to do it.
>
> Best,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com > _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext
_______________________________________________
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

 

--_000_E36F274013087B4EA05E08EB5037503902C406DEFTHW99EK5MSXww9_-- 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 B05EC21F9A1E for ; Wed, 17 Jul 2013 07:13:28 -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 8onKkNEZQ0xZ for ; Wed, 17 Jul 2013 07:13:28 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D092B21F99D7 for ; Wed, 17 Jul 2013 07:13:27 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so2598452oag.31 for ; Wed, 17 Jul 2013 07:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mys+KAIrKY4C8eDTVmY6+UxYnkTovA1kchzNAn8MWhY=; b=H5A8eAPa5oeDeQLx8gsOen37q6I0rM7fINItb6kBTgLxZxDYcizWMKjCpEXufQlX5n KWeBvGEHFK0+QkVbX9vZ1JAb7lrTMdEZ2503/Mq/VvzPU00idh1T4DKw4Q6JXSVmt+Zv TmEBjpTyekGR72pOE1aZBIg4HBuDi5PQBwFO8EJWTlTrpKcJ6RcqvumFcYQPOkofl5VW 5HKUMJZgxXk0ZZyZmeVfF48pGDc6ozcJIpBAAu8xFCMTHwhYLHoGqTTzuivDf+BBQ+f7 GAIxu35e9zSGCbHFMXXIAmNMIAovn1YTppbz/4Ym8/JAzcCV+bhepi2b8I7xeoZceFRl M3Hg== MIME-Version: 1.0 X-Received: by 10.60.144.69 with SMTP id sk5mr8674861oeb.0.1374070407320; Wed, 17 Jul 2013 07:13:27 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Wed, 17 Jul 2013 07:13:27 -0700 (PDT) In-Reply-To: References: <20130716151444.GE23286@mx1.yitter.info> Date: Wed, 17 Jul 2013 10:13:27 -0400 X-Google-Sender-Auth: JniDEz8nrS43sjfEx5YGHqrOQRw Message-ID: From: Kerry Lynn To: "Albrecht, Harald" Content-Type: multipart/alternative; boundary=047d7b3a7f80865d6404e1b5b287 Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Wed, 17 Jul 2013 14:13:28 -0000 --047d7b3a7f80865d6404e1b5b287 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 3:13 AM, Albrecht, Harald < harald.albrecht@siemens.com> wrote: > Thanks for the reply, > > control over the software stack is right down to one of the problems: > there is not a single software stack, there are multiple ones, so while w= e > may have control over some of our own stacks, we won't have over the ones > already out in the wild and which we want to interoperate with. Maybe a > change would be possible, but my view is that this would first need > consensus (where exactly? here in this group?) and in the "worst cast" an > update to the RFC. Would this be a feasible approach at all? > > Harald, As I said previously, if your application provides a qualified domain name ending in ".local" or ".local." then what you propose should work fine with an mDNS-aware resolver. It is the TLD ".local" that triggers the behavior to multicast the request to port 5353. What an mDNS-aware resolver won't do is to append ".local" to a multi- label host name if your application omits it. IMO, this does not constitute "full control of the stack", nor is an update to RFC 6762 required. This is not a difficult experiment to set up; I have tried it with OS X and Ubuntu LTS. You can ensure it works on Windows by installing Bonjour for Windows. -K- > With best regards, > Harald Albrecht > > Siemens AG > Industry Sector > Industry Automation Division > Industrial Automation Systems > I IA AS CTO DH 1 > Gleiwitzer Str. 555 > 90475 N=FCrnberg, Deutschland > Tel: +49 911 895-3847 > Fax: +49 911 895-2105 > mailto:harald.albrecht@siemens.com > > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard > Cromme; Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte > Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, > Siegfried Russwurm, Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellsc= haft: > Berlin und M=FCnchen, Deutschland; Registergericht: Berlin Charlottenburg= , > HRB 12300, M=FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 > > > > > -----Urspr=FCngliche Nachricht----- > > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > > Auftrag von Andrew Sullivan > > Gesendet: Dienstag, 16. Juli 2013 17:15 > > An: mdnsext@ietf.org > > Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS? > > > > On Tue, Jul 16, 2013 at 10:49:11AM -0400, Kerry Lynn wrote: > > > > > the hen house. One should still expect "controller.machine2.local." > > > to resolve properly, > > > > Yes, if you tried to resolve "controller.machine2.local.", then it > _would_ > > resolve correctly. The difficulty, however, is that most resolving > applications > > don't actually work truly fully-qualified that way (i.e. by appending > the final > > dot). So it will work fine if you have special name-handling code to > make > > sure that everything is actually really fully qualified always in local= . > I think it > > would be extremely wise to test how well that works in practice, but > those > > who have complete control over their application stack and so on might = be > > able to do it. > > > > Best, > > > > A > > > > -- > > Andrew Sullivan > > ajs@anvilwalrusden.com > > _______________________________________________ > > mdnsext mailing list > > mdnsext@ietf.org > > https://www.ietf.org/mailman/listinfo/mdnsext > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > --047d7b3a7f80865d6404e1b5b287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 3:13 AM, Albrecht, Harald <harald.albrec= ht@siemens.com> wrote:
Thanks for the reply,

control over the software stack is right down to one of the problems: there= is not a single software stack, there are multiple ones, so while we may h= ave control over some of our own stacks, we won't have over the ones al= ready out in the wild and which we want to interoperate with. Maybe a chang= e would be possible, but my view is that this would first need consensus (w= here exactly? here in this group?) and in the "worst cast" an upd= ate to the RFC. Would this be a feasible approach at all?

Harald,

As I said prev= iously, if your application provides a qualified domain name ending in
&= quot;.local" or ".local." then what you propose should work = fine with an mDNS-aware
resolver.=A0 It is the TLD ".local" that triggers the behavior to= multicast the request to
port 5353.=A0 What an mDNS-aware resolver won&= #39;t do is to append ".local" to a multi-
label host name if = your application omits it.

IMO, this does not constitute "full control of the stack", no= r is an update to RFC 6762
required.=A0 This is not a difficult experime= nt to set up; I have tried it with OS X and
Ubuntu LTS.=A0 You can ensur= e it works on Windows by installing Bonjour for Windows.

-K-
=A0
With best regards,
Harald Albrecht

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 N=FCrnberg, Deutschland
Tel: +49 911= 895-3847
Fax: +49 911= 895-2105
mailto:harald.albrecht@sieme= ns.com

Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322



> -----Urspr=FCngliche Nachricht-----
> Von: mdnsext-bounces@ietf.= org [mailto:mdnsext-bounces= @ietf.org] Im
> Auftrag von Andrew Sullivan
> Gesendet: Dienstag, 16. Juli 2013 17:15
> An: mdnsext@ietf.org
> Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS?
>
> On Tue, Jul 16, 2013 at 10:49:11AM -0400, Kerry Lynn wrote:
>
> > the hen house. =A0One should still expect "controller.machin= e2.local."
> > to resolve properly,
>
> Yes, if you tried to resolve "controller.machine2.local.", t= hen it _would_
> resolve correctly. =A0The difficulty, however, is that most resolving = applications
> don't actually work truly fully-qualified that way (i.e. by append= ing the final
> dot). =A0So it will work fine if you have special name-handling code t= o make
> sure that everything is actually really fully qualified always in loca= l. =A0I think it
> would be extremely wise to test how well that works in practice, but t= hose
> who have complete control over their application stack and so on might= be
> able to do it.
>
> Best,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com > _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext
_______________________________________________
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

--047d7b3a7f80865d6404e1b5b287-- 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 7CCA121F9C86 for ; Wed, 17 Jul 2013 00:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 K9ceazXH4NgW for ; Wed, 17 Jul 2013 00:39:12 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id AEDFA21F8C71 for ; Wed, 17 Jul 2013 00:39:11 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r6H7dAwn011953 for ; Wed, 17 Jul 2013 09:39:10 +0200 Received: from defthw99et6msx.ww902.siemens.net ([157.163.148.61]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r6H7dAvs031195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Jul 2013 09:39:10 +0200 Received: from DEFTHW99ER8MSX.ww902.siemens.net (139.22.70.73) by DEFTHW99ET6MSX.ww902.siemens.net (157.163.148.61) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 17 Jul 2013 09:39:10 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.109]) by DEFTHW99ER8MSX.ww902.siemens.net ([139.22.70.73]) with mapi id 14.03.0146.000; Wed, 17 Jul 2013 09:39:10 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Hierarchical (host) domain names in mDNS? Thread-Index: Ac6CGBuBlctNJJX5QF6LGwWoRFhvmQACsLGAAADkbwAAJZRPwP//4wgA///c6PA= Date: Wed, 17 Jul 2013 07:39:09 +0000 Message-ID: References: <20130716151444.GE23286@mx1.yitter.info> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Wed, 17 Jul 2013 07:39:18 -0000 SGkgRXJpaywNCg0KdW5mb3J0dW5hdGVseSBub3Q7IEkgbmVlZCAiZnVsbCBBL0FBQUEgY29ubmVj dGl2aXR5IiwgdGhhdCBpcywgd2UncmUgbm90IHRhbGtpbmcgYWJvdXQgYSBwYXJ0aWN1bGFyICJ0 cmFuc3BvcnQiIEhUVFAsIGJ1dCBJIG5lZWQgc3VwcG9ydCBmb3IgYWxsIHRyYW5zcG9ydHMgdGhh dCBzaXQgb24gdG9wIG9mIElQLCBlaXRoZXIgZGlyZWN0bHkgb3IgaW5kaXJlY3RseS4gQWxzbywg dGhlcmUgaXMgbm90aGluZyBzdWNoIGFzIGEgY2VudHJhbCAicG9ydGFsIiwgdGhhdCBpcywgYSB3 ZWIgc2VydmVyIHRoYXQgYWN0cyBhcyB0aGUgZW50cmFuY2UgdG8gdGhlIGluZGl2aWR1YWwgc3lz dGVtcy4NCg0KRm9yIGluc3RhbmNlLCBvdXIgUzcgY29udHJvbGxlcnMgYWxsb3cgb3VyIGN1c3Rv bWVycyB0byBwcm9ncmFtbWF0aWNhbGx5IHVzZSBUQ1AgY29ubmVjdGlvbnMgcmlnaHQgZnJvbSB0 aGVpciBjb250cm9sIHByb2dyYW1zIC4uLiBhbmQgdGhlcmUncyBhIGdyZWF0IGRlbWFuZCBvZiB0 aGF0LiBTbywgY3VzdG9tZXJzIG5lZWQgdG8gYmUgYWJsZSB0byBlaXRoZXIgYWRkcmVzcyB3aXRo aW4gdGhlIHNhbWUgZG9tYWluIGxldmVsLCBzdWNoIGFzIHRoZSAiaG1pIiBjb25uZWN0aW5nIHRv IHRoZSAiY29udHJvbGxlciIuIEJ1dCB0aGVyZSdzIGFsc28gbmVlZCBmb3IgaW50ZXItbWFjaGlu ZSBzeW5jaHJvbml6YXRpb24gKG9yIGludGVyLWNlbGwpLCB0aGF0IGlzLCAiY29udHJvbGxlci5t YWNoaW5lMS4uLi4iIHRvICJjb250cm9sbGVyLm1hY2hpbmUyLi4uLiIuDQoNCkF0IHRoZXNlIGxl dmVscywgb3VyIGN1c3RvbWVycyBvbmx5IGFjY2VwdCBkZWNlbnRyYWxpemVkIGFuZCBhZG1pbmlz dHJhdGlvbi1mcmVlIHRlY2hub2xvZ2llcyBmb3IgbmFtZSByZXNvbHV0aW9uLiBPbmx5IGF0IG11 Y2ggaGlnaGVyIGxldmVscyBETlMgaXMgYWNjZXB0YWJsZSwgc3VjaCBhcyB3aGVuIGhhdmluZyB0 byBsb29zZWx5IGNvbm5lY3QgZGlmZmVyZW50IHBsYW50cywgZXQgY2V0ZXJhLg0KDQpXaXRoIGJl c3QgcmVnYXJkcywNCkhhcmFsZCBBbGJyZWNodA0KDQotLS0gSSBoYXZlIHRvIGFkZCB0aGUgZm9s bG93aW5nIGR1ZSB0byBsb2NhbCBsYXc7IGxldCdzIGhvcGUgdGhhdCB0aGVyZSBhcmUgbm8gb3Ro ZXIgcGxhY2VzIHdpdGggYSBsYXcgZm9yYmlkZGluZyB0byBhZGQgdGhlIGZvbGxvd2luZyAtLS0N ClNpZW1lbnMgQUcNCkluZHVzdHJ5IFNlY3Rvcg0KSW5kdXN0cnkgQXV0b21hdGlvbiBEaXZpc2lv bg0KSW5kdXN0cmlhbCBBdXRvbWF0aW9uIFN5c3RlbXMNCkkgSUEgQVMgQ1RPIERIIDENCkdsZWl3 aXR6ZXIgU3RyLiA1NTUNCjkwNDc1IE7DvHJuYmVyZywgRGV1dHNjaGxhbmQNClRlbDogKzQ5IDkx MSA4OTUtMzg0Nw0KRmF4OiArNDkgOTExIDg5NS0yMTA1DQptYWlsdG86aGFyYWxkLmFsYnJlY2h0 QHNpZW1lbnMuY29tDQoNClNpZW1lbnMgQWt0aWVuZ2VzZWxsc2NoYWZ0OiBWb3JzaXR6ZW5kZXIg ZGVzIEF1ZnNpY2h0c3JhdHM6IEdlcmhhcmQgQ3JvbW1lOyBWb3JzdGFuZDogUGV0ZXIgTMO2c2No ZXIsIFZvcnNpdHplbmRlcjsgUm9sYW5kIEJ1c2NoLCBCcmlnaXR0ZSBFZGVyZXIsIEtsYXVzIEhl bG1yaWNoLCBKb2UgS2Flc2VyLCBCYXJiYXJhIEt1eCwgSGVybWFubiBSZXF1YXJkdCwgU2llZ2Zy aWVkIFJ1c3N3dXJtLCBQZXRlciBZLiBTb2xtc3NlbiwgTWljaGFlbCBTw7zDnzsgU2l0eiBkZXIg R2VzZWxsc2NoYWZ0OiBCZXJsaW4gdW5kIE3DvG5jaGVuLCBEZXV0c2NobGFuZDsgUmVnaXN0ZXJn ZXJpY2h0OiBCZXJsaW4gQ2hhcmxvdHRlbmJ1cmcsIEhSQiAxMjMwMCwgTcO8bmNoZW4sIEhSQiA2 Njg0OyBXRUVFLVJlZy4tTnIuIERFIDIzNjkxMzIyIA0KDQoNCg0KDQo+IC0tLS0tVXJzcHLDvG5n bGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBFcmlrIEtsaW5lIFttYWlsdG86ZWtAZ29vZ2xl LmNvbV0NCj4gR2VzZW5kZXQ6IE1pdHR3b2NoLCAxNy4gSnVsaSAyMDEzIDA5OjI3DQo+IEFuOiBB bGJyZWNodCwgSGFyYWxkDQo+IENjOiBtZG5zZXh0QGlldGYub3JnDQo+IEJldHJlZmY6IFJlOiBb bWRuc2V4dF0gSGllcmFyY2hpY2FsIChob3N0KSBkb21haW4gbmFtZXMgaW4gbUROUz8NCj4gDQo+ IFdvdWxkIHlvdSBiZSBhYmxlIHRvIHN1ZmZpY2Ugd2l0aCBoYXZpbmcgdGhlIHNtYWxsZXIgbm9k ZXMgKOKAnGhtaeKAnSwNCj4g4oCcY29udHJvbGxlcuKAnSwg4oCcc3RhbXBlcuKAnSwg4oCcZm9y bWVy4oCdLCDigJxjb29sZXLigJ0pIGJlIGlkZW50aWZpYWJsZSBhcyBzZXJ2aWNlcw0KPiBvZmZl cmVkIHZpYSBtYWNoaW5lMSBhbmQgbWFjaGluZTI/ICBJZiBhbGwgdGhhdCBhbnkgZXh0ZXJuYWwg ZWxlbWVudHMgYXJlDQo+IGRvaW5nIGlzIHRyeWluZyB0byB0YWxrIHRvIHNvbWUgc3BlY2lmaWMg c2VydmljZSBvbiB0aG9zZSBub2RlcyAoUkVTVC1mdWwgSFRUUA0KPiBzZXJ2ZXIsIGV0YyksIGNv dWxkIG1hY2hpbmUxIGFkdmVydGlzZSBfaGRtaSwgX2NvbnRyb2xsZXIsIF9zdGFtcGVyLCAuLi4N Cj4gc2VydmljZXM/DQo= 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 3E4D421F9C38 for ; Wed, 17 Jul 2013 00:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 oecbgek-gHxB for ; Wed, 17 Jul 2013 00:29:52 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2021F8417 for ; Wed, 17 Jul 2013 00:29:52 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.13.6/8.13.6) with ESMTP id r6H7TpB0023158 for ; Wed, 17 Jul 2013 09:29:51 +0200 Received: from DEFTHW99ET4MSX.ww902.siemens.net (defthw99et4msx.ww902.siemens.net [157.163.148.53]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r6H7Tpan010311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Jul 2013 09:29:51 +0200 Received: from DEFTHW99ER0MSX.ww902.siemens.net (139.22.70.175) by DEFTHW99ET4MSX.ww902.siemens.net (157.163.148.53) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 17 Jul 2013 09:29:50 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.109]) by DEFTHW99ER0MSX.ww902.siemens.net ([139.22.70.175]) with mapi id 14.03.0146.000; Wed, 17 Jul 2013 09:29:50 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Hierarchical (host) domain names in mDNS? Thread-Index: Ac6CGBuBlctNJJX5QF6LGwWoRFhvmQAA4NEAAChlLcA= Date: Wed, 17 Jul 2013 07:29:49 +0000 Message-ID: References: <20130716135718.GB23286@mx1.yitter.info> In-Reply-To: <20130716135718.GB23286@mx1.yitter.info> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Wed, 17 Jul 2013 07:29:59 -0000 > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > Auftrag von Andrew Sullivan > (It's actually not a DNS label, either, actually, but never mind that.) As I'm curious to learn more on this topic ... why do you think that it's n= ot a DNS label? At least, I thought it to be a label? =20 > It seems that the environment you need is much more amenable to traditina= l > DNS use. That's probably not the answer you want, but I think it's likel= y true. I don't want a particular answer, I want to know. We may very well decide t= o not use mDNS, so it is really about finding out where the design "limitat= ions" of mDNS are. But no, my environment is rather openly hostile to traditional DNS use. Put= ting such rather useless discussions about reliability aside (as I trust DN= S to be operated reliably) the main issue are the "business processes" of h= ow host names (or rather domain names) enter DNS: they are not established = and it will probably take at least half a decade at best to slowly introduc= e these environments to DNS. > This isn't too surprising. You can't really have an unmanaged namespace = that > is also managed, which is sort of what you seem to want. The point here is that there is no need for management: the "management" ha= s already taken place when designing the automation as we are in fact mirro= ring the technological hierarchical names in DNS. We aldready have means in= place that allow all kind of funny technological names to be used in a DNS= -compatible manner, that is, in a manner compatible with LDH. We do acutual= ly use DNS, but only on the large scale. What we need in these environments= , however, is a small-scale and completely administration-free solution. mD= NS is appealing here ... but my show stopper seems to be the "hierarchical = names" thing. > One thing you could do is use some sort of trickery to make your labels f= lat, > like service1_machine1.local, service2_machine1.local, > service1_machine2.local, and so on. This is slightly hideous because the= re's > no convenient way to split up the service name from the machine name (one > of the distinct advantages of te DNS is this hierarchical name space). B= ut you > could generate such labels programmatically, I think. Yes, of course, that is an option. However, we ditched it as it wouldn't re= ally integrate with the existing systems. People when would need to know wh= ich names to use in which context: oh, if it's "local" (well, ".local."), t= hen I need to use the underlines, otherwise, I'll use the dots. Recipe for = disaster. >=20 > Better, I suspect, would be to create a mechanism for registering names o= f > the services and machines in a local registry. As I indicated above, a local registry would still be a single point of fai= lure. Adding redundancy to it is a big effort. And customers would not acce= pt it just for local use. For large-scale use, they will accept, but then w= e're talking about full-blown DNS. mDNS is a peer system that in this aspec= t of its design is exactly what will perfectly fit into the environments we= are dealing with. It's just that we need hierarchical names, maybe only tw= o or three levels below ".local.", but we need it. Putting this details aside, I really enjoy the replies and suggestions here= ! With best regards, Harald Albrecht --- I have to add the following due to local law; let's hope that there are= no other places with a law forbidding to add the following --- Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322=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 E119B21F8C7C for ; Wed, 17 Jul 2013 00:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 DoG7vfkkN+jo for ; Wed, 17 Jul 2013 00:27:27 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 364D221F9D98 for ; Wed, 17 Jul 2013 00:27:27 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id m15so904275qcq.5 for ; Wed, 17 Jul 2013 00:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=vLtgJoV8dTKGr7tkq6G4aIjPbNB3QHVFCehhLe7IZF4=; b=VfRLsK6VSAe1LOBlED1QOj0RIrX1XQO/gqOXF7RoVyqSOCaWcu5i0unKcHGE9gINut 9C4AioASaXFAB1VlABdb6YAbaZyuQn2NwGtH206nPSNOGQA7IKWHudi+SOUwepEAwrvm 5hRRtY/CNRGCkh6N8nMWP3h12u42Dbr7Zy/7nM8AfGl0ZJo6FH7dOUseaqvhF2Oay3I4 phElyjYKVAc0wXkXiCr2kVB2NbnA/a9zZgfgb1hLnHtvDMGk6OYg8Tgkgi2h+r/NvpNi RWXjNcq+iQmnXZ0ZvJBDZOh0Dj6YNiy0fd7feqE62HYfkWnSw0YaW2wW5t0mXChXKmmM 5I1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=vLtgJoV8dTKGr7tkq6G4aIjPbNB3QHVFCehhLe7IZF4=; b=L7ec4wy2vv45cE8z5sfXyS+fM0W9llqRjrivIxQpqfZsmV3FwVxfXsgrPVq6v3cO7K SxRxB4UUascoHjpNwropm8IUtS0SoHubEQW55y3xy8QQFOnyon2muwh3tLpPm+WhtSRw r2grdhswW00CTdc53qoJ8zuxe8VevD0FUqckZTjoIoXBO/P6jnkLocbCxAMJtPxp1iRt LEqH6rT76xBdOGZejmVJhm58JPYFVwHSGOOZnu3N1OApbNbWXprX0PTBJX8NqLLIdB9E QYkQNr3OS7SmWL5iNMa5fmFh2kSIjZtNLtT8qXnMvGXIH+M5IWt3zEUqSYX7jHQr0RFR +8Fg== X-Received: by 10.49.26.35 with SMTP id i3mr6559609qeg.75.1374046045337; Wed, 17 Jul 2013 00:27:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.217 with HTTP; Wed, 17 Jul 2013 00:27:04 -0700 (PDT) In-Reply-To: References: <20130716151444.GE23286@mx1.yitter.info> From: Erik Kline Date: Wed, 17 Jul 2013 16:27:04 +0900 Message-ID: To: "Albrecht, Harald" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlQ6NwruAQ+BhV2rxjDFE3O3Hd4gY3tSHjJryZHoHWGzfyLvdfnGmo0BCAFfGAROXY/SmYtv8G3NSkwrEr0dAyE0s2QuxSf+DjctK4fAbpzP9az+UN7KUzmycJqD7L7SJe800d2ok0BlXc+tWOeMzUA/L3MwZMP1fnfJEsfa6gvxk/L8ZAzPg+SY4Vjcm/fFYOdHbO3 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Wed, 17 Jul 2013 07:27:28 -0000 Would you be able to suffice with having the smaller nodes (=E2=80=9Chmi=E2= =80=9D, =E2=80=9Ccontroller=E2=80=9D, =E2=80=9Cstamper=E2=80=9D, =E2=80=9Cformer=E2= =80=9D, =E2=80=9Ccooler=E2=80=9D) be identifiable as services offered via machine1 and machine2? If all that any external elements are doing is trying to talk to some specific service on those nodes (REST-ful HTTP server, etc), could machine1 advertise _hdmi, _controller, _stamper, ... services? 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 4587F21F9CAF for ; Wed, 17 Jul 2013 00:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.349 X-Spam-Level: X-Spam-Status: No, score=-9.349 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Ei3dpFZVxgWI for ; Wed, 17 Jul 2013 00:14:02 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA9B21F9C08 for ; Wed, 17 Jul 2013 00:14:00 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r6H7Dn0L021959 for ; Wed, 17 Jul 2013 09:13:50 +0200 Received: from DEFTHW99ET7MSX.ww902.siemens.net ([157.163.145.4]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r6H7DmZg006164 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Jul 2013 09:13:48 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) by DEFTHW99ET7MSX.ww902.siemens.net (157.163.145.4) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 17 Jul 2013 09:13:48 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.109]) by DEFTHW99ERNMSX.ww902.siemens.net ([139.22.70.141]) with mapi id 14.03.0146.000; Wed, 17 Jul 2013 09:13:47 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Hierarchical (host) domain names in mDNS? Thread-Index: Ac6CGBuBlctNJJX5QF6LGwWoRFhvmQACsLGAAADkbwAAJZRPwA== Date: Wed, 17 Jul 2013 07:13:47 +0000 Message-ID: References: <20130716151444.GE23286@mx1.yitter.info> In-Reply-To: <20130716151444.GE23286@mx1.yitter.info> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.37] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Wed, 17 Jul 2013 07:14:08 -0000 Thanks for the reply, control over the software stack is right down to one of the problems: there= is not a single software stack, there are multiple ones, so while we may h= ave control over some of our own stacks, we won't have over the ones alread= y out in the wild and which we want to interoperate with. Maybe a change wo= uld be possible, but my view is that this would first need consensus (where= exactly? here in this group?) and in the "worst cast" an update to the RFC= . Would this be a feasible approach at all? With best regards, Harald Albrecht Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322=20 > -----Urspr=FCngliche Nachricht----- > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > Auftrag von Andrew Sullivan > Gesendet: Dienstag, 16. Juli 2013 17:15 > An: mdnsext@ietf.org > Betreff: Re: [mdnsext] Hierarchical (host) domain names in mDNS? >=20 > On Tue, Jul 16, 2013 at 10:49:11AM -0400, Kerry Lynn wrote: >=20 > > the hen house. One should still expect "controller.machine2.local." > > to resolve properly, >=20 > Yes, if you tried to resolve "controller.machine2.local.", then it _would= _ > resolve correctly. The difficulty, however, is that most resolving appli= cations > don't actually work truly fully-qualified that way (i.e. by appending the= final > dot). So it will work fine if you have special name-handling code to mak= e > sure that everything is actually really fully qualified always in local. = I think it > would be extremely wise to test how well that works in practice, but thos= e > who have complete control over their application stack and so on might be > able to do it. >=20 > Best, >=20 > A >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > 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 A931111E80C5 for ; Tue, 16 Jul 2013 08:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=0.057, 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 a8T3biFvipTJ for ; Tue, 16 Jul 2013 08:14:46 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id DD16A11E80DC for ; Tue, 16 Jul 2013 08:14:45 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4F3008A031 for ; Tue, 16 Jul 2013 15:14:45 +0000 (UTC) Date: Tue, 16 Jul 2013 11:14:44 -0400 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130716151444.GE23286@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Tue, 16 Jul 2013 15:14:51 -0000 On Tue, Jul 16, 2013 at 10:49:11AM -0400, Kerry Lynn wrote: > the hen house. One should still expect "controller.machine2.local." to > resolve properly, Yes, if you tried to resolve "controller.machine2.local.", then it _would_ resolve correctly. The difficulty, however, is that most resolving applications don't actually work truly fully-qualified that way (i.e. by appending the final dot). So it will work fine if you have special name-handling code to make sure that everything is actually really fully qualified always in local. I think it would be extremely wise to test how well that works in practice, but those who have complete control over their application stack and so on might be able to do it. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com 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 5959711E80D7 for ; Tue, 16 Jul 2013 07:49:16 -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=[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 2ESj4UE1HNE0 for ; Tue, 16 Jul 2013 07:49:15 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34E11E80D5 for ; Tue, 16 Jul 2013 07:49:12 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id dn14so831964obc.2 for ; Tue, 16 Jul 2013 07:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=np7FdaIeUxj93zZOvNQxWqGlJrjyNkFkFcmA5qgBb1c=; b=ACYQnFzjjUD9sp3gq1LxoyTP9B48X7Rybw0Xcxh033BsKo2AKK9Wp/kmzzxWRFvHyx PgygmJF4hWmKwLmJU+BtacGosTIwarTQwxiRmZGVQYFuIxDWgAqcH9hv5hKZF3SKQVjT WZASdT2dnqLaX13Hivds+YNn9CCMxm0tvTILYorifpTz6s038lC2UhoRq8BQw2pA4vlD NvxWgL9hXMgMD5BQhj7bp6CIL4xiWai40W5rZRXzoPzdzOBzM0QsBOSTffVd42kq7N2d pl41aw/+EARRGbsbFooub/nCKIDUIz9edNJzBPdxgO3Pm4/CCkeNYTAdy4N8MJgbhct9 4xmw== MIME-Version: 1.0 X-Received: by 10.60.117.233 with SMTP id kh9mr2611010oeb.58.1373986151923; Tue, 16 Jul 2013 07:49:11 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Tue, 16 Jul 2013 07:49:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Jul 2013 10:49:11 -0400 X-Google-Sender-Auth: 8bA7_NUggJVS9oY87UuXp_aCFLg Message-ID: From: Kerry Lynn To: "Albrecht, Harald" Content-Type: multipart/alternative; boundary=047d7b3a92a083059804e1a2148a Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Tue, 16 Jul 2013 14:49:16 -0000 --047d7b3a92a083059804e1a2148a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 7:32 AM, Albrecht, Harald < harald.albrecht@siemens.com> wrote: > Hello, > > something I couldn=92t find a proper answer to I would like to ask the mD= NS > experts on this list: is it possible to apply mDNS also to situations whe= re > the decentralized, configuration-free operation of mDNS is required but > where the individual hosts within the same network need to make use of > hierarchical domain names? Such as =93controller.machine2.local=94? > > I think the answer is (or should be) "yes". First some guidance from RFC 6762: This document recommends a single flat namespace for dot-local host names, (i.e., the names of DNS "A" and "AAAA" records, which map names to IPv4 and IPv6 addresses), but other DNS record types (such as those used by DNS-Based Service Discovery [RFC6763 ]) may contain as many labels as appropriate for the desired usage, up to a maximum of 255 bytes, plus a terminating zero byte at the end. Name length issues are discussed further in Appendix C . The meaning of "recommends" as a keyword is equivalent to SHOULD. Now why does RFC 6762 take this position? It has to do with automagic operation of an mDNS resolver: A malicious host could masquerade as "www.example.com." by answering the resulting Multicast DNS query for "www.example.com.local.". To avoid this, a host MUST NOT append the search suffix ".local.", if present, to any relative (partially qualified) host name containing two or more labels. Appending ".local." to single-label relative host names is acceptable, since the user should have no expectation that a single-label host name will resolve as is. So this places a restriction on resolvers, which is basically intended to keep the fox out of the hen house. One should still expect "controller.machine2.local." to resolve properly, if there is an authoritative responder for this host name. I assume it would be invisible to lookups in ".local.". Some months back, the main criticism of mDNS in homenet was that if I visited a friend's house then my browser might confuse my bookmarked "www.refrigerator.local." with my friend's. I mentioned at the time that most (all?) major printer vendors solve this problem by appending a collision-resistant substring to a human-readable substring to create the instance or host label, e.g., Officejet\032Pro\0328500\032A909g\032[4C0EA4]. A similar approach was proposed by Brian Carpenter, but he proposed creating "zones" in the .local. namespace, e.g., .local. I suspect either approach can be made to work. I suggest you take a look at the Discovery section of the ZigBee Smart Energy Profile 2 (now IEEE 2030.5) specification: http://www.zigbee.org/Standards/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Standa= rd.aspx to see how your problem was solved using "fine-grained" discovery based on the former approach. Regards, -K- --047d7b3a92a083059804e1a2148a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 7:32 AM, Albrecht, Harald <harald.albrec= ht@siemens.com> wrote:
Hello,
=A0
something I couldn=92t find a proper answer to I would like to ask the= mDNS experts on this list: is it possible to apply mDNS also to situations= where the decentralized, configuration-free operation of mDNS is required = but where the individual hosts within the same network need to make use of hierarchical domain names? Such as =93= controller.machine2.local=94?
=A0
I think the answer is (or should be) "yes".
First some guidance from RFC 6762:

   This document recommends a single flat namespace for dot-l=
ocal host
   names, (i.e., the names of DNS "A" and "AAAA" record=
s, which map
   names to IPv4 and IPv6 addresses), but other DNS record types (such
   as those used by DNS-Based Service Discovery [RFC6763]) may contain
   as many labels as appropriate for the desired usage, up to a maximum
   of 255 bytes, plus a terminating zero byte at the end.  Name length
   issues are discussed further in Appendix C.

The meaning of "recommends" as a keyword is equi= valent to SHOULD.
Now why does RFC 6762 take this position?=A0 It has to= do with automagic operation
of an mDNS resolver:

   A malicious host could masquerade as "www.example.com." by answering
   the resulting Multicast DNS query for "www.example.com.local."=
.  To
   avoid this, a host MUST NOT append the search suffix ".local."=
, if
   present, to any relative (partially qualified) host name containing
   two or more labels.  Appending ".local." to single-label relat=
ive
   host names is acceptable, since the user should have no expectation
   that a single-label host name will resolve as is.

So= this places a restriction on resolvers, which is basically intended to kee= p the fox out of
the hen house.=A0 One should still expect "controller.machine2.local.&q= uot; to resolve properly,
if there is an authoritative responder for this host name.=A0 I assume it w= ould be invisible to
lookups in ".local.".

Some months = back, the main criticism of mDNS in homenet was that if I visited a friend&= #39;s
house then my browser might confuse my bookmarked "www.refrigerator.lo= cal." with my
friend's.=A0 I mentioned at the time that most (a= ll?) major printer vendors solve this problem
by appending a collision-r= esistant substring to a human-readable substring to create the
instance or host label, e.g., Officejet\032Pro\0328500\032A909g\032[4C0EA4]= .=A0 A similar
approach was proposed by Brian Carpenter, but he proposed= creating "zones" in the
.local. namespace, e.g., <ULA>.= local.

I suspect either approach can be made to work.=A0 I suggest you take a = look at the Discovery
section of the ZigBee Smart Energy Profile 2 (now = IEEE 2030.5) specification:
http://www.zigbee.org/St= andards/ZigBeeSmartEnergy/ZigBeeSmartEnergy20Standard.aspx
to see how your problem was solved using "fine-grained" discovery= based on the former
approach.

Regards, -K-
--047d7b3a92a083059804e1a2148a-- 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 B3C4F21F9D4F for ; Tue, 16 Jul 2013 06:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=0.068, 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 e3neo9e+O8uQ for ; Tue, 16 Jul 2013 06:57:22 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3C11621F9D45 for ; Tue, 16 Jul 2013 06:57:21 -0700 (PDT) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D689B8A031 for ; Tue, 16 Jul 2013 13:57:19 +0000 (UTC) Date: Tue, 16 Jul 2013 09:57:18 -0400 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130716135718.GB23286@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Tue, 16 Jul 2013 13:57:32 -0000 On Tue, Jul 16, 2013 at 11:32:52AM +0000, Albrecht, Harald wrote: > Hello, > > something I couldn't find a proper answer to I would like to ask the mDNS experts on this list: is it possible to apply mDNS also to situations where the decentralized, configuration-free operation of mDNS is required but where the individual hosts within the same network need to make use of hierarchical domain names? Such as "controller.machine2.local"? > No. The mDNS specification is in RFC 6762. Right at the beginning, it says, "To remedy this problem, this document allows any computer user to elect to give their computers link-local Multicast DNS host names of the form: "single-dns-label.local.". Note the "single-dns-label". (It's actually not a DNS label, either, actually, but never mind that.) Unfortunately, you can't do what you want. It seems that the environment you need is much more amenable to traditinal DNS use. That's probably not the answer you want, but I think it's likely true. This isn't too surprising. You can't really have an unmanaged namespace that is also managed, which is sort of what you seem to want. One thing you could do is use some sort of trickery to make your labels flat, like service1_machine1.local, service2_machine1.local, service1_machine2.local, and so on. This is slightly hideous because there's no convenient way to split up the service name from the machine name (one of the distinct advantages of te DNS is this hierarchical name space). But you could generate such labels programmatically, I think. Better, I suspect, would be to create a mechanism for registering names of the services and machines in a local registry. Your configuration would need to be just a little bit smarter, from the sounds of things, but it would allow you to create a self-contained system that allowed these machines to co-operate. You could trivially set up a DNS zone with one name per customer, so that you shipped a box with customer1.example.com, customer2.example.com, and so on, with the machines to be configured. That's in effect your "router" (you could do this on any of the standard user-programmable wireless gateways derived from the WRT-style products). Then you could even charge for so-called "vanity" service if there was a customer that already had a corporate domain name and wanted to include that instead. (Or just make it a user-configurable option at install time, &c. &c.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com 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 C084821E8054 for ; Tue, 16 Jul 2013 04:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.448 X-Spam-Level: X-Spam-Status: No, score=-8.448 tagged_above=-999 required=5 tests=[AWL=-1.801, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_OEM_BRC=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 V9tKKpQCS4FA for ; Tue, 16 Jul 2013 04:32:59 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id D458311E8195 for ; Tue, 16 Jul 2013 04:32:57 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r6GBWtKL002407 for ; Tue, 16 Jul 2013 13:32:56 +0200 Received: from DEFTHW99ET7MSX.ww902.siemens.net ([157.163.145.4]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r6GBWrpQ006109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Jul 2013 13:32:54 +0200 Received: from DENBGAT9ER8MSX.ww902.siemens.net (139.22.70.86) by DEFTHW99ET7MSX.ww902.siemens.net (157.163.145.4) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 16 Jul 2013 13:32:53 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.109]) by DENBGAT9ER8MSX.ww902.siemens.net ([139.22.70.86]) with mapi id 14.03.0146.000; Tue, 16 Jul 2013 13:32:53 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: Hierarchical (host) domain names in mDNS? Thread-Index: Ac6CGBuBlctNJJX5QF6LGwWoRFhvmQ== Date: Tue, 16 Jul 2013 11:32:52 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.37] Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB5037503902C1DCDEFTHW99EK5MSXww9_" MIME-Version: 1.0 Subject: [mdnsext] Hierarchical (host) domain names in mDNS? 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: Tue, 16 Jul 2013 11:33:05 -0000 --_000_E36F274013087B4EA05E08EB5037503902C1DCDEFTHW99EK5MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, something I couldn't find a proper answer to I would like to ask the mDNS e= xperts on this list: is it possible to apply mDNS also to situations where = the decentralized, configuration-free operation of mDNS is required but whe= re the individual hosts within the same network need to make use of hierarc= hical domain names? Such as "controller.machine2.local"? I'll illustrate this situation now in more detail: for instance, consider s= omething like machines for producing bread rolls ... bakeries can buy such = equipment from specialized machine manufacturers. Such (OEM) machines may v= ery well be modular and with an inner structure that results on such a sing= le machine equipped with several networked nodes, such as a user panel, a c= ontroller, and several devices for sensors and actuators. The OEM machine b= uilder builds the machine and programs the networked nodes. Part of this pr= ocess is, of course, to assign host names to the nodes. For instance, "hmi"= , "controller", "stamper", "former", "cooler", and so on. mDNS can be used = in this situation to allow the individual nodes to communicate with each ot= her independently of any concrete IP addresses set. After the machine has been built, it is essentially sealed in terms of its = setup. In particular, when the machine gets delivered to a customer and com= missioned on site, it is not possible to change the host names as such anym= ore. This is no problem if a customer just orders a single machine. However, if = you need such machines, you surely need more than one. So we end up with mu= ltiple instances of the same blueprint. Of course, you could try to separat= e these machines into different subnets and thus different mDNS "domains". = However, a bakery surely does not want to spend money on several routers ju= st to make the name resolution work. Also, routers may very well increase a= dministrative efforts ; something that these customers surely don't need an= d don't want. So what is needed in this situation is to view the individual machines as d= omains, such as "machine1", "machine2", et cetera. The individual networked= nodes inside these machines then would live in the sub name spaces, such a= s "controller.machine1" and "controller.machine2". We even see (in other ap= plications) three levels of hierarchy, such as cells, machines, nodes insid= e these machines. However, these installations don't want to go the extra m= ile for a proper DNS infrastructure, but instead want to rely on a peer-bas= ed name resolution system, such as mDNS is one example of. My (limited) understanding of mDNS is that this is not possible, as "contro= ller.machine1.local" isn't allowed. Or am I mistaken here? Can mDNS handle = such situations? Would IETF87 Berlin be the right place to discuss my situa= tion and how to properly apply mDNS? With best regards, Harald Albrecht Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 --_000_E36F274013087B4EA05E08EB5037503902C1DCDEFTHW99EK5MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
something I couldn’t find a proper answer to I would like to ask= the mDNS experts on this list: is it possible to apply mDNS also to situat= ions where the decentralized, configuration-free operation of mDNS is requi= red but where the individual hosts within the same network need to make use of hierarchical domain names? Such as = 220;controller.machine2.local”?
 
I’ll illustrate this situation now in more detail: for instance,= consider something like machines for producing bread rolls … bakerie= s can buy such equipment from specialized machine manufacturers. Such (OEM)= machines may very well be modular and with an inner structure that results on such a single machine equipped with seve= ral networked nodes, such as a user panel, a controller, and several device= s for sensors and actuators. The OEM machine builder builds the machine and= programs the networked nodes. Part of this process is, of course, to assign host names to the nodes. For insta= nce, “hmi”, “controller”, “stamper”, &#= 8220;former”, “cooler”, and so on. mDNS can be used in th= is situation to allow the individual nodes to communicate with each other i= ndependently of any concrete IP addresses set.
 
After the machine has been built, it is essentially sealed in terms of= its setup. In particular, when the machine gets delivered to a customer an= d commissioned on site, it is not possible to change the host names as such= anymore.
 
This is no problem if a customer just orders a single machine. However= , if you need such machines, you surely need more than one. So we end up wi= th multiple instances of the same blueprint. Of course, you could try to se= parate these machines into different subnets and thus different mDNS “domains”. However, a bakery su= rely does not want to spend money on several routers just to make the name = resolution work. Also, routers may very well increase administrative effort= s ; something that these customers surely don’t need and don’t want.
 
So what is needed in this situation is to view the individual machines= as domains, such as “machine1”, “machine2”, et cet= era. The individual networked nodes inside these machines then would live i= n the sub name spaces, such as “controller.machine1” and “controller.machine2”. We even see (in other applications) thre= e levels of hierarchy, such as cells, machines, nodes inside these machines= . However, these installations don’t want to go the extra mile for a = proper DNS infrastructure, but instead want to rely on a peer-based name resolution system, such as mDNS is one example of.
 
My (limited) understanding of mDNS is that this is not possible, as &#= 8220;controller.machine1.local” isn’t allowed. Or am I mistaken= here? Can mDNS handle such situations? Would IETF87 Berlin be the right pl= ace to discuss my situation and how to properly apply mDNS?
 
With best regards,
Harald Albrecht

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 N=FCrnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:harald.albrecht@siemens.com

Siemens Ak= tiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand:= Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmri= ch, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellscha= ft: Berlin und M=FCnchen, Deutschland; Registergericht: Berlin Charlottenbu= rg, HRB 12300, M=FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322
 
 
 
 --_000_E36F274013087B4EA05E08EB5037503902C1DCDEFTHW99EK5MSXww9_-- 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 F3FDC11E8121 for ; Mon, 15 Jul 2013 17:36:34 -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=[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 2kKTpbX1+2mI for ; Mon, 15 Jul 2013 17:36:33 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 929F011E80F2 for ; Mon, 15 Jul 2013 17:36:33 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id wd20so79526obb.33 for ; Mon, 15 Jul 2013 17:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Z8G4nJsrxDeYhReUveRqNk7FWAxeoUEungYbWBTMMS8=; b=Qa9XG0vEBQXJrORNyYRI9rLMu83Nl3B9afSS3gOvhahI9j9HhONqu66cdA+n7OAhvS WqC+/1FtZvrKdHi1KVO3CZtti9LFnwzHGtrJ3QgirzG66ZY4ypwyKrsdkSwsM7sjT+fQ BXSw5gNa+17SM3EU7sQK3RzofTtC/TJ90990qGqladljXXdjBK7ynESgCvPYFLQB3lbB S82fq+z9/ny6is2y2mqXAIv7yAHcL6B3odAUSoQE4cakRTvD2lyb95XMPJPlxweDQMmn eEBeCrPS/RBhgsolkC04eU7wVYFJLurMNtJX322VjqC5Oi2K5fIm66b9r1mpSol8yKsj epsQ== MIME-Version: 1.0 X-Received: by 10.182.128.6 with SMTP id nk6mr45676006obb.11.1373934983598; Mon, 15 Jul 2013 17:36:23 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Mon, 15 Jul 2013 17:36:23 -0700 (PDT) In-Reply-To: <20130715235956.10891.39451.idtracker@ietfa.amsl.com> References: <20130715235956.10891.39451.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 20:36:23 -0400 X-Google-Sender-Auth: 7CDBTe3ABwbN1LuMSpauUNuydq4 Message-ID: From: Kerry Lynn To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff242a3a45cfb04e1962abd Subject: [mdnsext] Fwd: New Version Notification for draft-lynn-mdnsext-requirements-02.txt 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: Tue, 16 Jul 2013 00:36:35 -0000 --e89a8ff242a3a45cfb04e1962abd Content-Type: text/plain; charset=ISO-8859-1 Greetings, This is only a very minor update: 1. Refresh the date to prevent expiration 2. Add the "one laptop, one printer" use case which I inadvertently omitted from earlier versions. This is basically a marker to remind us that the base case is no infrastructure of any sort, but also that there are M's of mDNS servers (e.g. printers) already deployed that will never be updated. We cannot afford to strand them. I submitted this as mdnsext-requirements-02. When the name of the WG is decided then the secretariat can rename the draft. I will try to upload a more comprehensive update before the BoF (I will not be attending IETF 87). Lastly, after checking with Stuart, the previous message I posted re: IPR statement was intended by Apple to apply to http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid and not the requirements draft. This too will be sorted in time. Sorry I will be missing the excitement in Berlin... Regards, -K- ---------- Forwarded message ---------- From: Date: Mon, Jul 15, 2013 at 7:59 PM Subject: New Version Notification for draft-lynn-mdnsext-requirements-02.txt To: Stuart Cheshire , Kerry Lynn A new version of I-D, draft-lynn-mdnsext-requirements-02.txt has been successfully submitted by Kerry Lynn and posted to the IETF repository. Filename: draft-lynn-mdnsext-requirements Revision: 02 Title: Requirements for DNS-SD/mDNS Extensions Creation date: 2013-07-16 Group: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-lynn-mdnsext-requirements-02.txt Status: http://datatracker.ietf.org/doc/draft-lynn-mdnsext-requirements Htmlized: http://tools.ietf.org/html/draft-lynn-mdnsext-requirements-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-lynn-mdnsext-requirements-02 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. The IETF Secretariat --e89a8ff242a3a45cfb04e1962abd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

This is only a very minor update:

1. Refresh the d= ate to prevent expiration

2. Add the "one laptop, one printer&q= uot; use case which I inadvertently omitted from
=A0 =A0 earlier version= s.=A0 This is basically a marker to remind us that the base case is no
=A0 =A0 infrastructure of any sort, but also that there are M's of mDNS= servers (e.g. printers)
=A0=A0=A0 already deployed that will never be = updated.=A0 We cannot afford to strand them.

I submitted this as mdn= sext-requirements-02.=A0 When the name of the WG is decided
then the secretariat can rename the draft.=A0 I will try to upload a more c= omprehensive
update before the BoF (I will not be attending IETF 87).
Lastly, after checking with Stuart, the previous message I posted re: = IPR statement
was intended by Apple to apply to http://tools.ietf.org/html/draft-cheshire-mdnse= xt-hybrid
and not the requirements draft.=A0 This too will be sorted= in time.

Sorry I will be missing the excitement in Berlin...

Regards, -K-=


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul= 15, 2013 at 7:59 PM
Subject: New Version Notification for draft-lynn-mdnsext-requirements-02.tx= t
To: Stuart Cheshire <cheshire@apple.com>, Kerry Lynn <kerlyn@ieee.org>



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

Filename: =A0 =A0 =A0 =A0draft-lynn-mdnsext-requirements
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Requirements for DNS-SD/mDNS Extensions
Creation date: =A0 2013-07-16
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.= org/internet-drafts/draft-lynn-mdnsext-requirements-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/d= oc/draft-lynn-mdnsext-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-= lynn-mdnsext-requirements-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/r= fcdiff?url2=3Ddraft-lynn-mdnsext-requirements-02

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.



The IETF Secretariat


--e89a8ff242a3a45cfb04e1962abd-- 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 C5B4D21E8092 for ; Mon, 15 Jul 2013 15:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 r09S8vZg2fCv for ; Mon, 15 Jul 2013 15:50:35 -0700 (PDT) Received: from mo3.mail-out.ovh.net (4.mo3.mail-out.ovh.net [178.33.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id C64D121E812E for ; Mon, 15 Jul 2013 15:50:34 -0700 (PDT) Received: from mail171.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with SMTP id D3E54FF90A6 for ; Tue, 16 Jul 2013 00:50:31 +0200 (CEST) Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 16 Jul 2013 00:50:30 +0200 Received: from mail-vc0-f181.google.com (cedric@dessez.fr@209.85.220.181) by ns0.ovh.net with SMTP; 16 Jul 2013 00:50:29 +0200 Received: by mail-vc0-f181.google.com with SMTP id lf11so3259vcb.12 for ; Mon, 15 Jul 2013 15:50:28 -0700 (PDT) X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=cdf25pTIbz1SLuZEufeqdP8rL82PdSanP6GNVr17QUQ=; b=I9o/9HB/r5liRR+jlUvjgLu4fIZzCDTYgEON+rAGsXJGT93NjIZE4tH+wGW3sf2SIH SQC0ffOGWsc1+vR5l8o+cCJyFwKW56xN5m6lrczD1qMVz4shXf8959KpG9fDgne1cmgr AJXF65Gdp6UZIU/CmX/qEWH0qXJqs12JwNCDJimtHQ+6hCZqcAVgC6ihVJO1QjyhJTtZ RE4vzUf3PzapwsoCsZ1uFUpd7EDeEdg8lSZ5hYkeaY0nmSH5wrdc0FgfH2L3Yc9fSmcT VsJB7NKd63OO9GkuHbhz/rzi+5Wo39Arn1mykABELEZQQPHXu2UbCRcZOyP+uu7V2oYO Es6Q== MIME-Version: 1.0 X-Received: by 10.52.90.50 with SMTP id bt18mr24620631vdb.35.1373928628320; Mon, 15 Jul 2013 15:50:28 -0700 (PDT) Received: by 10.58.147.4 with HTTP; Mon, 15 Jul 2013 15:50:28 -0700 (PDT) Date: Tue, 16 Jul 2013 00:50:28 +0200 Message-ID: X-Ovh-Mailout: 178.32.228.3 (mo3.mail-out.ovh.net) From: =?ISO-8859-1?Q?C=E9dric_Dessez?= To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec50162afd682ce04e194af35 X-Ovh-Tracer-Id: 8986088632375262914 X-Ovh-Remote: 209.85.220.181 (mail-vc0-f181.google.com) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeijedrvdduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Spam-Check: DONE|U 0.5/N X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeijedrvdduucetufdoteggodetrfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-Mailman-Approved-At: Mon, 15 Jul 2013 17:22:58 -0700 Subject: [mdnsext] New draft: draft-dessez-homenet-googleplus-interconnect 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, 15 Jul 2013 22:50:40 -0000 --bcaec50162afd682ce04e194af35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear readers of the mailing list, I have submitted a draft which describes an experiment for connecting home networks via social networks. This allows the access to devices or services within a home to be granted among home networks based on their relation to one another within the social network. It uses the Hybrid DNS-SD approach described in draft-cheshire-mdnsext-hybrid and draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf to enable Service Discovery among multiple home networks. URL: http://tools.ietf.org/html/draft-dessez-homenet-googleplus-interconnec= t Comments are welcome. I will be in Berlin if anyone wants to speak about this in person with me, or if the BoF would like a short presentation. Best regards, -- C=E9dric DESSEZ --bcaec50162afd682ce04e194af35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear readers of the mailing list,

I have submitted a draft which describes an experiment for connecting home networks via social networks. This allo= ws the access to devices or services within a home to be granted among home= networks based on their relation to one another within the social network<= /span>. It use= s the Hybrid DNS-SD approach described in dr= aft-cheshire-mdnsext-hybrid=A0and=A0draft-stenber= g-homenet-dnssd= ext-hybrid-proxy-ospf=A0to enable = Service Discovery among multiple home networks.


Comments are welcome.
I will be in Berlin if anyone wants t= o speak about this in person with me, or if the BoF<= /span> would like a short presentation.

Best regards,

--
C=E9dric DESSEZ
--bcaec50162afd682ce04e194af35-- 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 360A811E80D9 for ; Thu, 11 Jul 2013 18:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.148 X-Spam-Level: X-Spam-Status: No, score=-0.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] 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 C7VH84Y2AV57 for ; Thu, 11 Jul 2013 18:25:04 -0700 (PDT) Received: from mail.ctbri.com.cn (mail.ctbri.com.cn [219.142.69.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADE111E81F0 for ; Thu, 11 Jul 2013 18:25:03 -0700 (PDT) Received: from ctbriwangaij ([10.9.53.90]) by mail.ctbri.com.cn (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013071209245413-77122 ; Fri, 12 Jul 2013 09:24:54 +0800 From: "Aijun Wang" To: "'Ralph Droms \(rdroms\)'" , References: <4518F39EB578034D8C99A9B7776CDBA3785D4E@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA3785D4E@xmb-aln-x04.cisco.com> Date: Fri, 12 Jul 2013 09:24:55 +0800 Message-ID: <002a01ce7e9e$9d8a4460$d89ecd20$@com.cn> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHOfj2KMKPaeTY5zkO+HeXGTso4AZlgPhjA X-MIMETrack: Itemize by SMTP Server on mailserver/ctbri(Release 8.5.3FP1|March 07, 2012) at 2013/07/12 09:24:54, Serialize by Router on mailserver/ctbri(Release 8.5.3FP1|March 07, 2012) at 2013/07/12 09:25:01, Serialize complete at 2013/07/12 09:25:01 X-TNEFEvaluated: 1 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01CE7EE1.ABAD8460" Content-Language: zh-cn Subject: Re: [mdnsext] BoF details 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, 12 Jul 2013 01:25:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01CE7EE1.ABAD8460 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="gb2312" Hi, all =20 Is it necessary to add some description in the charter part for = comparing the difficulty to accomplish the service registration and discovery in multi-link scenario by DNS update(RFC2136&RFC3007) plus DNS-SD(RFC = 6763)? =20 =20 Best Regards. =20 Aijun Wang =20 China Telecom Corporation Limited Beijing Research Institute=20 Network Infrastructure Reserach Division =20 Network Technology Research Department=20 Tel : 010-58552347 Mobile: 13301168517 =20 =20 =20 =B7=A2=BC=FE=C8=CB: mdnsext-bounces@ietf.org = [mailto:mdnsext-bounces@ietf.org] =B4=FA=B1=ED Ralph Droms (rdroms) =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C211=C8=D5 21:50 =CA=D5=BC=FE=C8=CB: mdnsext@ietf.org =D6=F7=CC=E2: [mdnsext] BoF details =20 Here is the draft agenda for the BoF (with minor correction): BoF Logistics: 0900-1130 CEST Wednesday (7/31/13) Draft agenda (2 hr scheduled for 2.5 hr meeting slot) 1. Administrivia (Chairs, 5 mins) =20 Note Well and agenda bashing 2. Goals of the BoF (Chairs, 15 mins) Review of IETF 85 mdsnext BoF and progress since then 3. Requirements (TBD, 30 mins) draft-lynn-mdnsext-requirements-01 4. Open discussion (Chairs, 40 mins) Open mic; includes draft charter and deliverables 5. Key questions (Chairs, 30 mins) Are we ready to form a WG with the agreed charter, subject to mail list confirmation? =20 Note RFC5434 section 1. The draft charter is attached (this time for sure). Review and comment requested... - Ralph ------=_NextPart_000_002B_01CE7EE1.ABAD8460 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="gb2312"

Hi, all

 

Is it necessary to add  some description in the charter part for = comparing the difficulty to accomplish the service registration and = discovery in multi-link scenario by DNS update(RFC2136&RFC3007) plus = DNS-SD(RFC 6763)?  

 

Best Regards.

 

Aijun Wang

 

China Telecom Corporation Limited Beijing Res= earch Institute 

Network Infrastructure Reserach Division  

Network Technology Research Department =

Tel : 010-58552347

Mobile:  = 13301168517

 

 

 

=B7=A2=BC=FE=C8=CB: = mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] = =B4=FA=B1=ED = Ralph Droms = (rdroms)
=B7=A2=CB=CD=CA=B1=BC= =E4: 2013=C4=EA7=D4=C211=C8=D5 21:50
=CA=D5=BC=FE=C8=CB: = mdnsext@ietf.org
=D6=F7=CC=E2: [mdnsext] BoF = details

 

Here is the draft agenda for the BoF (with = minor correction):

BoF Logistics: 0900-1130 CEST Wednesday = (7/31/13)

Draft agenda (2 hr scheduled for 2.5 hr meeting = slot)
1. Administrivia (Chairs, 5 mins)  
   = Note Well and agenda bashing

2. Goals of the BoF (Chairs, 15 = mins)
   Review of IETF 85 mdsnext BoF and progress since = then

3. Requirements (TBD, 30 mins)
   = draft-lynn-mdnsext-requirements-01

4. Open discussion (Chairs, 40 = mins)
   Open mic; includes draft charter and = deliverables

5. Key questions (Chairs, 30 mins)
   = Are we ready to form a WG with the agreed charter, subject to = mail
     list confirmation?  =
   Note RFC5434 section 1.

The draft charter is = attached (this time for sure).  Review and comment = requested...

- = Ralph



------=_NextPart_000_002B_01CE7EE1.ABAD8460-- 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 AF8AE11E8177 for ; Thu, 11 Jul 2013 06:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Gm7A2dbTIksR for ; Thu, 11 Jul 2013 06:50:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AF31A11E8115 for ; Thu, 11 Jul 2013 06:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9709; q=dns/txt; s=iport; t=1373550605; x=1374760205; h=from:to:subject:date:message-id:mime-version; bh=WN6LGQKeWgWDVQOpm4U7M5bT7Begg79JYFI5q1DHb1o=; b=eEfLcDpHoK/xo723WQE5Xwz6L2H4AqPvFwWFkwD8lHOjur2bHSrb9fcy yxBhB4os86J5RQkURuJJJiYQcQ6HqcOD0+yr7H2hSvKnlbIYasIMsbK28 4yOZV6feiTOLRfaIXSrUiiJU9xGWmXlxiEUIaOYVUJZReUDjxvS2h+TVI k=; X-Files: charter-20130711.txt : 4657 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAJid3lGtJXHB/2dsb2JhbABagkVEMk3BUIEGFnSCJQEEAQEBax0BDAEdAiQfBgsnBBMIAQUNh2IDDwyWeZddDYhRjGoOgTeBAYNBbAOQDoM0gi+ODYUmgxGBcTc X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800"; d="txt'?scan'208,217";a="233583166" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 11 Jul 2013 13:50:04 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6BDo4Qc003030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jul 2013 13:50:04 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.239]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:50:03 -0500 From: "Ralph Droms (rdroms)" To: "mdnsext@ietf.org" Thread-Topic: BoF details Thread-Index: AQHOfj2KMKPaeTY5zkO+HeXGTso4AQ== Date: Thu, 11 Jul 2013 13:50:02 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA3785D4E@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.164.58] Content-Type: multipart/mixed; boundary="_004_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_" MIME-Version: 1.0 Subject: [mdnsext] BoF details 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, 11 Jul 2013 13:50:10 -0000 --_004_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_ Content-Type: multipart/alternative; boundary="_000_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_" --_000_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the draft agenda for the BoF (with minor correction): BoF Logistics: 0900-1130 CEST Wednesday (7/31/13) Draft agenda (2 hr scheduled for 2.5 hr meeting slot) 1. Administrivia (Chairs, 5 mins) Note Well and agenda bashing 2. Goals of the BoF (Chairs, 15 mins) Review of IETF 85 mdsnext BoF and progress since then 3. Requirements (TBD, 30 mins) draft-lynn-mdnsext-requirements-01 4. Open discussion (Chairs, 40 mins) Open mic; includes draft charter and deliverables 5. Key questions (Chairs, 30 mins) Are we ready to form a WG with the agreed charter, subject to mail list confirmation? Note RFC5434 section 1. The draft charter is attached (this time for sure). Review and comment req= uested... - Ralph --_000_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Here is the draft agenda for the BoF (with minor c= orrection):

BoF Logistics: 0900-1130 CEST Wednesday (7/31/13)

Draft agenda (2 hr scheduled for 2.5 hr meeting slot)
1. Administrivia (Chairs, 5 mins)  
   Note Well and agenda bashing

2. Goals of the BoF (Chairs, 15 mins)
   Review of IETF 85 mdsnext BoF and progress since then

3. Requirements (TBD, 30 mins)
   draft-lynn-mdnsext-requirements-01

4. Open discussion (Chairs, 40 mins)
   Open mic; includes draft charter and deliverables

5. Key questions (Chairs, 30 mins)
   Are we ready to form a WG with the agreed charter, subject to = mail
     list confirmation? 
   Note RFC5434 section 1.

The draft charter is attached (this time for sure).  Review and commen= t requested...

- Ralph




--_000_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_-- --_004_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_ Content-Type: text/plain; name="charter-20130711.txt" Content-Description: charter-20130711.txt Content-Disposition: attachment; filename="charter-20130711.txt"; size=4657; creation-date="Thu, 11 Jul 2013 13:50:02 GMT"; modification-date="Thu, 11 Jul 2013 13:50:02 GMT" Content-ID: Content-Transfer-Encoding: base64 R3JvdXAgTmFtZToJRE5TIFNlcnZpY2UgRGlzY292ZXJ5IEV4dGVuc2lvbnMNCkFjcm9ueW06CWRu c3NkZXh0DQpBcmVhOgkJSW50ZXJuZXQgQXJlYSAoaW50KQ0KU3RhdGU6CQlBY3RpdmUNCkNoYXJ0 ZXI6CWNoYXJ0ZXItaWV0Zi1kaGMtMDYtMDEgKEluZm9ybWFsIElFU0cgcmV2aWV3KQ0KQ2hhaXIg KEJvRik6CVRpbSBDaG93biA8dGpjQGVjcy5zb3Rvbi5hYy51az4NCiAgICAgIAkJUmFscGggRHJv bXMgPHJkcm9tcy5pZXRmQGdtYWlsLmNvbT4NCkFyZWEgRGlyZWN0b3I6CVRlZCBMZW1vbiA8dGVk LmxlbW9uQG5vbWludW0uY29tPg0KDQpNYWlsaW5nIExpc3QNCkFkZHJlc3M6CW1kbnNleHRAaWV0 Zi5vcmcNClRvIFN1YnNjcmliZToJaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21kbnNleHQNCkFyY2hpdmU6CWh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9t ZG5zZXh0Lw0KDQpDaGFydGVyOg0KDQpDdXJyZW50bHksIHplcm9jb25mIG5ldHdvcmtpbmcgcHJv dG9jb2xzIGFyZSBnZW5lcmFsbHkgdXNlZCB0bw0KZGlzY292ZXIgc2VydmljZXMgd2l0aGluIHRo ZSBzY29wZSBvZiBhIHNpbmdsZSBsaW5rLiBJbiBwYXJ0aWN1bGFyLA0KdGhlIEJvbmpvdXIgcHJv dG9jb2xzIHN1aXRlLCBjb21wcmlzaW5nIG1ETlMgKFJGQyA2NzYyKSBhbmQgRE5TLVNEDQooUkZD IDY3NjMpLCBhcmUgd2lkZWx5IHVzZWQgZm9yIGRpc2NvdmVyeSBhbmQgcmVzb2x1dGlvbiBvZiBz ZXJ2aWNlcw0KYW5kIG5hbWVzIG9uIGEgc2luZ2xlIGxpbmsuDQoNClRoZSBCb25qb3VyIHByb3Rv Y29sIHN1aXRlIGlzIGNvbW1vbmx5IHVzZWQgaW4gbWFueSBzY2VuYXJpb3MsDQppbmNsdWRpbmcg aG9tZSBuZXR3b3JrcywgY29tbWVyY2lhbCBhbmQgY2FtcHVzIGVudGVycHJpc2UgbmV0d29ya3Ms DQphbmQgbWF5IGJlIG9mIHVzZSBpbiBjZXJ0YWluIG1lc2ggbmV0d29ya3MuICBIb3dldmVyLCB0 aGUgbXVsdGljYXN0DQpCb25qb3VyIHByb3RvY29scyBhcmUgY29uc3RyYWluZWQgdG8gbGluay1s b2NhbCBzY29wZSwgc28gY2FuIG9ubHkgYmUNCnVzZWQgdG8gZGlzY292ZXIgc2VydmljZXMgb24g dGhlIHNhbWUgbGluay4gSW4gYSB0eXBpY2FsIGN1cnJlbnQgaG9tZQ0KbmV0d29yaywgd2hpY2gg aXMgYSBzaW5nbGUgbGluaywgdXNlcnMgc2hvdWxkIGV4cGVyaWVuY2UgdGhlIGRlc2lyZWQNCmRp c2NvdmVyeSBiZWhhdmlvci4gSG93ZXZlciwgaW4gZnV0dXJlIG11bHRpLWxpbmsgaG9tZSBuZXR3 b3JrcyAoYXMNCmVudmlzYWdlZCBieSB0aGUgaG9tZW5ldCBXRykgYW5kIGluIHJvdXRlZCBjYW1w dXMgb3IgZW50ZXJwcmlzZQ0KbmV0d29ya3MsIGRldmljZXMgYW5kIHRodXMgdXNlcnMgY2FuIG9u bHkgZGlzY292ZXIgc2VydmljZXMgb24gdGhlDQpzYW1lIGxpbmssIHdoaWNoIGlzIGEgc2lnbmlm aWNhbnQgbGltaXRhdGlvbi4gU3VjaCBsaW1pdGF0aW9ucyBoYXZlDQpsZWQgdG8gY2FsbHMsIHN1 Y2ggYXMgdGhvc2UgYnkgdGhlIEVkdWNhdXNlIHBldGl0aW9uLCB0byBkZXZlbG9wIGFuDQphcHBy b3ByaWF0ZSBzb2x1dGlvbiB0byBzcGFuIG11bHRpcGxlIGxpbmtzLCBvciB0byBwZXJmb3JtIGRp c2NvdmVyeQ0KYWNyb3NzIGEgd2lkZSBhcmVhIChub3QgbmVjZXNzYXJpbHkgb24gZGlyZWN0bHkg Y29ubmVjdGVkIGxpbmtzKS4NCg0KSW4gYWRkaXRpb24sIHRoZSBaaWdCZWUgQWxsaWFuY2UgU21h cnQgRW5lcmd5IFByb2ZpbGUgMi4wIGNvbW1lcmNpYWwNCnN0YW5kYXJkIGN1cnJlbnRseSB1bmRl ciBkZXZlbG9wbWVudCBoYXMgc3BlY2lmaWVkIHRoZSBCb25qb3VyDQpwcm90b2NvbHMgYXMgaXRz IG1ldGhvZCBvZiB6ZXJvIGNvbmZpZ3VyYXRpb24gZGlzY292ZXJ5LiBIb3dldmVyLCBpdHMNCnVz ZSBvZiB3aXJlbGVzcyBtZXNoIG11bHRpLWxpbmsgc3VibmV0cyBhbmQgaXRzIHVzZSBhY3Jvc3Mg dHJhZGl0aW9uYWwNCnJvdXRlZCBuZXR3b3JrcyB3aWxsIHJlcXVpcmUgZXh0ZW5zaW9ucyB0byB0 aGUgQm9uam91ciBwcm90b2NvbHMgdG8NCmFsbG93IG9wZXJhdGlvbiBhY3Jvc3MgbXVsdGlwbGUg bGlua3MuDQoNCkFzIGRlbWFuZCBmb3Igc2VydmljZSBkaXNjb3ZlcnkgYWNyb3NzIHdpZGVyIGFy ZWEgcm91dGVkIG5ldHdvcmtzDQpncm93cywgc29tZSB2ZW5kb3JzIGFyZSBiZWdpbm5pbmcgdG8g c2hpcCB0aGVpciBvd24gZWFybHkNCnNvbHV0aW9ucy4gSXQgaXMgdGh1cyBib3RoIHRpbWVseSBh bmQgaW1wb3J0YW50IHRoYXQgZWZmb3J0cyB0bw0KZGV2ZWxvcCBpbXByb3ZlZCwgc2NhbGFibGUs IGF1dG9ub21vdXMgc2VydmljZSBkaXNjb3Zlcnkgc29sdXRpb25zIGZvcg0Kcm91dGVkIG5ldHdv cmtzIGFyZSBjb29yZGluYXRlZCB0b3dhcmRzIHByb2R1Y2luZyBhIHNpbmdsZSwgc3RhbmRhcmRz LQ0KYmFzZWQgc29sdXRpb24uDQoNCkdvYWxzDQoNClRvIHRoYXQgZW5kLCB0aGUgcHJpbWFyeSBn b2FscyBvZiB0aGUgZG5zc2RleHQgV0cgYXJlIGFzIGZvbGxvd3M6DQoNCjEuIFRvIGRvY3VtZW50 IGEgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3Igc2NhbGFibGUsIGF1dG9ub21vdXMNCiAgIEROUy1i YXNlZCBzZXJ2aWNlIGRpc2NvdmVyeSBpbiByb3V0ZWQsIG11bHRpLWxpbmsgbmV0d29ya3MgaW4g dGhlDQogICBmb2xsb3dpbmcgZm91ciBzY2VuYXJpb3M6DQoNCiAgICBhKSBDb21tZXJjaWFsIGVu dGVycHJpc2UgbmV0d29ya3MNCiAgICBiKSBBY2FkZW1pYy9lZHVjYXRpb25hbC91bml2ZXJzaXR5 IGNhbXB1cyBuZXR3b3Jrcw0KICAgIGMpIE11bHRpLWxpbmsgaG9tZSBuZXR3b3Jrcywgc3VjaCBh cyB0aG9zZSBlbnZpc2FnZWQgYnkgdGhlDQogICAgICAgSE9NRU5FVCBXRyANCiAgICBkKSBNdWx0 aS1saW5rL3NpbmdsZSBzdWJuZXQgKG1lc2gpIG5ldHdvcmtzLCBzdWNoIGFzIHRob3NlDQogICAg ICAgZGVzY3JpYmVkIGJ5IHRoZSBaaWdCZWUgQWxsaWFuY2UgWi1JUCBzcGVjaWZpY2F0aW9uDQoN CjIuIFRvIGRldmVsb3AgYW4gaW1wcm92ZWQsIHNjYWxhYmxlIHNvbHV0aW9uIGZvciB3aWRlLWFy ZWEgc2VydmljZQ0KICAgZGlzY292ZXJ5IHRoYXQgY2FuIG9wZXJhdGUgaW4gbXVsdGktbGluayBu ZXR3b3JrcywgYXBwbGljYWJsZSB0bw0KICAgdGhlIHNjZW5hcmlvcyBhYm92ZS4NCg0KMy4gVG8g ZGV2ZWxvcCBhIEJDUCBmb3IgdGhlIGNvZXhpc3RlbmNlIG9mIHplcm9jb25mIChtRE5TKSBhbmQg dW5pY2FzdA0KICAgKGdsb2JhbCBETlMpIG5hbWUgc2VydmljZXMgaW4gc3VjaCBtdWx0aS1saW5r IG5ldHdvcmtzLCB3aGljaA0KICAgc2hvdWxkIGluY2x1ZGUgY29uc2lkZXJhdGlvbiBvZiBib3Ro IHRoZSBuYW1lIHJlc29sdXRpb24gbWVjaGFuaXNtDQogICBhbmQgdGhlIG5hbWVzcGFjZS4NCg0K SXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIGRuc3NkZXh0IFdHIHRha2VzIGlucHV0IGZyb20gc3Rh a2Vob2xkZXJzIGluDQp0aGUgc2NlbmFyaW9zIGl0IGlzIGNvbnNpZGVyaW5nLiBGb3IgZXhhbXBs ZSwgdGhlIGhvbWVuZXQgV0cgaXMNCmN1cnJlbnRseSBldmFsdWF0aW5nIGl0cyBvd24gcmVxdWly ZW1lbnRzIGZvciBuYW1pbmcgYW5kIHNlcnZpY2UNCmRpc2NvdmVyeTsgaXQgaXMgdXAgdG8gdGhl IGhvbWVuZXQgV0cgYXMgdG8gd2hldGhlciBpdCB3aXNoZXMgdG8NCnJlY29tbWVuZCBhZG9wdGlv biBvZiB0aGUgc29sdXRpb24gZGV2ZWxvcGVkIGluIHRoZSBkbnNzZGV4dCBXRywgYW5kDQp0aHVz IGNvb3JkaW5hdGlvbiBiZXR3ZWVuIHRoZSBXR3MgaXMgZGVzaXJhYmxlLg0KDQpEZWxpdmVyYWJs ZXMNCg0KVGhlIFdHIHdpbGwgcHJvZHVjZSB0aHJlZSBkb2N1bWVudHM6IGFuIEluZm9ybWF0aW9u YWwgUkZDIG9uIHRoZQ0KcmVxdWlyZW1lbnRzIGZvciB3aWRlLWFyZWEgc2VydmljZSBkaXNjb3Zl cnkgcHJvdG9jb2xzOyBhIFN0YW5kYXJkcw0KVHJhY2sgUkZDIGRvY3VtZW50aW5nIGEgd2lkZS1h cmVhIHNlcnZpY2UgZGlzY292ZXJ5IHNvbHV0aW9uIHRoYXQgaXMNCmFwcGxpY2FibGUgdG8gdGhv c2Ugc2NlbmFyaW9zOyBhbmQgYSBCQ1AgZG9jdW1lbnQgZGVzY3JpYmluZyB0aGUgbW9zdA0KZWZm ZWN0aXZlIG1ldGhvZCB0byBpbnRlZ3JhdGUgbUROUyBhbmQgZ2xvYmFsIEROUyBuYW1lIHNlcnZp Y2VzLg0KDQpNaWxlc3RvbmVzDQoNClNlcCAyMDEzIEZvcm1hdGlvbiBvZiB0aGUgV0cNCk9jdCAy MDEzIEFkb3B0IHJlcXVpcmVtZW50cyBkcmFmdCBhcyBXRyBkb2N1bWVudA0KTm92IDIwMTMgU3Vi bWl0IHJlcXVpcmVtZW50cyBkcmFmdCB0byB0aGUgSUVTRyBhcyBhbiBJbmZvcm1hdGlvbmFsIFJG Qw0KTWFyIDIwMTQgQWRvcHQgd2lkZS1hcmVhIHNlcnZpY2UgZGlzY292ZXJ5IHNvbHV0aW9uIGRy YWZ0IGFzIFdHDQogICAgICAgICBkb2N1bWVudCANCk1hciAyMDE0IEFkb3B0IHplcm9jb25mIGFu ZCB1bmljYXN0IEROUyBpbnRlZ3JhdGlvbiBCQ1AgZHJhZnQgYXMgV0cNCiAgICAgICAgIGRvY3Vt ZW50IA0KU2VwIDIwMTQgU3VibWl0IHdpZGUtYXJlYSBzZXJ2aWNlIGRpc2NvdmVyeSBzb2x1dGlv biBkcmFmdCB0byB0aGUgSUVTRw0KICAgICAgICAgYXMgU3RhbmRhcmRzIFRyYWNrIFJGQyANClNl cCAyMDE0IFN1Ym1pdCB6ZXJvY29uZiBhbmQgdW5pY2FzdCBETlMgaW50ZWdyYXRpb24gc29sdXRp b24gZHJhZnQgdG8NCiAgICAgICAgIHRoZSBJRVNHIGFzIEJDUCANCg== --_004_4518F39EB578034D8C99A9B7776CDBA3785D4Exmbalnx04ciscocom_-- 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 9114521F9ADD for ; Thu, 11 Jul 2013 06:45:59 -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 WYHUoje+xju5 for ; Thu, 11 Jul 2013 06:45:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2517421F9AAE for ; Thu, 11 Jul 2013 06:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=743; q=dns/txt; s=iport; t=1373550353; x=1374759953; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=l7fmZ4IC6SPYoGBklMSA/tFBWCwcsQdXOo7Rir5seq0=; b=F6byGNQxQIrWimeMk/ugYlOhEKZsy5e69O6LR++d96CCmT2aggMC+am+ IQXjGvo8+hXJWENgqIUeyfalDe4/w7jT1bF9ItS14OAS8WnQfg9DLQcLL 5jL2fP3n277ZditZIdx9hg9IuC3RloSY0wLPQAMU4nuoll08t5Nvt+c7j 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAJid3lGtJXG9/2dsb2JhbABagwl/wVCBBhZ0giUBBDpRASoUQicEG4gHlwWgO44vgQGDQWwDqSSDEYFxNw X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800"; d="scan'208";a="233372113" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2013 13:45:52 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6BDjqQV025673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jul 2013 13:45:52 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.239]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:45:52 -0500 From: "Ralph Droms (rdroms)" To: "mdnsext@ietf.org" Thread-Topic: BoF details Thread-Index: AQHOfjz1Q2QrUK1p6k2ri/EBpUPjrQ== Date: Thu, 11 Jul 2013 13:45:51 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA3785CD3@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.116.164.58] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mdnsext] BoF details 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, 11 Jul 2013 13:45:59 -0000 Here is the draft agenda for the BoF: BoF Logistics: 0900-1130 CEST Wednesday (7/31/13) Draft agenda (2 hr scheduled for 2.5 hr meeting slot) 1. Administrivia (Chairs, 5 mins) =20 Note Well and agenda bashing 2. Goals of the BoF (Chairs, 15 mins) Review of IETF 85 mdsnext BoF and progress since then 3. Requirements (TBD, 30 mins) draft-lynn-sadnssd-requirements-01 4. Open discussion (Chairs, 40 mins) Open mic; includes draft charter and deliverables =20 5. Key questions (Chairs, 30 mins) Are we ready to form a WG with the agreed charter, subject to mail list confirmation? =20 Note RFC5434 section 1. The draft charter is attached. Review and comment requested... - Ralph