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 CA40421F8A14 for ; Thu, 31 Jan 2013 16:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6z3mOPQr8a7 for ; Thu, 31 Jan 2013 16:41:05 -0800 (PST) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id B4A7F21F8A0C for ; Thu, 31 Jan 2013 16:40:59 -0800 (PST) Received: from mail-ob0-f200.google.com (mail-ob0-f200.google.com [209.85.214.200]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Thu, 31 Jan 2013 18:40:48 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ob0-f200.google.com [209.85.214.200] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f200.google.com with SMTP id un3so19124263obb.11 for ; Thu, 31 Jan 2013 16:40:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=2wkc4sD7JVx6gwo1amwWSxg++AbNFOIwRHVLYvjgTms=; b=JQDlPr0EsNMbIAagZmRYY9Qybk1RilSGSkZ2UhpMKuS2P/GYhSEv0oO8olutjJuL8y 11yQKTCV35VW+D5JlRazspFWAhOLGEioJJP2CNmNij09jWrAvXp0ya2hsG6hpUnIt886 FNTf3XQ8qobC8G+cjE4ljcPEiupU28O/qcypugBJ+l+uiqAkQwQAj8pjn6Hi3gAfI45F wSRgNMcosfzX7k71NRMJLyHLMF6qW43wZQcYHY98mq3ZvpGZcDYpIGHPNFgp9UvyHCIL SN8zoXUCfUHQDKvpezSL6e61A694bYoevLZ9jWBAWeH4vn/ybXoOSZv975uKOmDpW9P4 jUqg== X-Received: by 10.42.91.7 with SMTP id n7mr8271195icm.40.1359679248372; Thu, 31 Jan 2013 16:40:48 -0800 (PST) X-Received: by 10.42.91.7 with SMTP id n7mr8271191icm.40.1359679248286; Thu, 31 Jan 2013 16:40:48 -0800 (PST) Received: from x-134-84-88-68.nts.umn.edu (x-134-84-88-68.nts.umn.edu. [134.84.88.68]) by mx.google.com with ESMTPS id k5sm355380igq.9.2013.01.31.16.40.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Jan 2013 16:40:47 -0800 (PST) Message-ID: <510B0F0E.5030608@umn.edu> Date: Thu, 31 Jan 2013 18:40:46 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Stuart Cheshire References: <65245680-41DC-4B28-98FE-9EA97C6EB06E@apple.com> In-Reply-To: <65245680-41DC-4B28-98FE-9EA97C6EB06E@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlq2mTRGQ8p6XPUf4JiXsjBGsMLdUAU4jD+qshLrk6eJ41Z/5AXvSIz1i8hAwTHo1k87TkOLJwh2z6Iu2jO6zFuQIU+drY56tCcRLjVQh03BBUEuTLG/Bw7ugx8YKGzjiZzPSua Cc: IETF mdnsext , Kerry Lynn , David Farmer Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-01.txt X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer 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, 01 Feb 2013 00:41:05 -0000 On 1/24/13 23:41 , Stuart Cheshire wrote: > We just submitted draft-lynn-mdnsext-requirements-01.txt > > > > Please review and give feedback. > > The deadline is next Thursday for the IESG to decide whether to schedule an mdnsext BoF meeting at IETF 86 in March, so any discussion before that date is useful for helping them make their decision. Here are a few comments; 1. In the second paragraph of of the Intro, I'd like to add the concern that the different ad-hoc techniques, when used together at best will likely produce unpredictable results, and at worst will be completely incompatible and break services. 2. Section 2.1 seems focused on supporting the large scale enterprise network environment, especially the technical summary. While it is important to have solutions for these large scale enterprise network environments with 10s of thousands of devices on the network, this is just the opposite extreme from the link-local environment. We MUST NOT forget the 20 to 200 node network that is just big enough to need more than one link segment, maybe just simply separate wired and wireless segments, but probably no more than a hand full of segments. The more important issue here is they might have a jack-of-all-trades one-(wo)man IT department, but probably not specialized networking staff, an surely not a fully qualified network engineering staff. So the requirement for a breadth or continuum of solutions should be made more clear. 3. While Section 2.2 is true in general, this is particularly problematic in very large scale 802.11 networks, that are focused on density of coverage, with hundreds to thousands of devices in the same air space using the same network. 4. Namespace Scope, Address Scope, v4-v6 Dual-Stack, packet TTL, and policy; The interaction namespace with GUA and link-local addressing, IPv4 and IPv6, and the TTL that applications use after service discovery needs discussion along with global vs ".local" namespaces. - If ".local" is to remain a link-local only name space then some kind of ".site" namespace needs to be considered, and maybe ad-hoc local or site namespaces as well. I can easily see wanting to keep your authoritative global DNS namespace separate from this local or site service discovery namespace. Or the policy and security consideration for local or site namespace are very much different from authoritative global DNS namespace for most organizations. At the very least these trade-offs need to be discussed. - mDNS use of IPv6 link-local means multi-link use is currently restricted to IPv4, because host use their IPv4 GUA address if they have one. So the address scope used has impacts on reachability of services and the usability the namespace. - Some applications highly restrict the TTL (I've seen TTL=2 for instance) of the packets used once a service is discovered. This means it could be possible to discover a service but have it maybe fail silently after discover because packet TTLs are exceeded between, this is especially possible if the service discovery path is incongruent to the packet forwarding path. 5. Location Services - Mobile devices (laptops, pads, phones, etc...) generally have very good location services these days, generally good enough to locate within the correct building or even a quadrant of a building. When you start dealing with locations privacy can become an issue, so we have to be careful, but this seem like a very useful concept to bring to bear when dealing with actual humans looking for things. Sort the list services closest to furthest. From a privacy point of view you probably want services to advertize their location and the querying device to order the list based on its location. Rather than the query including the location and disclosing the users location. I think this is too powerful and useful to be ignored. Flipping this around, there could be interesting considerations for networks that are themselves mobile. Think about Wifi networks on planes, trains, buses, and ships, telling the devices where the network is currently located or what services are available while in port or at the current station. I think that is enough for now, I'll let you chew on that for a while. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ 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 625DA21F875F for ; Thu, 31 Jan 2013 13:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxNYotDY2WvQ for ; Thu, 31 Jan 2013 13:54:21 -0800 (PST) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by ietfa.amsl.com (Postfix) with ESMTP id BF6C921F8438 for ; Thu, 31 Jan 2013 13:54:21 -0800 (PST) Received: by mail-ob0-f170.google.com with SMTP id wc20so3443516obb.15 for ; Thu, 31 Jan 2013 13:54:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=TEOo2Y+TfVtzPkbUgc/IZ6kpfO/NLkThTKkR0YNt+68=; b=ul7i5p4BNsIe9VR+IfUVj8G0FrbRo6M7nq/Q7yiZ/r0AgRRi9M632iPPWuXa6TJAXT bBNJbZ+85ZSz6/yGD3ONxA50d3/M7MKc6aWAzH/9f2iD/pqrH4VDMpYfYWmKUeWYTJzD Uzm9z2sQmGxgrgnwr2oyp5beJlSIfz5C40ukqRLUoRua15qrwcB+P1ROmnaD+uthhG3S BqAurblARi5eEYkl2TpQwXA3DLzdN3m1eY43hwjUXDu0l6E3jlt8PuQyN4zlFWdmtzZE rcUPV8JB85U4bF9x+QEEYwRoZjfgxrbnNnFjJQidBjsihCNKpNDeLraktc0v9z91YGEk mSzw== MIME-Version: 1.0 X-Received: by 10.182.73.67 with SMTP id j3mr6297945obv.102.1359669261324; Thu, 31 Jan 2013 13:54:21 -0800 (PST) Received: by 10.60.3.129 with HTTP; Thu, 31 Jan 2013 13:54:21 -0800 (PST) Date: Thu, 31 Jan 2013 16:54:21 -0500 Message-ID: From: Kerry Lynn To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=f46d0445187b554fe904d49cab40 Subject: [mdnsext] BoF postponement 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, 31 Jan 2013 21:54:22 -0000 --f46d0445187b554fe904d49cab40 Content-Type: text/plain; charset=ISO-8859-1 Greetings, The main organizers of the first BoF met with the responsible AD (Ralph Droms) yesterday to discuss our progress toward WG formation. Given the remaining amount of work it will take to make WG formation a "no brainer" from the IESG's perspective, it was felt prudent to delay the final BoF until Berlin. This is far better than scheduling it for Orlando and then canceling it at the last minute if we don't make sufficient progress in the next few weeks. Here's my short list of the remaining work: - Converge on a set of use cases and derived requirements in the form of the Requirements draft (yours truly, editor). This includes: * closer coordination with homenet and other WGs to ensure we're adequately capturing their requirements * more discussion on the security issues raised by extending DNS-SD/mDNS (i.e. a fairly complete "Security Considerations" section in the draft) * more discussion and representative examples of the "two namespaces" issue discussed on the list - Discussion of Stuart's http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid or other proposals - Convergence on the charter We plan to hold a Bar BoF in Orlando for interested parties. Date and time will be announced on the mailing list when the agenda comes out, then a place will be determined and announced in Orlando on 10 March. We trust the work on the list will continue unabated as we refine the requirements and move toward a solution. Special thanks to Tim Chown for pulling together the BoF Request earlier in the week and for his understanding that we'll use it all next time. Regards, Kerry Lynn --f46d0445187b554fe904d49cab40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings,

The main organizers of the first BoF met with the responsible AD (Ralph= Droms)
yesterday to discuss our progress toward WG formation.=A0 Given = the remaining
amount of work it will take to make WG formation a "n= o brainer" from the IESG's
perspective, it was felt prudent to delay the final BoF until Berlin.=A0 Th= is is far
better than scheduling it for Orlando and then canceling it at= the last minute if
we don't make sufficient progress in the next fe= w weeks.

Here's my short list of the remaining work:
- Converge on a set = of use cases and derived requirements in the form of the
=A0 Requirement= s draft (yours truly, editor).=A0 This includes:
=A0 * closer coordinati= on with homenet and other WGs=A0 to ensure we're adequately
=A0=A0=A0 capturing their requirements
=A0 * more discussion on the secu= rity issues raised by extending DNS-SD/mDNS
=A0=A0=A0 (i.e. a fairly com= plete "Security Considerations" section in the draft)
=A0 * mo= re discussion and representative examples of the "two namespaces"=
=A0=A0=A0 issue discussed on the list
- Discussion of Stuart's http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid
=A0 = or other proposals
- Convergence on the charter

We plan to hold a Bar BoF in Orlando for interested parties.=A0 Date an= d time will
be announced on the mailing list when the agenda comes out, = then a place will
be determined and announced in Orlando on 10 March.
We trust the work on the list will continue unabated as we refine the r= equirements
and move toward a solution.=A0 Special thanks to Tim Chown f= or pulling together
the BoF Request earlier in the week and for his unde= rstanding that we'll use it
all next time.

Regards, Kerry Lynn --f46d0445187b554fe904d49cab40-- 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 6817721F8B35 for ; Wed, 30 Jan 2013 06:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zBZOIyuLZ2kL for ; Wed, 30 Jan 2013 06:39:29 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 77C4721F854D for ; Wed, 30 Jan 2013 06:39:29 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id j34so751718qco.37 for ; Wed, 30 Jan 2013 06:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=B7Z1y9YCkqXU1j38E14a5pR6SljWxJDJuwhSjm/bNk0=; b=BnuMozjfrglEsEwb/Mu7W+XXIuvAUNRNnlPKiV27eWex1TK0yyEviHjBqfELUu3E1X YkLT2sGwteQjONx4471CC34G5+jvegR9phtm/kKhaDgPjfErq16z9eeqZjADS+t7TJga cTYssqyz0JC6rBgYGwUxe6Cm1qoj+dmngRbXp6Gq+mJz7uDDsNR5juakDicomj+CIK7a PNs2Xe2sZGvWrawm7+kwu1saE/zKcVFuY3pKu4BDrDPcIdi1IKVgaTL/weOT59OhGd1d R5Zx4VF+zUTQb1gtU0oGkePACC6iuqMfMTpx0vnMfxhVNmSJYSoSWhry1dNiBt5sVz6n Vw8Q== MIME-Version: 1.0 X-Received: by 10.229.78.87 with SMTP id j23mr1234175qck.87.1359556768829; Wed, 30 Jan 2013 06:39:28 -0800 (PST) Sender: olevon@gmail.com Received: by 10.49.81.102 with HTTP; Wed, 30 Jan 2013 06:39:28 -0800 (PST) In-Reply-To: References: <1359484752.31527.140661184088257.2DD91FC3@webmail.messagingengine.com> <51082424.9090404@networkcommons.org> Date: Wed, 30 Jan 2013 15:39:28 +0100 X-Google-Sender-Auth: XqB7CsM-QUdxc2VpXwZ7UgmEVfI Message-ID: From: Olivier Levon To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=00235429c7bc42144b04d4827a86 Subject: [mdnsext] mDNSext features/requirements rollup 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, 30 Jan 2013 14:40:20 -0000 --00235429c7bc42144b04d4827a86 Content-Type: text/plain; charset=ISO-8859-1 Hi, Some people did various patches to suport WAB in POSIX, like http://www.roguelazer.com/tips/2010/02/dynamic-dns-part-two/ or https://github.com/gkaindl/Community-mdnsResponder. They were published on the bonjour-dev mailing list. For my own use, I'm currently running my own patched version of POSIX mdnsresponder on two Ubuntu boxes (one client with mdnsresponder and one DNS server with dnsextd/bind). Best, Olivier On Tue, Jan 29, 2013 at 8:33 PM, vortex wrote: > > The problem has been that the POSIX and non-apple WAB component for > read/write DNS-SD under the bonjour stack has been broken and ignored > for years. > > Integrating mDNS & WAB has been close on impossible because of this > (reference all the frustrations on the bonjour-dev mailing list without > resolution, again, it's been years!). > > Alternate stacks such as avahi (non-cross platform) have waited for > "vital" security implementations for DNSSEC before implementing write > enabled DNS-SD (a big mistake IMHO!), and because DNSSEC is so hairy > this has not happened either (on their roadmap unimplemented/delayed for > years). > > WAB & m~DNS has had the potential to be an exciting cross platform > Internet-wide resource publishing and discovery mechanism, but their > seems little interest in the past to make this happen, > > Regards to all, > > .v > > On 29/01/2013 18:39, nudge wrote: > > On Tue, Jan 29, 2013, at 07:07 PM, Alf Watt wrote: > >> > >> I think Andrew's point is worth taking the time to seriously consider. > We > >> already have dynamic DNS update but as previously mentioned > configuration > >> of the DNS server and it's clients out has proven to be either too > >> difficult or not of interest to various OS vendors. > >> > >> It's worth mentioning that Apple has all the parts in place to pull this > >> off: > >> > >> - A Server OS with an embedded DNS server which they provide a UI to > >> manage > >> - Traditional and Mobile Clients with mDNSResolvers running on them > >> - A profile distribution system which make pushing configuration options > >> including keys easy > >> > >> Given the will to get the features implemented Apple could solve part of > >> the problem this without any changes to mdns. > >> > >> There are still things that fall outside of that scope which we should > >> consider, but ignoring the opportunity to uses the existing protocols > >> seems like a lot of effort to reproduce work that already exists. > >> > >> Best, > >> Alf > >> > > > > As someone who successfully tested and implemented WAB with TSIG > > protected updates[1] in an Apple environment about a year or so ago, I > > would tend to agree. It wasn't as difficult as I imagined partly because > > of a lack of documentation. Of course, things have changed since and I > > need to test again soon. But back then you had to front-end named with > > dnsextd if you needed llq (obviously you do). If that's still true it > > blocks other useful stuff such as rpz and rrl and needs fixing IMO. > > > > [1]I also tested TSIG protected reads DNSprivate, where's that going ? > > > > _______________________________________________ > > 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 > --00235429c7bc42144b04d4827a86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Some people did various patches to suport WAB in POSIX, = like http://www.roguelazer.com/tips/2010/02/dynamic-dns-par= t-two/ or https://github.com/gkaindl/Community-mdnsResponder.=
They were published on the bonjour-dev mailing list.
=A0
For my own u= se, I'm=20 currently running my own patched version of POSIX mdnsresponder on two=20 Ubuntu boxes (one client with mdnsresponder and one DNS server with=20 dnsextd/bind).

Best,

Olivier

On Tu= e, Jan 29, 2013 at 8:33 PM, vortex <vortex@networkcommons.org&= gt; wrote:

The problem has been that the POSIX and non-apple WAB component for
read/write DNS-SD under the bonjour stack has been broken and ignored
for years.

Integrating mDNS & WAB has been close on impossible because of this
(reference all the frustrations on the bonjour-dev mailing list without
resolution, again, it's been years!).

Alternate stacks such as avahi (non-cross platform) have waited for
"vital" security implementations for DNSSEC before implementing w= rite
enabled DNS-SD (a big mistake IMHO!), and because DNSSEC is so hairy
this has not happened either (on their roadmap unimplemented/delayed for years).

WAB & m~DNS has had the potential to be an exciting cross platform
Internet-wide resource publishing and discovery mechanism, but their
seems little interest in the past to make this happen,

Regards to all,

.v

On 29/01/2013 18:39, nudge wrote:
> On Tue, Jan 29, 2013, at 07:07 PM, Alf Watt wrote:
>>
>> I think Andrew's point is worth taking the time to seriously c= onsider. We
>> already have dynamic DNS update but as previously mentioned config= uration
>> of the DNS server and it's clients out has proven to be either= too
>> difficult or not of interest to various OS vendors.
>>
>> It's worth mentioning that Apple has all the parts in place to= pull this
>> off:
>>
>> - A Server OS with an embedded DNS server which they provide a UI = to
>> manage
>> - Traditional and Mobile Clients with mDNSResolvers running on the= m
>> - A profile distribution system which make pushing configuration o= ptions
>> including keys easy
>>
>> Given the will to get the features implemented Apple could solve p= art of
>> the problem this without any changes to mdns.
>>
>> There are still things that fall outside of that scope which we sh= ould
>> consider, but ignoring the opportunity to uses the existing protoc= ols
>> seems like a lot of effort to reproduce work that already exists.<= br> >>
>> Best,
>> Alf
>>
>
> As someone who successfully tested and implemented WAB with TSIG
> protected updates[1] in an Apple environment about a year or so ago, I=
> would tend to agree. It wasn't as difficult as I imagined partly b= ecause
> of a lack of documentation. Of course, things have changed since and I=
> need to test again soon. But back then you had to front-end named with=
> dnsextd if you needed llq (obviously you do). If that's still true= it
> blocks other useful stuff such as rpz and rrl and needs fixing IMO. >
> [1]I also tested TSIG protected reads DNSprivate, where's that goi= ng ?
>
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org=
> https://www.ietf.org/mailman/listinfo/mdnsext
>

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



--00235429c7bc42144b04d4827a86-- 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 CCA2E21F8AB2 for ; Tue, 29 Jan 2013 23:11:40 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Subject" X-Spam-Flag: NO X-Spam-Score: 0.797 X-Spam-Level: X-Spam-Status: No, score=0.797 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HEADER_COUNT_SUBJECT=3.096] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaQqvc+heVal for ; Tue, 29 Jan 2013 23:11:39 -0800 (PST) Received: from abulafia.free2air.net (abulafia.free2air.net [87.106.251.70]) by ietfa.amsl.com (Postfix) with ESMTP id 80AE821F8AAD for ; Tue, 29 Jan 2013 23:11:39 -0800 (PST) Received: from host86-178-159-153.range86-178.btcentralplus.com ([86.178.159.153] helo=[192.168.1.64]) by abulafia.free2air.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1U0RpW-0001lX-HG for mdnsext@ietf.org; Wed, 30 Jan 2013 07:11:37 +0000 Message-ID: <5108C79C.7070301@networkcommons.org> Date: Wed, 30 Jan 2013 07:11:24 +0000 From: vortex Organization: free2air User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mdnsext@ietf.org References: <1359484752.31527.140661184088257.2DD91FC3@webmail.messagingengine.com> <51082424.9090404@networkcommons.org> <20130129200449.GP15365@mx1.yitter.info> In-Reply-To: <20130129200449.GP15365@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: vortex@networkcommons.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 07:11:40 -0000 On 29/01/2013 20:04, Andrew Sullivan wrote: > On Tue, Jan 29, 2013 at 07:33:56PM +0000, vortex wrote: >> Alternate stacks such as avahi (non-cross platform) have waited for >> "vital" security implementations for DNSSEC before implementing write >> enabled DNS-SD (a big mistake IMHO!), and because DNSSEC is so hairy >> this has not happened either (on their roadmap unimplemented/delayed for >> years). > > This is probably a clue-stick that should be applied off-list, but > what does DNSSEC have to do with writing records into the DNS? > (Unless by "DNSSEC" you mean SIG(0) or TSIG or something like that.) AFAIK, close to nothing. But in avahi's case the two issues were bound together by one or more developers considering them intimately bound, resulting in Wide Area updates never being implemented, see http://avahi.org/roadmap and http://avahi.org/wiki/GoogleSummerOfCode Best, .v 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 2077521F88EA for ; Tue, 29 Jan 2013 12:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri-lXubZkPVf for ; Tue, 29 Jan 2013 12:04:49 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C821F88B5 for ; Tue, 29 Jan 2013 12:04:49 -0800 (PST) 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 B98E48A031 for ; Tue, 29 Jan 2013 20:04:47 +0000 (UTC) Date: Tue, 29 Jan 2013 15:04:49 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130129200449.GP15365@mx1.yitter.info> References: <1359484752.31527.140661184088257.2DD91FC3@webmail.messagingengine.com> <51082424.9090404@networkcommons.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51082424.9090404@networkcommons.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 20:04:50 -0000 On Tue, Jan 29, 2013 at 07:33:56PM +0000, vortex wrote: > Alternate stacks such as avahi (non-cross platform) have waited for > "vital" security implementations for DNSSEC before implementing write > enabled DNS-SD (a big mistake IMHO!), and because DNSSEC is so hairy > this has not happened either (on their roadmap unimplemented/delayed for > years). This is probably a clue-stick that should be applied off-list, but what does DNSSEC have to do with writing records into the DNS? (Unless by "DNSSEC" you mean SIG(0) or TSIG or something like that.) 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 41A8521F87B3 for ; Tue, 29 Jan 2013 11:34:10 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Subject" X-Spam-Flag: NO X-Spam-Score: 1.097 X-Spam-Level: * X-Spam-Status: No, score=1.097 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HEADER_COUNT_SUBJECT=3.096, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnXHAdPKcxNz for ; Tue, 29 Jan 2013 11:34:09 -0800 (PST) Received: from abulafia.free2air.net (abulafia.free2air.net [87.106.251.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2C93F21F86B7 for ; Tue, 29 Jan 2013 11:34:09 -0800 (PST) Received: from host86-178-159-153.range86-178.btcentralplus.com ([86.178.159.153] helo=[192.168.1.64]) by abulafia.free2air.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1U0GwX-0000s5-Fj for mdnsext@ietf.org; Tue, 29 Jan 2013 19:34:07 +0000 Message-ID: <51082424.9090404@networkcommons.org> Date: Tue, 29 Jan 2013 19:33:56 +0000 From: vortex Organization: free2air User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: mdnsext@ietf.org References: <1359484752.31527.140661184088257.2DD91FC3@webmail.messagingengine.com> In-Reply-To: <1359484752.31527.140661184088257.2DD91FC3@webmail.messagingengine.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: vortex@networkcommons.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:34:10 -0000 The problem has been that the POSIX and non-apple WAB component for read/write DNS-SD under the bonjour stack has been broken and ignored for years. Integrating mDNS & WAB has been close on impossible because of this (reference all the frustrations on the bonjour-dev mailing list without resolution, again, it's been years!). Alternate stacks such as avahi (non-cross platform) have waited for "vital" security implementations for DNSSEC before implementing write enabled DNS-SD (a big mistake IMHO!), and because DNSSEC is so hairy this has not happened either (on their roadmap unimplemented/delayed for years). WAB & m~DNS has had the potential to be an exciting cross platform Internet-wide resource publishing and discovery mechanism, but their seems little interest in the past to make this happen, Regards to all, .v On 29/01/2013 18:39, nudge wrote: > On Tue, Jan 29, 2013, at 07:07 PM, Alf Watt wrote: >> >> I think Andrew's point is worth taking the time to seriously consider. We >> already have dynamic DNS update but as previously mentioned configuration >> of the DNS server and it's clients out has proven to be either too >> difficult or not of interest to various OS vendors. >> >> It's worth mentioning that Apple has all the parts in place to pull this >> off: >> >> - A Server OS with an embedded DNS server which they provide a UI to >> manage >> - Traditional and Mobile Clients with mDNSResolvers running on them >> - A profile distribution system which make pushing configuration options >> including keys easy >> >> Given the will to get the features implemented Apple could solve part of >> the problem this without any changes to mdns. >> >> There are still things that fall outside of that scope which we should >> consider, but ignoring the opportunity to uses the existing protocols >> seems like a lot of effort to reproduce work that already exists. >> >> Best, >> Alf >> > > As someone who successfully tested and implemented WAB with TSIG > protected updates[1] in an Apple environment about a year or so ago, I > would tend to agree. It wasn't as difficult as I imagined partly because > of a lack of documentation. Of course, things have changed since and I > need to test again soon. But back then you had to front-end named with > dnsextd if you needed llq (obviously you do). If that's still true it > blocks other useful stuff such as rpz and rrl and needs fixing IMO. > > [1]I also tested TSIG protected reads DNSprivate, where's that going ? > > _______________________________________________ > 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 E544621F890D for ; Tue, 29 Jan 2013 11:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.903 X-Spam-Level: X-Spam-Status: No, score=-4.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eemt+cjsrff for ; Tue, 29 Jan 2013 11:00:15 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 04B7321F88E3 for ; Tue, 29 Jan 2013 11:00:15 -0800 (PST) Received: from mail-oa0-f72.google.com (mail-oa0-f72.google.com [209.85.219.72]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 29 Jan 2013 12:59:56 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f72.google.com [209.85.219.72] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f72.google.com with SMTP id h2so4636164oag.3 for ; Tue, 29 Jan 2013 10:59:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to:x-gm-message-state; bh=eMu2wXPACoefopqUWO1PQ93jVsQF4ETsdIP4cjjtFvg=; b=Q/ZHjk9eU4ocDIKXvQsD9T1O0Z+d1boQdkgNvRVKoQtwHuWZI/7eQcmyhYNX/yc3bq TM/swd/PCFfgDiyHAPouWQT6eLqj0qB/dOjvDzloUjW5d8cXaFW9qjbqagMX5bCcHgl/ OZf9Bcw8LjX/8oOLhxJTEbg4Pb+JJynFIY+8466mVPKDkEJMg+eEiosrsa2Thm61Fa2L 0UbXm4SlC3bjPusHg04k1sI8S72qB00T2yXSYcxgEssy40TwOokrW61FVuJINFzW3eP9 rwlfRUcKSjFRv1JK7JcqrFIMYlmwSQTWTZ0maGNm6dtSD4/a16dvY9z2nciVg4YwhdLL ltUA== X-Received: by 10.50.222.232 with SMTP id qp8mr1784968igc.25.1359485995860; Tue, 29 Jan 2013 10:59:55 -0800 (PST) X-Received: by 10.50.222.232 with SMTP id qp8mr1784961igc.25.1359485995757; Tue, 29 Jan 2013 10:59:55 -0800 (PST) Received: from [10.92.160.79] (mobile-198-228-232-086.mycingular.net. [198.228.232.86]) by mx.google.com with ESMTPS id fv6sm2316488igc.17.2013.01.29.10.59.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 10:59:54 -0800 (PST) References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> <510720CA.7060906@umn.edu> <42a7482a134ff72473fef261cd53c48d.squirrel@www.trepanning.net> <06A07C6179EDEE48895CE9661FD0E41D0F797D32@xmb-rcd-x11.cisco.com> In-Reply-To: <06A07C6179EDEE48895CE9661FD0E41D0F797D32@xmb-rcd-x11.cisco.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <80881744-8168-4E81-918F-A2BD18698A11@umn.edu> X-Mailer: iPad Mail (10B141) From: David Farmer Date: Tue, 29 Jan 2013 12:59:51 -0600 To: "Stephen Orr (sorr)" X-Gm-Message-State: ALoCoQk7KPo2rKBQeS96m1CQyjWeXNC022jzpb4Y6uc8dL/tuJexLhl1OeYNeM36DnGI388/baOUNz0CUIA0SoAtmON84eMpp9qzqqgVgHTeVR4ddf0cFuyWxFQ0DrzaX4m68E/p30hs Cc: "mdnsext@ietf.org" , Dan Harkins Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 19:00:16 -0000 As a first step I'm ok with this, in fact I'm already doing it, but I view t= his as mostly a work around or hack. 1. What happens if you get a proxy loop? This seems really bad! Right now I= have nothing to prevent this. 2. Maybe loop detection can be defined as part o a proxies behavior. 3. Creates the same problem AppleTalk had, routers involved in the name bind= ing protocol. This is especially a problem for most enterprise network gear w= ith powerful fast-path ASIC switching and relatively low powered slow-path p= rocessors. 4. Doesn't really solve any multicast traffic issues or scaling of the name s= pace. Yes, it's not the network's problem to display 100s of services, but i= t will be a problem with most of the GUI's I've seen. 5. What about IPv6, mDNS is using link-local IPv6, how do you route between m= ultiple IPv6 link-local, by definition you can't. So multi network mDNS is r= eally IPv4 only right now. So a proxy that safely interconnects multiple link-local nets is only one sm= all part of the solution space we need. That is only a start, but an import= ant start. --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota =20 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Jan 29, 2013, at 12:11, "Stephen Orr (sorr)" wrote: > I agree with Dan on this - making sure that the network infrastructure has= the ability to operate as good "mdns clients" while providing filtering/pro= xying of DNS-SD advertisements between L3 segments would be a fundamental us= e case. >=20 > How the information gets displayed, searching etc would be left up to the c= lient GUI. >=20 > Stephen >=20 > -----Original Message----- > From: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] On Behalf= Of Dan Harkins > Sent: Tuesday, January 29, 2013 12:24 PM > To: David Farmer > Cc: mdnsext@ietf.org; Andrew Sullivan > Subject: Re: [mdnsext] mDNSext features/requirements rollup >=20 >=20 > Hello, >=20 > On Mon, January 28, 2013 5:07 pm, David Farmer wrote: >>=20 >> So you hear a bunch of us pushing to solve this with network hacks, or=20= >> mDNS hacks. Not because we think it is really the right way, but=20 >> because the network is what we can effect, its the levers we can=20 >> control. The applications and wiz-bang-thing devices are out of our=20 >> control and, right or wrong, we have had exceptions placed on us to=20 >> make them work on our networks. >>=20 >> So, while it may not be the right thing, I need a way to make normal=20 >> mDNS and Link-Local DNS Services Discovery work on my network. Which=20 >> consists of multiple segments and the services the users want may or=20 >> may not exist on the same segment. Fundamentally, this is either a=20 >> symptom of the success of mDNS and Link-Local DNS Services Discovery=20 >> or a failure to think through the consequences of not including=20 >> broader scalability in the original solution, take your pick. >=20 > What you're asking for is for networking devices like routers and firewal= ls and the like to provide a form of proxying for these link-local DNS servi= ces discovery. This can be enhanced by using smarts in the network (e.g. is t= he authenticated wiz-bang-thing authorized to make such a query?) and by exp= licit config of the networking device. The nice thing about this is that non= e of the wiz-bang-things need to be touched, they do what they always did bu= t get a much more rich response. >=20 > This seems to me like a well-defined problem we could work on that could p= roduce a useful RFC. >=20 > regards, >=20 > Dan. >=20 >=20 >=20 > _______________________________________________ > 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 D7CF421F886D for ; Tue, 29 Jan 2013 10:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o08oEJlGKpHH for ; Tue, 29 Jan 2013 10:39:13 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F121F8858 for ; Tue, 29 Jan 2013 10:39:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 78A2820E99 for ; Tue, 29 Jan 2013 13:39:12 -0500 (EST) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute3.internal (MEProxy); Tue, 29 Jan 2013 13:39:12 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date:in-reply-to:references; s=mesmtp; bh= jua9DlXy/cZFfhBNeK93jRt4JE4=; b=JshqOwnmsnaDPDoj30Kh0+SxhD7VVCpe SpQTB/+oKZJuyrZJVQ+aPxw9Mi8TdBvzEguTJkAPwlpM++RxjxjePS/8o6RF83h4 X/btthghbt91dIonXSM4WqjroRb2DL4gl0HwXF/5B9kf603iRXIrKM4OoPR754ux LVuoVraLYsM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date:in-reply-to :references; s=smtpout; bh=jua9DlXy/cZFfhBNeK93jRt4JE4=; b=gnbAQ yRSnWDpfCqledMVd3RG3i5lv5wa18y1lOHWr/5w5g9dqzhsfqGinyQM0QR/vGyJM 46jtApFNv7X9vMngBc0380cMeQwhmkHVwcc4n9vHT1N2CpjaW7eWKYGEa7OdbxsF bZnQ5yqmNlFfGeMkeYUS+RF0FlQB93kOTZHeQ8= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 3EC5921AE4; Tue, 29 Jan 2013 13:39:12 -0500 (EST) Message-Id: <1359484752.31527.140661184088257.2DD91FC3@webmail.messagingengine.com> X-Sasl-Enc: ljLn4ZW6atp1sI23+LdgpOKIpqY9SYhcHFukRztix14q 1359484752 From: nudge To: "" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html Date: Tue, 29 Jan 2013 19:39:12 +0100 In-Reply-To: References: Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 18:39:14 -0000 On Tue, Jan 29, 2013, at 07:07 PM, Alf Watt wrote: > > I think Andrew's point is worth taking the time to seriously consider. We > already have dynamic DNS update but as previously mentioned configuration > of the DNS server and it's clients out has proven to be either too > difficult or not of interest to various OS vendors. > > It's worth mentioning that Apple has all the parts in place to pull this > off: > > - A Server OS with an embedded DNS server which they provide a UI to > manage > - Traditional and Mobile Clients with mDNSResolvers running on them > - A profile distribution system which make pushing configuration options > including keys easy > > Given the will to get the features implemented Apple could solve part of > the problem this without any changes to mdns. > > There are still things that fall outside of that scope which we should > consider, but ignoring the opportunity to uses the existing protocols > seems like a lot of effort to reproduce work that already exists. > > Best, > Alf > As someone who successfully tested and implemented WAB with TSIG protected updates[1] in an Apple environment about a year or so ago, I would tend to agree. It wasn't as difficult as I imagined partly because of a lack of documentation. Of course, things have changed since and I need to test again soon. But back then you had to front-end named with dnsextd if you needed llq (obviously you do). If that's still true it blocks other useful stuff such as rpz and rrl and needs fixing IMO. [1]I also tested TSIG protected reads DNSprivate, where's that going ? 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 AA3FE21F8AF2 for ; Tue, 29 Jan 2013 10:12:01 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ-ykN5n3qpK for ; Tue, 29 Jan 2013 10:12:01 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF2321F8AE6 for ; Tue, 29 Jan 2013 10:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2401; q=dns/txt; s=iport; t=1359483121; x=1360692721; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ioFVAjdebbZkhH6uU3W3o1nwefc7f1UjKznbhI4eRbo=; b=mjPy9/vMiqRJh6rQoRHTutwg1yly6yzk5wwjMvFIXRbBqEsozIiBfPOr GGXV8d075mv0RB4EGPHVoaA8RIh3uskM099+J6m4a80li00xV3KPeZrl+ Ljg506z+Ca7MOI28x8+oKvPICefDN66EBlQdltjwMq+p4xRVzgfOuDzgi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKcPCFGtJXG8/2dsb2JhbABEDr5RFnOCHgEBAQQBAQE3DScXBAIBCA4DBAEBAQoUCQcnCxQJCAIEARIIE4d2DLEVgTiOcwSQKGEDpliCOT6CJA X-IronPort-AV: E=Sophos;i="4.84,561,1355097600"; d="scan'208";a="169983243" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jan 2013 18:12:00 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0TIC094029340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Jan 2013 18:12:00 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.75]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Tue, 29 Jan 2013 12:12:00 -0600 From: "Stephen Orr (sorr)" To: Dan Harkins , David Farmer , "mdnsext@ietf.org" Thread-Topic: [mdnsext] mDNSext features/requirements rollup Thread-Index: AQHN/X2sW8FpPWx93kSrR8X+xIE2t5hf45UAgAEQ24D//6IHAA== Date: Tue, 29 Jan 2013 18:11:59 +0000 Message-ID: <06A07C6179EDEE48895CE9661FD0E41D0F797D32@xmb-rcd-x11.cisco.com> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> <510720CA.7060906@umn.edu> <42a7482a134ff72473fef261cd53c48d.squirrel@www.trepanning.net> In-Reply-To: <42a7482a134ff72473fef261cd53c48d.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.220] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 18:12:01 -0000 I agree with Dan on this - making sure that the network infrastructure has = the ability to operate as good "mdns clients" while providing filtering/pro= xying of DNS-SD advertisements between L3 segments would be a fundamental u= se case. How the information gets displayed, searching etc would be left up to the c= lient GUI. Stephen -----Original Message----- From: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] On Behalf = Of Dan Harkins Sent: Tuesday, January 29, 2013 12:24 PM To: David Farmer Cc: mdnsext@ietf.org; Andrew Sullivan Subject: Re: [mdnsext] mDNSext features/requirements rollup Hello, On Mon, January 28, 2013 5:07 pm, David Farmer wrote: > > So you hear a bunch of us pushing to solve this with network hacks, or=20 > mDNS hacks. Not because we think it is really the right way, but=20 > because the network is what we can effect, its the levers we can=20 > control. The applications and wiz-bang-thing devices are out of our=20 > control and, right or wrong, we have had exceptions placed on us to=20 > make them work on our networks. > > So, while it may not be the right thing, I need a way to make normal=20 > mDNS and Link-Local DNS Services Discovery work on my network. Which=20 > consists of multiple segments and the services the users want may or=20 > may not exist on the same segment. Fundamentally, this is either a=20 > symptom of the success of mDNS and Link-Local DNS Services Discovery=20 > or a failure to think through the consequences of not including=20 > broader scalability in the original solution, take your pick. What you're asking for is for networking devices like routers and firewal= ls and the like to provide a form of proxying for these link-local DNS serv= ices discovery. This can be enhanced by using smarts in the network (e.g. i= s the authenticated wiz-bang-thing authorized to make such a query?) and by= explicit config of the networking device. The nice thing about this is tha= t none of the wiz-bang-things need to be touched, they do what they always = did but get a much more rich response. This seems to me like a well-defined problem we could work on that could = produce a useful RFC. regards, Dan. _______________________________________________ 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 93FB921F8955 for ; Tue, 29 Jan 2013 10:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNpJ+pi2tmJa for ; Tue, 29 Jan 2013 10:08:09 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFBA21F861F for ; Tue, 29 Jan 2013 10:08:09 -0800 (PST) Received: from mail120-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Tue, 29 Jan 2013 18:08:04 +0000 Received: from mail120-ch1 (localhost [127.0.0.1]) by mail120-ch1-R.bigfish.com (Postfix) with ESMTP id 64EC33A02B0; Tue, 29 Jan 2013 18:08:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: PS-20(zz98dI9371Ic85fhzz1ee6h1de0h1202h1e76h1d1ah1d2ahz31iz1033IL8275dh18c673h8275bhz32i2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail120-ch1 (localhost.localdomain [127.0.0.1]) by mail120-ch1 (MessageSwitch) id 1359482882328122_18757; Tue, 29 Jan 2013 18:08:02 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail120-ch1.bigfish.com (Postfix) with ESMTP id 32DEE3E0091; Tue, 29 Jan 2013 18:08:02 +0000 (UTC) Received: from CH1PRD0811HT005.namprd08.prod.outlook.com (157.56.245.85) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 29 Jan 2013 18:07:58 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.195]) by CH1PRD0811HT005.namprd08.prod.outlook.com ([10.255.155.40]) with mapi id 14.16.0263.000; Tue, 29 Jan 2013 18:07:57 +0000 From: Alf Watt To: "" Thread-Topic: [mdnsext] mDNSext features/requirements rollup Thread-Index: AQHN/kuQ9TSkRV3c+k2jD34yUo/UWw== Date: Tue, 29 Jan 2013 18:07:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.155.4] Content-Type: multipart/alternative; boundary="_000_D99048ACAF96354EBFD6A811E3C65ACD10977A7CCH1PRD0811MB407_" MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com Cc: "ajs@anvilwalrusden.com" Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 18:08:10 -0000 --_000_D99048ACAF96354EBFD6A811E3C65ACD10977A7CCH1PRD0811MB407_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think Andrew's point is worth taking the time to seriously consider. We a= lready have dynamic DNS update but as previously mentioned configuration of= the DNS server and it's clients out has proven to be either too difficult = or not of interest to various OS vendors. It's worth mentioning that Apple has all the parts in place to pull this of= f: - A Server OS with an embedded DNS server which they provide a UI to manage - Traditional and Mobile Clients with mDNSResolvers running on them - A profile distribution system which make pushing configuration options in= cluding keys easy Given the will to get the features implemented Apple could solve part of th= e problem this without any changes to mdns. There are still things that fall outside of that scope which we should cons= ider, but ignoring the opportunity to uses the existing protocols seems lik= e a lot of effort to reproduce work that already exists. Best, Alf On Jan 28, 2013, at 12:03 PM, mdnsext-request@ietf.org wrote: From: Andrew Sullivan > Subject: Re: [mdnsext] mDNSext features/requirements rollup Date: January 28, 2013 9:34:00 AM PST To: > On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote: Some of us would like to see mDNS support multiple IP subnets (e.g. multiple buildings, multiple groups, multiple (V)LANs) within a single administrative domain (e.g. university campus, corporate campus). This implies having a straight-forward way to configure networking devices (e.g. firewalls, routers) at the edge of one's administrative domain to exclude certain interfaces (e.g. exterior uplink interfaces) from all mDNS traffic of the administrative domain using mDNS. I still do not understand why this sort of thing isn't better handled by vastly improved tools for real DNS management. It seems to me that people are asking for a single, unifed namespace outside the link-local context, and we invented a mechanism for that many years ago. The problem is that the support tools for that mechanism sort of suck. Instead of inventing a new protocol which, by definition, is going to run into conflicts with the existing protocols in this space, why wouldn't it be better to take that energy and expend it on the missing tools? A -- Andrew Sullivan ajs@anvilwalrusden.com --_000_D99048ACAF96354EBFD6A811E3C65ACD10977A7CCH1PRD0811MB407_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

I think Andrew's point is worth taking the time to seriously consider.= We already have dynamic DNS update but as previously mentioned configurati= on of the DNS server and it's clients out has proven to be either too diffi= cult or not of interest to various OS vendors.

It's worth mentioning that Apple has all the parts in place to pull th= is off:

- A Se= rver OS with an embedded DNS server which they provide a UI to manage
- Trad= itional and Mobile Clients with mDNSResolvers running on them
- A pr= ofile distribution system which make pushing configuration options includin= g keys easy

Given the will to get the features implemented Apple could solve part = of the problem this without any changes to mdns.

There are still things that fall outside of that scope which we should= consider, but ignoring the opportunity to uses the existing protocols seem= s like a lot of effort to reproduce work that already exists.

Best,
Alf

On Jan 28, 2013, at 12:03 PM, mdnsext-request@ietf.org wrote:

From: = Andrew S= ullivan <ajs@anvilwalrusden.co= m>
Subject: <= /b>Re= : [mdnsext] mDNSext features/requirements rollup
Date: = January = 28, 2013 9:34:00 AM PST


On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote:

Some of us would like to see mDNS support multiple IP subnets
(e.g. multiple buildings, multiple groups, multiple (V)LANs)
within a single administrative domain (e.g. university campus,
corporate campus).  

 This implies having a straight-forward way to configure 
 networking devices (e.g. firewalls, routers) at the edge 
 of one's administrative domain to exclude certain interfaces 
 (e.g. exterior uplink interfaces) from all mDNS traffic 
 of the administrative domain using mDNS.

I still do not understand why this sort of thing isn't better handled=
by vastly improved tools for real DNS management.  It seems to me that
people are asking for a single, unifed namespace outside the
link-local context, and we invented a mechanism for that many years
ago.  The problem is that the support tools for that mechanism sort of
suck.  Instead of inventing a new protocol which, by definition, is<= br style=3D"font-family: Helvetica; font-size: medium; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; line-hei= ght: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-t= ransform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-= text-size-adjust: auto; -webkit-text-stroke-width: 0px; "> going to run into conflicts with the existing protocols in this space, why wouldn't it be better to take that energy and expend it on the
missing tools?

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com

--_000_D99048ACAF96354EBFD6A811E3C65ACD10977A7CCH1PRD0811MB407_-- 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 AA44821F89DA for ; Tue, 29 Jan 2013 09:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkbFWBUJpJ3p for ; Tue, 29 Jan 2013 09:23:58 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3737221F8971 for ; Tue, 29 Jan 2013 09:23:58 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CFC1B1022404A; Tue, 29 Jan 2013 09:23:57 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 29 Jan 2013 09:23:57 -0800 (PST) Message-ID: <42a7482a134ff72473fef261cd53c48d.squirrel@www.trepanning.net> In-Reply-To: <510720CA.7060906@umn.edu> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> <510720CA.7060906@umn.edu> Date: Tue, 29 Jan 2013 09:23:57 -0800 (PST) From: "Dan Harkins" To: "David Farmer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: mdnsext@ietf.org, Andrew Sullivan Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 17:23:59 -0000 Hello, On Mon, January 28, 2013 5:07 pm, David Farmer wrote: > > So you hear a bunch of us pushing to solve this with network hacks, or > mDNS hacks. Not because we think it is really the right way, but > because the network is what we can effect, its the levers we can > control. The applications and wiz-bang-thing devices are out of our > control and, right or wrong, we have had exceptions placed on us to make > them work on our networks. > > So, while it may not be the right thing, I need a way to make normal > mDNS and Link-Local DNS Services Discovery work on my network. Which > consists of multiple segments and the services the users want may or may > not exist on the same segment. Fundamentally, this is either a symptom > of the success of mDNS and Link-Local DNS Services Discovery or a > failure to think through the consequences of not including broader > scalability in the original solution, take your pick. What you're asking for is for networking devices like routers and firewalls and the like to provide a form of proxying for these link-local DNS services discovery. This can be enhanced by using smarts in the network (e.g. is the authenticated wiz-bang-thing authorized to make such a query?) and by explicit config of the networking device. The nice thing about this is that none of the wiz-bang-things need to be touched, they do what they always did but get a much more rich response. This seems to me like a well-defined problem we could work on that could produce a useful RFC. regards, Dan. 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 1E4E821F8803 for ; Tue, 29 Jan 2013 03:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f1MZyXD+G7Z for ; Tue, 29 Jan 2013 03:10:35 -0800 (PST) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8D28621F87F3 for ; Tue, 29 Jan 2013 03:10:35 -0800 (PST) Received: by mail-qe0-f46.google.com with SMTP id 1so108877qec.33 for ; Tue, 29 Jan 2013 03:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=dps4seR0h+G5hNQkyfDbFs1OPMlhWW3o1Rc7P/y3FAg=; b=tI1GWBy5hZryW+ho04IqVf85643DzA7PtSHm7kk6XqVDzwbWP2k92mds/KzV0L6kWQ cXRVUR7F8DFKzl2xJ9a+KZaWbXAioMAisqmYUOo6COzHG9ujHlimWRh87HzNJ8MEV6H3 ejtW6ByCUMEpZELKasSefqKGqapm+3m8FTzgKEA9qVGIw2FBkwGXrVZY+0qXDQOH4CBg EkR9vWoHGdOBedfJS1aQfy3umAgJB6B3+oHCnuqt1LrulrVOkjhpipoShDcCkjB7q8i0 yUABjzFNejdUhFrt5vJDnptXrss7RpxaMXki7qV8TSvBIqcHQfoNa3FXOCSt7ancr6Kd OoqA== X-Received: by 10.49.72.136 with SMTP id d8mr612850qev.62.1359457835008; Tue, 29 Jan 2013 03:10:35 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id df6sm7591715qab.6.2013.01.29.03.10.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 03:10:34 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: RJ Atkinson In-Reply-To: <51071689.8030601@umn.edu> Date: Tue, 29 Jan 2013 06:10:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <51071689.8030601@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1283) Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 29 Jan 2013 11:10:36 -0000 On 28 Jan 2013, at 19:23 , David Farmer wrote: > I agree that we should not assume multicast or unicast > is more or less efficient, that should be left up to the > network operator. > > We need to provide a tool that work with either multicast or > unicast allowing a network operator to control that where > appropriate. Multicast as an assumption for an unmanaged > network, is fine, but allowing this to be managed or > controlled by the network operator in the case of a managed > network is what some of us are looking for. The above sounds about right to me. Thanks, Ran Atkinson 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 4546621F8BD4 for ; Tue, 29 Jan 2013 01:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJuUWtVgNqmB for ; Tue, 29 Jan 2013 01:25:33 -0800 (PST) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 895E121F8B13 for ; Tue, 29 Jan 2013 01:25:33 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube8.xs4all.net [194.109.20.206]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id r0T9PVAQ054389 for ; Tue, 29 Jan 2013 10:25:32 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-228-183.w92-145.abo.wanadoo.fr ([92.145.51.183]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Tue, 29 Jan 2013 10:25:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 29 Jan 2013 10:25:31 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: <72004462c199494ac7bc486bd95c66ab@xs4all.nl> X-Sender: stokcons@xs4all.nl (fur7QRI5dVqS3W9ojGdZm2UlhAL3mgvK) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 09:25:34 -0000 Hi Kerry and Stuart, I went through the req. document A typo in section 1 line 4: ... find that mDNS does NOT work across routers. << NOT added by me >> I do miss the following use case (also missing in hybrid-01 document), expected for control networks in building at intallation time. Devices are connected to a mesh network that is not connected to an edge router. These devices can do service disovery as suggested in hybrid-1 document, but no DNS server, no DHCP server and no edge router are accessible. A DNS proxy can be present. DNS proxy can be configured off-line or with specially designed tools on-line. After connection of this mesh network to an edge router and accompanying connection to DNS server, applications in devices are expected to use same domain names and be discoverable over edge router. I hope this case can be made explicit in section 3 point (E) of req document, by citing that mesh network can be (temporarily) stand-alone without edge router accessibility. In REQ2: add use case E to cases A and B In REQ3: add use case E to cases C and D. Peter van der Stok 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 0765F21E8055 for ; Mon, 28 Jan 2013 17:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKb4O64J0ANS for ; Mon, 28 Jan 2013 17:07:36 -0800 (PST) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB621E8054 for ; Mon, 28 Jan 2013 17:07:36 -0800 (PST) Received: from mail-oa0-f71.google.com (mail-oa0-f71.google.com [209.85.219.71]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 28 Jan 2013 19:07:25 -0600 (CST) X-Umn-Remote-Mta: [N] mail-oa0-f71.google.com [209.85.219.71] #+LO+TR X-Umn-Classification: local Received: by mail-oa0-f71.google.com with SMTP id n12so20381558oag.2 for ; Mon, 28 Jan 2013 17:07:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=5Ja6TCRbe15DgJisOzodUb7goTkt1XHiPkINxSohSjY=; b=aempdQDyaeR1MJmtx57lLf7TB4e95GLELshgO8O3UT//kzLz+qlxTDhW/nQDfAHyMZ drerI/3DDg/dhywtO4/8ct2/11OzWTV5gD074EXMVvdHZqgLjlX5P3D5ih5zQmIF0WHO UxXHBZ2+KqECVVn5ZWp0a1VBUkOI3iABCiwpNHCcFO5e3tPX+Ku8LIAivq4tp0E6PDe+ m29Bn5UyHsude4Wil55O+Th2kbBJs04EOOM9rTVV+s1dkgaE9NroShIM+ODLE6Es8U6x I9ycbKJ3ZTDS5dH9Bp0ApSk0I6g2ZLYkYWXtsiKfptMaDRQf7f+ovIGTo3Ei3HR52smd 7jTg== X-Received: by 10.50.179.100 with SMTP id df4mr6450579igc.60.1359421644658; Mon, 28 Jan 2013 17:07:24 -0800 (PST) X-Received: by 10.50.179.100 with SMTP id df4mr6450570igc.60.1359421644542; Mon, 28 Jan 2013 17:07:24 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu (x-134-84-88-75.nts.umn.edu. [134.84.88.75]) by mx.google.com with ESMTPS id c3sm542888igj.1.2013.01.28.17.07.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 17:07:23 -0800 (PST) Message-ID: <510720CA.7060906@umn.edu> Date: Mon, 28 Jan 2013 19:07:22 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrew Sullivan References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> In-Reply-To: <20130128173400.GP13806@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl0DlL8uMvuEMfHnwf7U1D6IKfiC2t+kO/sw/gZ1Zv4O34PWCEok8NBJGmmvkqNytJRyweEupo2xK4jkZrS/llhyA/wrufDj07h2HcNg6BqOX5djgVi/KqCLMm+RKuEWGbBtqx6 Cc: mdnsext@ietf.org, David Farmer Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer 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, 29 Jan 2013 01:07:37 -0000 On 1/28/13 11:34 , Andrew Sullivan wrote: > On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote: > >> Some of us would like to see mDNS support multiple IP subnets >> (e.g. multiple buildings, multiple groups, multiple (V)LANs) >> within a single administrative domain (e.g. university campus, >> corporate campus). >> >> This implies having a straight-forward way to configure >> networking devices (e.g. firewalls, routers) at the edge >> of one's administrative domain to exclude certain interfaces >> (e.g. exterior uplink interfaces) from all mDNS traffic >> of the administrative domain using mDNS. > > I still do not understand why this sort of thing isn't better handled > by vastly improved tools for real DNS management. It seems to me that > people are asking for a single, unifed namespace outside the > link-local context, and we invented a mechanism for that many years > ago. The problem is that the support tools for that mechanism sort of > suck. Instead of inventing a new protocol which, by definition, is > going to run into conflicts with the existing protocols in this space, > why wouldn't it be better to take that energy and expend it on the > missing tools? If you mean an implementation of Wide-Area DNS Services Discovery then yes, but most of the zero-conf implementations and the applications using this have ignored anything but mDNS and Link-Local DNS Services Discovery. The real issue is that end-users and even IT Executives (CIOs, etc...) don't see why there should be any difference between what they can do and use at home and in the office. If they can do wiz-bang-thing at home they want to do it in the office. Right now mDNS and Link-Local DNS Services Discovery are critical to how many of these consumer devices, or the Internet-of-things that some people call it, make the wiz-bang-things work. I apologize to Apple, but to really make this clear I have to call them out. The driver behind the petition is a specific case of what I generically described above. Users and IT Executives in Higher Ed wanted to be able to use AirPlay Screen Mirroring to Apple TVs from iOS and now Mountain Lion Laptops on the campus network. Not only was this an idea they came up with but, Apple even had an TV ad campaign promoting the idea. To be honest as a network engineer its very much an uphill battle when your arguing against a multi-million dollar TV ad campaign. :( So you hear a bunch of us pushing to solve this with network hacks, or mDNS hacks. Not because we think it is really the right way, but because the network is what we can effect, its the levers we can control. The applications and wiz-bang-thing devices are out of our control and, right or wrong, we have had exceptions placed on us to make them work on our networks. So, while it may not be the right thing, I need a way to make normal mDNS and Link-Local DNS Services Discovery work on my network. Which consists of multiple segments and the services the users want may or may not exist on the same segment. Fundamentally, this is either a symptom of the success of mDNS and Link-Local DNS Services Discovery or a failure to think through the consequences of not including broader scalability in the original solution, take your pick. So while we need the better DNS tool you refer to, we also need solutions that work with the applications and wiz-bang-thing devices that are out there now. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ 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 CA4A721E804E for ; Mon, 28 Jan 2013 16:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpJfWGeo23-3 for ; Mon, 28 Jan 2013 16:23:51 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3815121E804B for ; Mon, 28 Jan 2013 16:23:51 -0800 (PST) Received: from mail-ia0-f198.google.com (mail-ia0-f198.google.com [209.85.210.198]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 28 Jan 2013 18:23:40 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ia0-f198.google.com [209.85.210.198] #+LO+TR X-Umn-Classification: local Received: by mail-ia0-f198.google.com with SMTP id h23so10749259iae.9 for ; Mon, 28 Jan 2013 16:23:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding:x-gm-message-state; bh=eEJJCliQ5OdR1Z6CtWev0y+suKGwjknk/sCfzJfe14g=; b=h8oZI7cX4XZ8Kyqmwlw6qGpDqla7l2flI475E3dnAy/JRmpxm6Wrwweu2YXGHwhhbp Jd5l66CZ8KUC0Y2IyzuDpJS9r8XU5jkatAjTSopndvyMtZ7hxBy5XoQbPGWD2FPgvEwK z+KvIFKnGdrupKJ6fs2OjyECCkXecnKJ5xCaLSSnHWgMe34xnaO6mUqzkB/FhQ4IFt1x kNnaUp9ii+djoSXvIoIF+5yn1J5Fyk+fvHqiPJf4dBsJ0Uh9yV5cDAzgQGfIURsoPz18 FMwlJUhP58EpfuxhlEJuJBr3teMrwisEtsVoQpLPypwKps13+xB632KD6Nip36ofuG1v A92A== X-Received: by 10.50.220.166 with SMTP id px6mr6262456igc.8.1359419020272; Mon, 28 Jan 2013 16:23:40 -0800 (PST) X-Received: by 10.50.220.166 with SMTP id px6mr6262450igc.8.1359419020152; Mon, 28 Jan 2013 16:23:40 -0800 (PST) Received: from x-134-84-88-75.nts.umn.edu (x-134-84-88-75.nts.umn.edu. [134.84.88.75]) by mx.google.com with ESMTPS id df6sm390516igb.15.2013.01.28.16.23.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 16:23:39 -0800 (PST) Message-ID: <51071689.8030601@umn.edu> Date: Mon, 28 Jan 2013 18:23:37 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: RJ Atkinson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkpt5l0l5W0QnOP9/Dh0IRkqOf+JAP7RYp13wLzuYqju8u8sjiblAyFLpBiUckpx3sydCRSbGMYmwJWClimVAyiTtUc10QFahM7/nI8QqVJrsSXmafOeYE3ZYZWlTPjeVurZOol Cc: mdnsext@ietf.org, David Farmer Subject: Re: [mdnsext] mDNSext features/requirements rollup X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer 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, 29 Jan 2013 00:23:51 -0000 On 1/28/13 10:39 , RJ Atkinson wrote: > > Earlier, Alf Watt wrote: >> - multicast on wireless links is expensive, >> move as much traffic as possible to unicast > > This reportedly is true for IEEE 802.11 links > as of today. Reports also indicate that some > folks active in IEEE 802.11 are looking into this issue, > with a goal being to eliminate this issue in > future revisions of IEEE 802.11. > > However, the quote at top is (emphatically) NOT TRUE > for a wide range of other wireless links. For MANY > wireless link types, multicast is MUCH more > efficient and cheaper than unicast. I agree that we should not assume multicast or unicast is more or less efficient, that should be left up to the network operator. We need to provide a tool that work with either multicast or unicast allowing a network operator to control that where appropriate. Multicast as an assumption for an unmanaged network, is fine, but allowing this to be managed or controlled by the network operator in the case of a managed network is what some of us are looking for. This could be with a DHCP option or many other possible solutions. Besides 802.11, another example where multicast could be problematic; there are metro Ethernet providers that disable multicast or rate limit multicast packets, when an Enterprise network operator uses these services, this is just something you have to deal with. > While it is sensible to note this limitation of > IEEE 802.11 wireless link technology, it is > NOT sensible to impair the applicability of mDNS > to the wide range of other links (wired or wireless) > where multicast is cheap and efficient. Yes, when appropriate, available, and efficient multicast is great, its just not universally available, efficient, or always appropriate. As in most things one-size-fits-all is a myth, multicast is not universally good or bad, some of us just want/need other options. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ 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 553CC21E803A for ; Mon, 28 Jan 2013 14:48:07 -0800 (PST) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyZ6xIJlQU+T for ; Mon, 28 Jan 2013 14:48:06 -0800 (PST) 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 266F821E8039 for ; Mon, 28 Jan 2013 14:48:05 -0800 (PST) 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 r0SMm00r027720 for ; Mon, 28 Jan 2013 22:48:00 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r0SMm00r027720 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359413280; bh=u+7gV4flnYhBLWI7iTZiLjZG+20=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=Xz2ImIjm9FyFC9HX/8SNejC/vzPv6VFI45g/Bt6j7UmYxeNQbK5CCNYsAZL0Oh0c9 wooHyLsrBcjYlyzboB2B0YPxzKqdRMNqP0vGKvTKeX8gnwhKF7kYs1lawatgi3CQxI i0kayHE3IU8A/NqY+9o4w6CxHNJpPW6M2K6myljg= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p0RMm00430612812Dd ret-id none; Mon, 28 Jan 2013 22:48:00 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r0SMlsEO020075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jan 2013 22:47:55 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_30DEE7CF-1FCB-4655-A747-51672ADA2A08" Message-ID: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Mon, 28 Jan 2013 22:47:54 +0000 References: <65245680-41DC-4B28-98FE-9EA97C6EB06E@apple.com> <7073.1359131300@sandelman.ca> <02CA7B73-3A02-4CBA-9C55-3FC52445509F@ecs.soton.ac.uk> To: IETF mdnsext In-Reply-To: <7073.1359131300@sandelman.ca> X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p0RMm0043061281200; tid=p0RMm00430612812Dd; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r0SMm00r027720 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-01.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: Mon, 28 Jan 2013 22:48:07 -0000 --Apple-Mail=_30DEE7CF-1FCB-4655-A747-51672ADA2A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 25 Jan 2013, at 16:28, Michael Richardson = wrote: >>>>>> "Stuart" =3D=3D Stuart Cheshire writes: >=20 >> Service discovery beyond the local link is probably the most=09 >> important feature missing currently in the DNS-SD/mDNS framework. >> The following describes some of the issues. >=20 > I think it's important that we take these words in account, and maybe = we > should rename the effort sto something like: > DNS-based site-wide service discovery >=20 > (DBSWSD? DSSD?... maybe someone else will come up with a nice IETF WG > acronym). The proposal we just put in says "Wide area DNS-SD". We chose at this = stage to keep mdnsext as the acronym to match up with the mail list name = and with the previous BoF effort. Should there be enough progress to warrant a WG, then the name can be = revisited. That, at the moment, is by no means our main concern. What = we need is healthy list discussion on the issues, in particular pushing = forward the good work on the requirements draft, and seeing evidence of = commitment to do work. > I think that we will make better progress is we talk more about the > problem, with the understanding that it involves extending = mdns/DNS-SD, > but that it isn't just mDNS. Indeed. > I find the document is very clear, and I think that it is a good = problem > statement for creation of a group. I very much appreciate that > non-multicast things are being considered. We have 4 weeks to work on the requirements text. It would be very = desirable to see a version that would be adoptable as a WG item (were we = a WG) by then. That would certainly help the cause for forming a WG. The actual deadline is Mon 25th Feb: http://www.ietf.org/meeting/cutoff-dates-2013.html Tim --Apple-Mail=_30DEE7CF-1FCB-4655-A747-51672ADA2A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii mcr+ietf@sandelman.ca> = wrote:
"Stuart"= =3D=3D Stuart Cheshire <cheshire@apple.com> = writes:
Service discovery beyond the local link is = probably the most=
    important feature missing = currently in the DNS-SD/mDNS framework.
    The = following describes some of the issues.

I think it's = important that we take these words in account, and maybe we
should = rename the effort sto something like:
=       DNS-based site-wide service = discovery

(DBSWSD? DSSD?... maybe someone else will come up with = a nice IETF WG
acronym).

The proposal = we just put in says "Wide area DNS-SD". We chose at this stage to keep = mdnsext as the acronym to match up with the mail list name and with the = previous BoF effort.

Should there be enough = progress to warrant a WG, then the name can be revisited.  That, at = the moment, is by no means our main concern.  What we need is = healthy list discussion on the issues, in particular pushing forward the = good work on the requirements draft, and seeing evidence of commitment = to do work.

I think that we will = make better progress is we talk more about the
problem, with the = understanding that it involves extending mdns/DNS-SD,
but that it = isn't just = mDNS.

Indeed.

I find the document is very clear, and I think that it is = a good problem
statement for creation of a group.    I = very much appreciate that
non-multicast things are being = considered.

We have 4 weeks to work on = the requirements text.  It would be very desirable to see a version = that would be adoptable as a WG item (were we a WG) by then. That would = certainly help the cause for forming a WG.

The = actual deadline is Mon 25th Feb:

Tim

= --Apple-Mail=_30DEE7CF-1FCB-4655-A747-51672ADA2A08-- 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 9AE0121F86D2 for ; Mon, 28 Jan 2013 14:32:41 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4kVdeZ6gYjw for ; Mon, 28 Jan 2013 14:32:41 -0800 (PST) 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 AC66021F86CE for ; Mon, 28 Jan 2013 14:32:40 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r0SMWY6j024309 for ; Mon, 28 Jan 2013 22:32:34 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r0SMWY6j024309 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1359412354; bh=5++AWQaKfKH7ufdEnVSIYq7F3Yk=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=iu/dE7ecCkHH0/mgIbzS4MQJJ08gWlpC3KVva9/K9jEe0C1UneLIkkxVd76S5rIU7 oSE/P3lh/oLuASgidjKB1OBYQOC42qI0VJ5u4Uz11ehKg3aw1X0SHh/kf4facQOjlE L/yjc2gpBtvcH+wfvY4xixFo6UxLRe6BMXgLLu9U= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p0RMWY0430612708YF ret-id none; Mon, 28 Jan 2013 22:32:34 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r0SMWTHA017107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jan 2013 22:32:30 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: <20130128203603.GW13806@mx1.yitter.info> Date: Mon, 28 Jan 2013 22:32:29 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> <20130128203603.GW13806@mx1.yitter.info> <84159934-1DC4-47CE-806C-D156C978CFD1@ecs.soton.ac.uk> To: "mdnsext@ietf.org" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p0RMWY043061270800; tid=p0RMWY0430612708YF; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r0SMWY6j024309 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 22:32:41 -0000 On 28 Jan 2013, at 20:36, Andrew Sullivan = wrote: > Or put this another way. We today have two DNS-like name spaces: the > mDNS one, which is link local, and the global DNS one. At the moment, > your problem of debugging collisions between these two is restricted > to link local scope. This makes the problem not completely > intractable. =20 We are putting a BoF request to the AD(s) for Orlando. The request is = phrasing the BoF as "Wide area DNS-SD", though for practical reasons = we'll likely keep the same mdnsext acronym if the request is approved. The goals have been revised from the previous BoF, with the proposed = zeroconf and unicast DNS goal revised to be a BCP on their coexistence, = which could describe some of the issues discussed here and elsewhere = recently. Whether the Bof goes ahead will depend on the AD(s) view(s) as well as = evidence of commitment and work here. Further good progress on the = requirements draft would be welcomed. 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 1DD5B21F8581 for ; Mon, 28 Jan 2013 14:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tpt3V6LYdMRV for ; Mon, 28 Jan 2013 14:20:56 -0800 (PST) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id AFA2721F86CA for ; Mon, 28 Jan 2013 14:20:55 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id i10so1067352oag.0 for ; Mon, 28 Jan 2013 14:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=vTc+ILNThrmGVIzygOmlNuwTC0m/09+aBo8BelHu9f4=; b=RDrJZ4N0rZguGfr7oWr+7V/zRYVShvvC98zuhyzZwp11qX14+LaFDRiD74SVcJj6iH GYHvY9qGD6VnOrTaUOsR//e6toHL8MGs4ApCLQNZwC7pOB/iXizu+Mi3Dk65Tkw9YOHU QK6Nj/GTM0whyrEo7pvdq3xdNwzIMAct2aUdXnowlArBNg6/eERnJyceE8r22UbvJRpj Sbhg+R0xdZgAhwgUGmMmY7HGZtcrhnEa3a0hIk5Zco5iQwbhGjzJTtVAgKpxNGTLkA7a T8LrW9RXLCXFGw1DfyM077kl4Ygc1dJeo+kndZMpGNEwTTt7rb48bMXq0568Oge1AB7c +Uxg== MIME-Version: 1.0 X-Received: by 10.60.171.16 with SMTP id aq16mr12375117oec.37.1359411655217; Mon, 28 Jan 2013 14:20:55 -0800 (PST) Received: by 10.60.3.129 with HTTP; Mon, 28 Jan 2013 14:20:55 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 17:20:55 -0500 Message-ID: From: Kerry Lynn To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=bcaec54d3ef0d0112004d460b0df X-Mailman-Approved-At: Mon, 28 Jan 2013 14:33:36 -0800 Subject: [mdnsext] Fwd: Extensions to DNS-Based Service Discovery (mdnsext) BoF request 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, 28 Jan 2013 22:20:59 -0000 --bcaec54d3ef0d0112004d460b0df Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: Kerry Lynn Date: Mon, Jan 28, 2013 at 5:14 PM Subject: Extensions to DNS-Based Service Discovery (mdnsext) BoF request To: Ralph Droms , Brian Haberman Greetings, Please find enclosed a BoF request for IETF86 in Orlando. This is a follow-up BoF to the "Extensions to the Bonjour protocol suite" (mdnsext) BoF held at IETF85, and thus we appreciate is the second and final chance to form a WG in this space. (Thanks to Tim Chown for preparing this.) We need to see discussion on the list regarding the proposed charter below. Also, with input from Marc Blanchet, Matthew Gast, and others we have begun to reorganize the requirements draft around use cases. See: draft https://datatracker.ietf.org/doc/draft-lynn-mdnsext-requirements/ I will be prompting a discussion of mdnsext security considerations on the list so we can include more ideas in future versions of the requirements draft. Note that there was some discussion of changing the BoF name after the first one. We compromised by keeping the same short name (mdnsext) but changing the long name to avoid the impression that our scope is too narrowly focused. It's something we can discuss on the list and revisit before the WG is (hopefully) established. Regards, -K- ---------- BoF scheduling information: a. Extensions to DNS-Based Service Discovery (mdnsext) b. Internet Area c. Conflicts: 6man homenet dhc apparea appsawg intarea sdnrg v6ops dnsop and dnsext d. Expected Attendance: 200 (at least 164 attended at IETF85) e. Special requests: None f. Number of sessions: 1 g. Length of session: 2 hours Draft agenda: -------------------- 1. Administravia (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 3. Requirements (Kerry Lynn, 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. Draft charter: ------------------- Currently, zeroconf networking protocols are generally used to discover services within the scope of a single link. In particular, the Bonjour protocols suite, comprising mDNS (draft-cheshire-dnsext-multicastdns / RFC 6762 in AUTH48) and DNS-SD (draft-cheshire-dnsext-dns-sd / RFC 6763 in AUTH48), are widely used for discovery and resolution of services and names on a single link. Such discovery is commonly used in many scenarios, including home networks, commercial and campus enterprise networks, and can be used in certain mesh networks. However, the multicast zeroconf protocols are constrained to link-local scope, so can only be used to discover services on the same link. In a typical current home network, which is a single link, users should experience the desired discovery behaviour. However, in future multi-link home networks (as envisaged by the homenet WG) and in routed campus or enterprise networks, devices and thus users can only discover services on the same link, which is a significant limitation. Such limitations have led to calls, such as those by the Educause petition, to develop an appropriate solution to span multiple links, or to perform discovery across a wide area (not necessarily on directly connected links). In addition, the Zigbee Smart Energy Profile 2.0 commercial standard currently under development has specified mDNS as its method of zero configuration discovery. However, its use of multi-link wireless mesh subnets (LLNs) and disparate physical layers will require extensions to mDNS to allow it to operate across multiple links. In principle DNS-SD can be used with conventional unicast DNS for wide area service discovery spanning multiple links, but in practice this capability is not widely used (potentially due to user interface/configuration issues, but potentially due to protocol limitations). As a result, as demand for service discovery across wider area routed networks grows, some vendors are beginning to ship their own early solutions. It is thus both timely and important that efforts to develop improved, scalable service discovery solutions for routed networks are coordinated towards producing a single, standards- based solution. Goals To that end, the primary goals of the mdnsext WG are as follows: 1. To document a set of requirements for wider area service discovery in routed, multi-link networks in the following four scenarios: a) Commercial enterprise networks b) Academic/educational/university campus networks c) Multi-link home networks, such as those envisaged by the HOMENET WG d) Multi-link/single subnet (mesh) networks, such as ROLL/6LOWPAN subnets 2. To develop an improved, scalable solution for wide-area service discovery that can operate in multi-link networks, applicable to the scenarios above. 3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast (global DNS) name services in such multi-link networks, which should include consideration of both the name resolution mechanism and the namespace. It is important that the mdnsext WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the mdsnext WG, and thus coordination between the WGs is desirable. Deliverables The WG will produce three documents: an Informational RFC on the requirements for wide-area service discovery protocols; a Standards Track RFC documenting a wide-area service discovery solution that is applicable to those scenarios; and a BCP document describing the most effective method to integrate mDNS and global DNS name services. Milestones May 2013 Formation of the WG Apr 2013 Adopt requirements draft as WG document Aug 2013 Submit requirements draft to the IESG as an Informational RFC Sep 2013 Adopt wide-area service discovery solution draft as WG document Oct 2013 Adopt zeroconf and unicast DNS integration BCP draft as WG document Mar 2014 Submit wide-area service discovery solution draft to the IESG as Standards Track RFC Mar 2014 Submit zeroconf and unicast DNS integration solution draft to the IESG as BCP --bcaec54d3ef0d0112004d460b0df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
F= rom: Kerry Lynn <kerlyn2001@gmail.com>Date: Mon, Jan 28, 2013 at 5:14 PM
Subject: Extensions to DNS-Based Service Discovery (mdnsext) BoF requestTo: Ralph Droms <rdroms@cisco.com>, Brian Haberman <bria= n@innovationslab.net>


Greetings,

Please f= ind enclosed a BoF=20 request for IETF86 in Orlando. This is a follow-up BoF
to the=20 "Extensions to the Bonjour protocol suite" (mdnsext) BoF held at = IETF85, and
thus we appreciate is the second and final chance to form a WG in= =20 this space.
(Thanks to Tim Chown for preparing this.)

We need to see discussi= on on the list regarding the proposed charter below.=A0 Also,
with input= from Marc Blanchet, Matthew Gast, and others we have begun to
reorganize the requirements draft around use cases.=A0 See:
draft https://datatracker.ietf.org/doc/draft-lynn-mdnsext-requirem= ents/
I will be prompting a discussion of mdnsext security considerations on the = list so
we can include more ideas in future versions of the requirements draft.
=
Note that there was some discussion of changing the BoF name after the = first one.
We compromised by keeping the same short name (mdnsext) but c= hanging the
long name to avoid the impression that our scope is too narrowly focused.= =A0 It's
something we can discuss on the list and revisit before the= WG is (hopefully)
established.

Regards, -K-


---------= -
BoF scheduling information:<= /div>

a. Extensions to DNS-Based Service Discovery (mdnsext)

b. Internet Area

c. Conflicts: 6man homenet dhc app= area appsawg intarea sdnrg v6ops dnsop and dnsext

d. Expected Attendance: 200 (at least 164 attended at IETF85)

e. Special requests: None

f. Number of sessions: 1

g. Length of= session: 2 hours=A0


Draft agenda:
--------------------

1. Administravia (Chairs= , 5 mins)=A0 =A0
=A0 =A0 Note= Well and agenda bashing

2. Goals of the BoF (Cha= irs, 15 mins)
=A0 =A0 Review = of IETF 85 mdsnext BoF and progress since

3. Requirements (Kerry L= ynn, 30 mins)
=A0 =A0 draft-l= ynn-mdnsext-requirements-01

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

=A0=A0

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


Draft charter:
--------------= -----

Currently, zeroconf networking protocols are generally used to discover services=20 within
the scope of a single link.=A0In particular, the Bonjour protocol= s=20 suite, comprising mDNS
(draft-cheshire-dnsext-multicast= dns=A0/=A0RFC 6762=A0in AUTH48) and DNS-SD
(draft-cheshire-dnsext-dns-sd=A0/=A0RFC 6763=A0in AUTH48), are wid= ely used for discovery and
resolution of services and names on a single link.=A0

Such discovery is commonly used in many scenarios, including home networks,
= commercial and campus enterprise networks, and can be used in certain=20 mesh networks.
However, the multicast zeroconf protocols are constrained to link-local scope, so can
only be used to discover services on the=20 same link. In a typical current home network,
which is a single link,=20 users should experience the desired discovery behaviour. However,
in=20 future multi-link home networks (as envisaged by the homenet WG) and in=20 routed
campus or enterprise networks, devices and thus users can only=20 discover services on the
same link, which is a significant limitation.= =20 Such limitations have led to calls, such as those
by the Educause=20 petition, to develop an appropriate solution to span multiple links, or=20 to
perform discovery across a wide area (not necessarily on directly=20 connected links).

In addition, the Zigbee Smart Energy Profile 2.0=A0commercial standard=20 currently under
development has specified mDNS as its method of zero=20 configuration discovery. However,
its use of multi-link wireless mesh=20 subnets (LLNs) and disparate physical layers will require
extensions to= =20 mDNS to allow it to operate across multiple links.

In principle DNS-SD can be used with conventional unicast DNS for wide=20 area service
discovery spanning multiple links,=A0but in practice this= =20 capability is not widely used
(potentially due to user=20 interface/configuration issues, but potentially due to protocol
limitati= ons). As a result, as demand for service discovery across wider=20 area routed
networks grows, some vendors are beginning to ship their own early solutions. It is thus
both timely and important that efforts to= =20 develop improved, scalable service discovery
solutions for routed=20 networks are coordinated towards producing a single, standards-
based=20 solution.
Goals

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

1. To document a set of requirements for wider area service discovery in=20 routed,
=A0=A0=A0 multi-link networks in the following four scenarios:
=A0 =A0 a) Commercial enterpri= se networks
=A0 =A0 b) Academ= ic/educational/university campus networks
=A0 =A0 c) Multi-link home network= s, such as those envisaged by the HOMENET WG
=A0 =A0 d) Multi-link/single subnet (mesh) networks, such a= s ROLL/6LOWPAN subnets

2. To develop an improved, scalable solution for wide-area service=20 discovery that can
=A0=A0=A0=A0 operate in multi-link networks, applicab= le to the=20 scenarios above.=A0

3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast=20 (global DNS)
=A0=A0=A0=A0 name services in such multi-link networks, whi= ch should=20 include consideration of both
=A0=A0=A0=A0 the name resolution mechanism= and the=20 namespace.
It is important that the mdnsext WG takes input from stakeholders in the=20 scenarios it is
considering. For example, the=A0homenet WG is currently= =20 evaluating its own requirements
for naming and service discovery; it is= =20 up to the homenet WG as to whether it wishes to
recommend adoption of=20 the solution developed in the mdsnext WG, and thus coordination
between= =20 the WGs is desirable.=A0

Deliverables=

The WG will produce three documents: an Informational RFC on the=20 requirements for
wide-area service discovery protocols; a Standards=20 Track RFC documenting a wide-area
service discovery solution that is=20 applicable to those scenarios; and a BCP document
describing the most=20 effective method to integrate mDNS and global DNS name services.

Milestones

May 2013 Formation of th= e WG
Apr 2013 Adopt requireme= nts draft as WG document
Aug = 2013 Submit requirements draft to the IESG as an Informational RFC
Sep 2013 Adopt wide-area service d= iscovery solution draft as WG document
Oct 2013 Adopt zeroconf and unicast DNS integration BCP draft as = WG document
Mar 2014 Submit wide-area service = discovery solution draft to the IESG as Standards Track RFC
Mar 2014 Submit zeroconf and unicast DNS int= egration solution draft to the IESG as BCP

--bcaec54d3ef0d0112004d460b0df-- 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 EAFFD21F86CC for ; Mon, 28 Jan 2013 12:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Bj-kouDGdC8 for ; Mon, 28 Jan 2013 12:36:11 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 396BE21F86C8 for ; Mon, 28 Jan 2013 12:36:11 -0800 (PST) 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 A57428A031 for ; Mon, 28 Jan 2013 20:36:05 +0000 (UTC) Date: Mon, 28 Jan 2013 15:36:04 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130128203603.GW13806@mx1.yitter.info> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> 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] mDNSext features/requirements rollup 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, 28 Jan 2013 20:36:15 -0000 On Mon, Jan 28, 2013 at 02:52:51PM -0500, Brian Dickson wrote: > The risks I see (in exclusively working on tools) are: > - scope creep > - scaling problems (in terms of development resources) > - work done by those who do not fully understand DNS protocols > - work done by those who do not fully understand DNS namespaces > - work supported by vendors who have history of horrible implementations > - tools in one space breaking things in another space (creating a Hobsons' > choice for users) > - users > - firmware > - longevity of deployed hardware/firmware/software I have removed from your list all the issues that are _not_ also true of extending mDNS, and will add to that the risks of extremely surprising behaviour to users when mDNS doesn't work consistently from one site to another. That risk leads us to the problem that, in future when people have name resolution problems in large networks, we'll get to chase _two_ protocols in every case. Or put this another way. We today have two DNS-like name spaces: the mDNS one, which is link local, and the global DNS one. At the moment, your problem of debugging collisions between these two is restricted to link local scope. This makes the problem not completely intractable. As the history of NAT (and DNS split horizon) appears to suggest, there may be no practical way to be absolutely sure these extended mDNS queries won't leak past the organizational boundary. If that's true, then what extending mDNS really represents is "create two completely different but apparently related global name spaces and oh, by the way, one of them doesn't work all the time." > > people are asking for a single, unifed namespace outside the > > link-local context, and we invented a mechanism for that many years > > ago. > Just to be clear, which mechanism is that to which you refer? DNS. 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 9311E21F87A4 for ; Mon, 28 Jan 2013 11:53:11 -0800 (PST) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXYD11PwDDWs for ; Mon, 28 Jan 2013 11:53:08 -0800 (PST) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id D55CB21F86AC for ; Mon, 28 Jan 2013 11:53:05 -0800 (PST) Received: by mail-ia0-f181.google.com with SMTP id k25so4692995iah.40 for ; Mon, 28 Jan 2013 11:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mq0LyBbx/V/UiP7CrWOPlY+CrJwHurP4nljTIKEZ+Z8=; b=S+mIcXGuUUQP2GXyK8lCmfpo8jijFclqCwT4lBX83ZSw7HGwF0aRTaPx+qjt1bxOI2 lYPGkAuwoLRAIAOiJuCqBpRq4u//MIqYbTHRCqX21ROtDwTC9pGSzn4cX1GWDvkFF4q6 yOM38wBQO+1K8o4s3m44FZezrhAIc6iGmljySFkLwwHUTDZcha8LC9tyR0QtsQismi6Y PWSrkRKhNSnsn2mMwzTI11qxA0rM5BhpUdH/pxfOstPekTmCzTEBFkMoWHynwJOe390I wFmCFXk3nByrpo3B5raFAbtYn62BZqC+m1Eq5ltIEvMNcSoPJ9btY+9JIXABRJ3k6e6W 0AIQ== MIME-Version: 1.0 X-Received: by 10.50.135.8 with SMTP id po8mr5826111igb.23.1359402771946; Mon, 28 Jan 2013 11:52:51 -0800 (PST) Received: by 10.64.40.234 with HTTP; Mon, 28 Jan 2013 11:52:51 -0800 (PST) In-Reply-To: <20130128173400.GP13806@mx1.yitter.info> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> Date: Mon, 28 Jan 2013 14:52:51 -0500 Message-ID: From: Brian Dickson To: Andrew Sullivan Content-Type: multipart/alternative; boundary=e89a8f83ab13541d7f04d45e9f2f Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 19:53:12 -0000 --e89a8f83ab13541d7f04d45e9f2f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jan 28, 2013 at 12:34 PM, Andrew Sullivan wrote: > On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote: > > > Some of us would like to see mDNS support multiple IP subnets > > (e.g. multiple buildings, multiple groups, multiple (V)LANs) > > within a single administrative domain (e.g. university campus, > > corporate campus). > > > > This implies having a straight-forward way to configure > > networking devices (e.g. firewalls, routers) at the edge > > of one's administrative domain to exclude certain interfaces > > (e.g. exterior uplink interfaces) from all mDNS traffic > > of the administrative domain using mDNS. > > I still do not understand why this sort of thing isn't better handled > by vastly improved tools for real DNS management. I think one of the fundamental problems is, that by merely existing, mDNS has created two namespaces, where the link-local (yes/no) is the only identifying attribute for which namespace applies. Also, creating/improving tools, in general, has certain risks, unless improving things from implict -> explicit (mDNS vs DNS namespace) is done first. The risks I see (in exclusively working on tools) are: - open/standardized tools vs proprietary - scope creep - scaling problems (in terms of development resources) - work done by those who do not fully understand DNS protocols - work done by those who do not fully understand DNS namespaces - work done by idiots - work supported by vendors who have history of horrible implementations - tools in one space breaking things in another space (creating a Hobsons' choice for users) - users - firmware - longevity of deployed hardware/firmware/software > It seems to me that > people are asking for a single, unifed namespace outside the > link-local context, and we invented a mechanism for that many years > ago. The problem is that the support tools for that mechanism sort of > suck. Instead of inventing a new protocol which, by definition, is > going to run into conflicts with the existing protocols in this space, > why wouldn't it be better to take that energy and expend it on the > missing tools? > Just to be clear, which mechanism is that to which you refer? Brian > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > --e89a8f83ab13541d7f04d45e9f2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jan 28, 2013 at 12:34 PM, Andrew= Sullivan <ajs@anvilwalrusden.com> wrote:
On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wro= te:

> Some of us would like to see mDNS support multiple IP subnets
> (e.g. multiple buildings, multiple groups, multiple (V)LANs)
> within a single administrative domain (e.g. university campus,
> corporate campus).
>
> =A0 This implies having a straight-forward way to configure
> =A0 networking devices (e.g. firewalls, routers) at the edge
> =A0 of one's administrative domain to exclude certain interfaces > =A0 (e.g. exterior uplink interfaces) from all mDNS traffic
> =A0 of the administrative domain using mDNS.

I still do not understand why this sort of thing isn't better han= dled
by vastly improved tools for real DNS management.

I think one of the fundamental problems is, that by merely existing,=
mDNS has created two namespaces, where the link-local (yes/no)
is the only identifying attribute for which namespace applies.

Also, creating/improving tools, in general, has certain r= isks, unless
improving things from implict -> explicit (mDNS v= s DNS namespace) is done first.

The risks I see (in exclusively working on tools) are:<= /div>
- open/standardized tools vs proprietary
- scope creep<= /div>
- scaling problems (in terms of development resources)
- work done by those who do not fully understand DNS protocols
- = work done by those who do not fully understand DNS namespaces
- w= ork done by idiots
- work supported by vendors who have history o= f horrible implementations
- tools in one space breaking things in another space (creating a Hobs= ons' choice for users)
- users
- firmware
- longevity of deployed hardware/firmware/software

=A0
=A0It seems to me that
people are asking for a single, unifed namespace outside the
link-local context, and we invented a mechanism for that many years
ago. =A0The problem is that the support tools for that mechanism sort of suck. =A0Instead of inventing a new protocol which, by definition, is
going to run into conflicts with the existing protocols in this space,
why wouldn't it be better to take that energy and expend it on the
missing tools?

Just to be clear, which mechanism is t= hat to which you refer?

Brian
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
mdnsext mailing list
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

--e89a8f83ab13541d7f04d45e9f2f-- 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 0F35121F8915 for ; Mon, 28 Jan 2013 09:54:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zh6mf1IIOmf5 for ; Mon, 28 Jan 2013 09:54:31 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8DD21F87E0 for ; Mon, 28 Jan 2013 09:54:31 -0800 (PST) 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 EA9068A031 for ; Mon, 28 Jan 2013 17:54:30 +0000 (UTC) Date: Mon, 28 Jan 2013 12:54:29 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130128175429.GR13806@mx1.yitter.info> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> <1359394716.21038.140661183424269.2E11AA10@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1359394716.21038.140661183424269.2E11AA10@webmail.messagingengine.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 17:54:32 -0000 On Mon, Jan 28, 2013 at 06:38:36PM +0100, nudge wrote: > Because there's more money to be made being dns experts in a poorly > equipped world ? And larding up mDNS does not re-instantiate this problem how, exactly? 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 4159D21F8930 for ; Mon, 28 Jan 2013 09:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUEVOLnJ3Bht for ; Mon, 28 Jan 2013 09:38:37 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8921F8786 for ; Mon, 28 Jan 2013 09:38:37 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C354420F42 for ; Mon, 28 Jan 2013 12:38:36 -0500 (EST) Received: from web6.nyi.mail.srv.osa ([10.202.2.216]) by compute5.internal (MEProxy); Mon, 28 Jan 2013 12:38:36 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= qIlHE9VDoq3qS+N92zCdSCno544=; b=kOG+nYxYb/sY1J1B7yIiufE1f9my2LId buQs7CZVwTqkLKcnB+eXWzwztN7gFR75g+Unngoc25c39bZGx5ThCpN6QnecoJ04 ognbXqDTzbCR76IvcthvDTV5pGI3aoG9z06dTOv48R/ldZSejlzhK0w21guufseH 6zk9sJvI1Rw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=qIlHE9VDoq3qS+N92zCdSCno544=; b=D2D P2VZCrs8xPzosQpp7CjUhdt67IJnCyNW0+KCw5K40oVgwB2M5PeVqqLPUTBP/C4y 1Bij8rSQXLQq3GfZqAfjd6rd7JGikaxapgi/yu/bCpd+N8jpz+3IySivCCOqOqiy sQ1plsp0WGgSysoV+Gmr54jvsEgnp9hcnfIO3qpM= Received: by web6.nyi.mail.srv.osa (Postfix, from userid 99) id 935EB212B8; Mon, 28 Jan 2013 12:38:36 -0500 (EST) Message-Id: <1359394716.21038.140661183424269.2E11AA10@webmail.messagingengine.com> X-Sasl-Enc: 4azkrnTT5IdAmh3ZMLtgDYaXd8tWa9mtG61dhDIokTRq 1359394716 From: nudge To: mdnsext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - html In-Reply-To: <20130128173400.GP13806@mx1.yitter.info> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> <20130128173400.GP13806@mx1.yitter.info> Date: Mon, 28 Jan 2013 18:38:36 +0100 Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 17:38:38 -0000 On Mon, Jan 28, 2013, at 06:34 PM, Andrew Sullivan wrote: > On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote: > > > Some of us would like to see mDNS support multiple IP subnets > > (e.g. multiple buildings, multiple groups, multiple (V)LANs) > > within a single administrative domain (e.g. university campus, > > corporate campus). > > > > This implies having a straight-forward way to configure > > networking devices (e.g. firewalls, routers) at the edge > > of one's administrative domain to exclude certain interfaces > > (e.g. exterior uplink interfaces) from all mDNS traffic > > of the administrative domain using mDNS. > > I still do not understand why this sort of thing isn't better handled > by vastly improved tools for real DNS management. It seems to me that > people are asking for a single, unifed namespace outside the > link-local context, and we invented a mechanism for that many years > ago. The problem is that the support tools for that mechanism sort of > suck. Instead of inventing a new protocol which, by definition, is > going to run into conflicts with the existing protocols in this space, > why wouldn't it be better to take that energy and expend it on the > missing tools? Because there's more money to be made being dns experts in a poorly equipped world ? 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 1645421F8930 for ; Mon, 28 Jan 2013 09:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlnl-WXk9rLX for ; Mon, 28 Jan 2013 09:34:03 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4B421F8928 for ; Mon, 28 Jan 2013 09:34:03 -0800 (PST) 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 8ECF78A031 for ; Mon, 28 Jan 2013 17:34:01 +0000 (UTC) Date: Mon, 28 Jan 2013 12:34:00 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20130128173400.GP13806@mx1.yitter.info> References: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 17:34:04 -0000 On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote: > Some of us would like to see mDNS support multiple IP subnets > (e.g. multiple buildings, multiple groups, multiple (V)LANs) > within a single administrative domain (e.g. university campus, > corporate campus). > > This implies having a straight-forward way to configure > networking devices (e.g. firewalls, routers) at the edge > of one's administrative domain to exclude certain interfaces > (e.g. exterior uplink interfaces) from all mDNS traffic > of the administrative domain using mDNS. I still do not understand why this sort of thing isn't better handled by vastly improved tools for real DNS management. It seems to me that people are asking for a single, unifed namespace outside the link-local context, and we invented a mechanism for that many years ago. The problem is that the support tools for that mechanism sort of suck. Instead of inventing a new protocol which, by definition, is going to run into conflicts with the existing protocols in this space, why wouldn't it be better to take that energy and expend it on the missing tools? 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 0770721F88B9 for ; Mon, 28 Jan 2013 08:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNcKtptqBMw1 for ; Mon, 28 Jan 2013 08:51:12 -0800 (PST) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB3B21F8871 for ; Mon, 28 Jan 2013 08:51:07 -0800 (PST) Received: by mail-qa0-f51.google.com with SMTP id cr7so643138qab.10 for ; Mon, 28 Jan 2013 08:51:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=zm31TR+1p1VmqtnCEf/h2eB5uwBoWckYa0JC+il8mFQ=; b=shy+gEtH5pm/+VhMHiHXuG4c2HqFBRcYFU3IjW/JfS4j3Idhw1AJlT8obXXLdnW3RZ v/wmS7oxs4KshJH/k49ymHH6iSGCNmWwluaOKF5iSqiULzvW6oi1WGbkBFIY8tu9BeUr 32ajeOIVZeYyiCmm+X7CavRy/Pg/5VdmmQmWTK/BRfnE6lbuaomF6qG0sgFWqp5kv0rd dWBk3iyiQ5Ih3sH0PuQIF4/x/nJudJ5lcCPJzOwiNbFrEboPwohV4nWTTdSj7HkkBiEz J3kUo9pDmbDEYQJbXZEElFVCZZr2132pHWPcIP/6/dFhbDjnrGteXSKyS0v4QpfiQaIY FL0Q== X-Received: by 10.224.34.195 with SMTP id m3mr7135134qad.77.1359391864238; Mon, 28 Jan 2013 08:51:04 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id r13sm5992720qeu.11.2013.01.28.08.51.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 08:51:03 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 28 Jan 2013 11:51:02 -0500 Message-Id: <01E33CD1-89B4-4088-B2BC-F01E34DF6F57@gmail.com> To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 16:51:13 -0000 Some of us would like to see mDNS support multiple IP subnets (e.g. multiple buildings, multiple groups, multiple (V)LANs) within a single administrative domain (e.g. university campus, corporate campus). This implies having a straight-forward way to configure networking devices (e.g. firewalls, routers) at the edge of one's administrative domain to exclude certain interfaces (e.g. exterior uplink interfaces) from all mDNS traffic of the administrative domain using mDNS. To a first approximation, the facility/capability provided by (old) Apple EtherTalk would do very nicely. Kindly note that the ability to group a resource into a non-topological "zone" within that single administrative domain would be most helpful. Overall bandwidth efficiency is also important as a design goal. Some of us have a mixture of different links/subnets with different technologies and bandwidth limitations -- not everything is running at Gbps speeds, over fibre, or over uncontested radio spectrum.[1] Ran [1] Exempli Gratia: IEEE 802.11n does NOT operate at full theoretical performance in typical 2.4 GHz deployments, because of the widespread use of the 2.4 GHz band for a wide range of things -- other 802.11 deployments, cordless telephones, and so on. While the 5 GHz band often has less interference at present, that also is shared, so interference there will tend to grow over time. 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 62D3921F8915 for ; Mon, 28 Jan 2013 08:39:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjCwi1q4MT59 for ; Mon, 28 Jan 2013 08:39:51 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id D281921F88B9 for ; Mon, 28 Jan 2013 08:39:50 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id 1so909469qee.26 for ; Mon, 28 Jan 2013 08:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; bh=dzmVulrGpsFEsVfQwm7uqyXfVPEMrRTSOIffaGR4li8=; b=L/RIQ03FbRP0TOV8UQFpkeNGLiuKX+RPsJ8dwG0b8Z5sFuiFPLAm2q04JEy3d3e8e8 PAlNbbRbDLUivonzbxHBAlpW2zGGvri0AS5GM6swwZmvUvVlVsVKppTKr6h5roBvDicu o4R4mUbvYXERaPbPKk0hpd1oWWlWPMagA6SUvETz07oXlGPHwm5xvs0V3b9jQCIhke5O Mv7BKHajhXZ9ea8WlhTKd9JUh6YPv6kq1WmgjqKLxQG6zNMcT118isYjZ/OyPDiNfnJH kQaTWRckLW0SPIKG2JGV7BE6Bm4CAYexDzlbVmEdzG8OKAcuSf+aoOhJRs0rDUAUxRYz Sh2Q== X-Received: by 10.224.192.195 with SMTP id dr3mr8888789qab.63.1359391190332; Mon, 28 Jan 2013 08:39:50 -0800 (PST) Received: from [10.30.20.13] (pool-96-255-149-117.washdc.fios.verizon.net. [96.255.149.117]) by mx.google.com with ESMTPS id f7sm6116950qap.13.2013.01.28.08.39.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jan 2013 08:39:49 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 28 Jan 2013 11:39:48 -0500 Message-Id: To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [mdnsext] mDNSext features/requirements rollup 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, 28 Jan 2013 16:39:51 -0000 Earlier, Alf Watt wrote: > - multicast on wireless links is expensive, > move as much traffic as possible to unicast This reportedly is true for IEEE 802.11 links as of today. Reports also indicate that some folks active in IEEE 802.11 are looking into this issue, with a goal being to eliminate this issue in future revisions of IEEE 802.11. However, the quote at top is (emphatically) NOT TRUE for a wide range of other wireless links. For MANY wireless link types, multicast is MUCH more efficient and cheaper than unicast. While it is sensible to note this limitation of IEEE 802.11 wireless link technology, it is NOT sensible to impair the applicability of mDNS to the wide range of other links (wired or wireless) where multicast is cheap and efficient. Yours, Ran 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 4682A21F8995 for ; Sat, 26 Jan 2013 22:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+RhpIUV-ylb for ; Sat, 26 Jan 2013 22:46:24 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id AB87621F8967 for ; Sat, 26 Jan 2013 22:46:24 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MH900MV2UT96W52@mail-out.apple.com> for mdnsext@ietf.org; Sat, 26 Jan 2013 22:46:24 -0800 (PST) X-AuditID: 11807134-b7fe36d0000066c0-02-5104cd405298 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay14.apple.com (Apple SCV relay) with SMTP id CF.69.26304.04DC4015; Sat, 26 Jan 2013 22:46:24 -0800 (PST) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MH900CM3UTBMU60@koseret.apple.com> for mdnsext@ietf.org; Sat, 26 Jan 2013 22:46:24 -0800 (PST) From: Stuart Cheshire Date: Sat, 26 Jan 2013 22:46:23 -0800 To: IETF mdnsext Message-id: <7061FD9D-68E6-44CD-9EC3-95A083AD297E@apple.com> X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42IRnG6nrutwliXQ4MURPouTS04xOTB6LFny kymAMYrLJiU1J7MstUjfLoErY//WaywF6yUqDh/oYmpgnC/cxcjJISFgIvHiTwMzhC0mceHe erYuRi4OIYFOJokz05+DJYQEjjBJ/DtlBmKzCWhJvPh8hQ3EZgay1+88zgRha0s8eXeBFcRm EVCV2HT3OlhcWEBTYs7e6WBxEQFliZvnZ4PN5BWwkXi2sIUVwjaUWHJ9CzvEEbISO++cZpnA yDsLyYpZSFbMQtKygJF5FaNgUWpOYqWhiV5iQUFOql5yfu4mRlDINBSa7GA8+JP/EKMAB6MS D++vNJZAIdbEsuLK3EOMEhzMSiK88yuBQrwpiZVVqUX58UWlOanFhxilOViUxHnLHjEFCgmk J5akZqemFqQWwWSZODilGhi5bSY+OW4W7r8r1vCn+mQebVvGltUCoTnHF4ls+leSI9Wz7NRt p4ClqomSBbzP37971cNoW6G/dpk/C/vTInnpRNs1f8SWbHVuXdkWxHYtP71gvvXd6XfuKpVu aNvpXJSZsEX8x8W5kRumTX7gN6F5ql3VYYVX1Xk9LifnHplUctNrkvld14tKLMUZiYZazEXF iQBzAP3PFQIAAA== Subject: [mdnsext] draft-cheshire-mdnsext-hybrid-01 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: Sun, 27 Jan 2013 06:46:25 -0000 In private discussions about draft-cheshire-mdnsext-hybrid-00, it is evident that the document is not clear about which parts of the proposal already exist, and which are new. Accordingly, I have submitted an update which adds this section: 4. Implementation Status Some aspects of the mechanism specified in this document already exist in deployed software. Some aspects are new. This section outlines which aspects already exist and which are new. 4.1. Already Implemented and Deployed Domain enumeration discovery by the client (the "b._dns-sd._udp" queries) is already implemented and deployed. Unicast queries to the indicated discovery domain is already implemented and deployed. These are implemented and deployed in Mac OS X 10.4 and later (including all versions of Apple iOS, on all iPhone and iPads) in Bonjour for Windows, and in Android 4.1 "Jelly Bean" (API Level 16) and later. Domain enumeration discovery and unicast querying have been used for several years at IETF meetings to make Terminal Room printers discoverable from outside the Terminal room. When you Press Cmd-P on your Mac, or select AirPrint on your iPad or iPhone, and the Terminal room printers appear, that is because your client is doing unicast DNS queries to the IETF DNS servers. 4.2. Partially Implemented The current APIs make multiple domains visible to client software, but most client UI today lumps all discovered services into a single flat list. This is largely a chicken-and-egg problem. Application writers were naturally reluctant to spend time writing domain-aware UI code when few customers today would benefit from it. If Hybrid Proxy deployment becomes common, then application writers will have a reason to provide better UI. Existing applications will work with the Hybrid Proxy, but will show all services in a single flat list. Applications with improved UI will group services by domain. The Long-Lived Query mechanism [I-D.sekar-dns-llq] referred to in this specification exists and is deployed, but has not been standardized by the IETF. It is possible that the IETF may choose to standardize a different or better Long-Lived Query mechanism. In that case, the pragmatic deployment approach would be for vendors to produce Hybrid Proxies that implement both the deployed Long-Lived Query mechanism [I-D.sekar-dns-llq] (for today's clients) and a new IETF Standard Long-Lived Query mechanism (as the future long-term direction). 4.3. Not Yet Implemented The translating/filtering Hybrid Proxy specified in this document. Once implemented, such a Hybrid Proxy will immediately make wide-area discovery available with today's existing clients and devices. A mechanism to 'stitch' together multiple ".local." zones so that they appear as one. Such a mechanism will be specified in a future companion document. Stuart Cheshire 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 2F21921F8929 for ; Sat, 26 Jan 2013 12:38:27 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXoZFzp+Ej7s for ; Sat, 26 Jan 2013 12:38:26 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDE421F88F1 for ; Sat, 26 Jan 2013 12:38:25 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6BA1A2016D for ; Fri, 25 Jan 2013 11:34:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 70E9963765; Fri, 25 Jan 2013 11:28:20 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5E445636C4 for ; Fri, 25 Jan 2013 11:28:20 -0500 (EST) From: Michael Richardson To: IETF mdnsext In-Reply-To: <65245680-41DC-4B28-98FE-9EA97C6EB06E@apple.com> References: <65245680-41DC-4B28-98FE-9EA97C6EB06E@apple.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-01.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: Sat, 26 Jan 2013 20:38:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Stuart" =3D=3D Stuart Cheshire writes: Stuart> We just submitted draft-lynn-mdnsext-requirements-01.txt Stuart> Stuart> Please review and give feedback. I read this document. >Service discovery beyond the local link is probably the most=09 > important feature missing currently in the DNS-SD/mDNS framework. > The following describes some of the issues. I think it's important that we take these words in account, and maybe we should rename the effort sto something like: DNS-based site-wide service discovery (DBSWSD? DSSD?... maybe someone else will come up with a nice IETF WG acronym). I think that we will make better progress is we talk more about the problem, with the understanding that it involves extending mdns/DNS-SD, but that it isn't just mDNS. I find the document is very clear, and I think that it is a good problem statement for creation of a group. I very much appreciate that non-multicast things are being considered. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQKypIqHRg3pndX9AQKxzAP6A2TyzUmMV1jh7gLaZOUPolWErXjZjxnS de0bDseZS+THok2EQUkLrmbENOGrQP7mtXUTNQcn/JoKwX1QClxSc0QIqD+uAHjO QIgXAIHiwhsJtK0mV+hWlV6LGlJDVvhWvZfLNl5GpHyQmp3E1aDY64gHWOHAl2fZ A/aeBcfaVRo= =a+RY -----END PGP SIGNATURE----- --=-=-=-- 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 C04FB21F853A for ; Fri, 25 Jan 2013 22:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBuWH0lnP4e3 for ; Fri, 25 Jan 2013 22:04:12 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A923F21F8570 for ; Fri, 25 Jan 2013 22:04:12 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MH700G39Y70KQ11@mail-out.apple.com> for mdnsext@ietf.org; Fri, 25 Jan 2013 22:04:12 -0800 (PST) X-AuditID: 11807112-b7f296d000001183-5a-510371dc4b0d Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 36.A2.04483.CD173015; Fri, 25 Jan 2013 22:04:12 -0800 (PST) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by jimbu.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MH7006PCY6ZGS20@jimbu.apple.com> for mdnsext@ietf.org; Fri, 25 Jan 2013 22:04:12 -0800 (PST) From: Stuart Cheshire Date: Fri, 25 Jan 2013 22:04:11 -0800 Message-id: To: IETF mdnsext X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpiluLIzCtJLcpLzFFi42IRnG6nqnunkDnQoOcnr8XJJaeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8bT/CHPBJ86K3gO2DYy/2bsYOTkkBEwkJq7dyAxhi0lcuLee rYuRi0NIoJVJ4krHWyYI5wCTROeUnSwgVWwCWhIvPl9hA7GZgez1O48zQdjaEk/eXWAFsYUF NCUWL/gOVs8ioCrxa9k9sHpeARuJuYdawepFBJQlbp6fzQwRN5RYcn0L1EWyEjvvnGaZwMg7 C8mKWUhWzELSsoCReRWjYFFqTmKlobleYkFBTqpecn7uJkZQyDQUCu1gvL9L7xCjAAejEg+v 5wKmQCHWxLLiytxDjBIczEoivNW5zIFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeWseAVULpCeW pGanphakFsFkmTg4pRoYmWtkO94V+7GEl5rpJrx+Y2agP3kG4zO2h9MSf1xP9qu/qWiruObU CYPE/xZTzyZmqp1Y982D8fef5ckpTlkvS5zfH5s2tZHVZcOHWWUF0m6VymrswZGdC3fN0Hc7 /tk9ZFET92Xe9cu5eSxbrdckhGYxvdab4XRuw7pj8QuPSqXJJCQveTVRiaU4I9FQi7moOBEA jjLa1hUCAAA= Subject: [mdnsext] draft-cheshire-mdnsext-hybrid-00 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: Sat, 26 Jan 2013 06:04:13 -0000 I have submitted a new Internet Draft that proposes a way to address the mdnsext problem. Please review and give feedback. Title: Hybrid Unicast/Multicast DNS-Based Service Discovery Creation date: 2013-01-25 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-cheshire-mdnsext-hybrid-00.txt Status: http://datatracker.ietf.org/doc/draft-cheshire-mdnsext-hybrid Htmlized: http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-00 Abstract: Performing DNS-Based Service Discovery using purely Multicast DNS allows discovery only of services present on the local link. Using a very large local link with thousands of hosts improves service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient, but requires configuration of DNS Update keys on the devices offering the services, which can be onerous for simple devices like printers and network cameras. Hence a compromise is needed, that provides easy service discovery without requiring either large amounts of multicast traffic or onerous configuration. Stuart Cheshire 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 3442421F85D7 for ; Thu, 24 Jan 2013 21:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN9dKTCh3mVB for ; Thu, 24 Jan 2013 21:41:47 -0800 (PST) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A8E3111E80DE for ; Thu, 24 Jan 2013 21:41:44 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MH600MP42HKY180@mail-out.apple.com> for mdnsext@ietf.org; Thu, 24 Jan 2013 21:41:44 -0800 (PST) X-AuditID: 11807137-b7f156d000005a91-42-51021b18f8dc Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 2D.2C.23185.81B12015; Thu, 24 Jan 2013 21:41:44 -0800 (PST) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MH600KXB2HJ3B00@koseret.apple.com> for mdnsext@ietf.org; Thu, 24 Jan 2013 21:41:43 -0800 (PST) From: Stuart Cheshire Date: Thu, 24 Jan 2013 21:41:43 -0800 Message-id: <65245680-41DC-4B28-98FE-9EA97C6EB06E@apple.com> To: IETF mdnsext X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkluLIzCtJLcpLzFFi42IRnG6nrishzRRo8PkGl8XJJaeYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8W/LNKaCduaKpk/32BoYjzB1MXJySAiYSPxrfMwCYYtJXLi3 nq2LkYtDSKCTSeJB92lGCOcIk8S+9d1gVWwCWhIvPl9hA7GZgez1O48zQdjaEk/eXWDtYuTg EBbQl/jQzgRisgioSnzd4AVSwStgI/HnyhVGEFtEQFni5vnZzBBxQ4kl17ewQ9wgK7HzzmmW CYy8s5AsmIVkwSwkLQsYmVcxChal5iRWGprpJRYU5KTqJefnbmIEBUxDofkOxu1/5Q4xCnAw KvHwWqUxBgqxJpYVV+YeYpTgYFYS4TX8ABTiTUmsrEotyo8vKs1JLT7EKM3BoiTOKyEDlBJI TyxJzU5NLUgtgskycXBKNTBeqtnOorff5nZgz9c9x/fN+9p0bdPGOeW2NxJWVJWbd37/OcWN LVLy59LdybHvf/02+Lah4afEkbDaZ1ue8lxp1rW5cIxD9bNI29yi6DjrXQl5b3QSjd+Hi992 Os9R/qn0p+Djfq2mIzJG8Qx+P5qcGbPtzGIqRLbvDZ504pZCb/1UtasKS6YrsRRnJBpqMRcV JwIAOvMb+BQCAAA= Subject: [mdnsext] draft-lynn-mdnsext-requirements-01.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: Fri, 25 Jan 2013 05:41:48 -0000 We just submitted draft-lynn-mdnsext-requirements-01.txt Please review and give feedback. The deadline is next Thursday for the IESG to decide whether to schedule an mdnsext BoF meeting at IETF 86 in March, so any discussion before that date is useful for helping them make their decision. Stuart Cheshire 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 A8AED21F859A for ; Wed, 23 Jan 2013 12:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gv4XmovE9j9S for ; Wed, 23 Jan 2013 12:18:21 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe002.messaging.microsoft.com [213.199.154.140]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4521F8570 for ; Wed, 23 Jan 2013 12:18:20 -0800 (PST) Received: from mail42-db3-R.bigfish.com (10.3.81.249) by DB3EHSOBE010.bigfish.com (10.3.84.30) with Microsoft SMTP Server id 14.1.225.23; Wed, 23 Jan 2013 20:18:19 +0000 Received: from mail42-db3 (localhost [127.0.0.1]) by mail42-db3-R.bigfish.com (Postfix) with ESMTP id 271F8A0267 for ; Wed, 23 Jan 2013 20:18:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zz1454Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzzz32i2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1155h) Received: from mail42-db3 (localhost.localdomain [127.0.0.1]) by mail42-db3 (MessageSwitch) id 1358972297367501_29736; Wed, 23 Jan 2013 20:18:17 +0000 (UTC) Received: from DB3EHSMHS010.bigfish.com (unknown [10.3.81.233]) by mail42-db3.bigfish.com (Postfix) with ESMTP id 571E614004C for ; Wed, 23 Jan 2013 20:18:17 +0000 (UTC) Received: from CH1PRD0811HT005.namprd08.prod.outlook.com (157.56.245.85) by DB3EHSMHS010.bigfish.com (10.3.87.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 23 Jan 2013 20:18:17 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.74]) by CH1PRD0811HT005.namprd08.prod.outlook.com ([10.255.155.40]) with mapi id 14.16.0257.004; Wed, 23 Jan 2013 20:18:16 +0000 From: Alf Watt To: "mdnsext@ietf.org" Thread-Topic: mDNSext features/requirements rollup Thread-Index: AQHN+abGAkt7d5gx1EeHFkBSg0TotQ== Date: Wed, 23 Jan 2013 20:18:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.155.4] Content-Type: text/plain; charset="us-ascii" Content-ID: <879F85127DFA8C4D8DB765B0C94BE1C5@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com Subject: [mdnsext] mDNSext features/requirements rollup 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, 23 Jan 2013 20:18:21 -0000 I've worked back through the mail log and assembled all the common features= and requirements that I could identify, there's likely some personal bias = in this list as I have preferences on how to implement some of these, but h= opefully it's enough to get our BoF in the air: Multicast Domain Bridging (Bonjour Bridge) - this is the feature that multiple vendors are currently working on, brie= fly: Bonjour packets are proxied between two multicast domains, optionally wit= h filters. Multicast to Unicast Proxy/Relay/Middlebox - proposed feature where local services can be browsed via unicast dns for= efficiency or to cover a wider area - functionally looks like a DYN-DNS server but updates via mdns queries in= stead of registration by clients - resolve namespace collision issues (each multicast domain may need a sep= arate .local or .site subdomain) - support for long-lived unicast queries to the proxy Improved performance - multicast on wireless links is expensive, move as much traffic as possib= le to unicast=20 - use multicast to discover the local proxy (or lack thereof) and switch t= o unicast if present Administrative & Security Features - suppression of some or all bonjour activity, selected services or other = filters (e.g. browse-only domains) - redirection to a Bonjouor proxy or other alternate service discovery mec= hanism (see above) - this 'breaks' some features but is better than complete suppression whic= h is currently common - validation of service advertisements and resolution (prevent resolution = spoofing) - Users and devices are only authorized to advertise certain services - Service advertisements are only delivered to authorized recipients - ensure that service resolution is authoritative for the advertisement, w= hether it is an original or proxy advertisement" I'm sure I missed a few, please feel free to fill in the list. Best, Alf= 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 F189121F86B7 for ; Mon, 21 Jan 2013 05:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw0xXnWRpfqW for ; Mon, 21 Jan 2013 05:29:05 -0800 (PST) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id DCC1F21F85B6 for ; Mon, 21 Jan 2013 05:29:00 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r0LDSpAG084407 for ; Mon, 21 Jan 2013 14:28:51 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-194-144.w90-0.abo.wanadoo.fr ([90.0.97.144]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 21 Jan 2013 14:28:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Mon, 21 Jan 2013 14:28:51 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: <2dc001810b6299f42965ce3a5ab6152f@xs4all.nl> X-Sender: stokcons@xs4all.nl (XeXF83nkMR8O+nuVqX3ZvhNLr6391+0Y) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [mdnsext] =?utf-8?q?mDNSext_BoF_at_IETF_86=3F?= X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 13:29:06 -0000 +1 I will certainly attend. important aspects for me are: - scalability of mDNS - automatic switch from mDNS to DNS on network connection - service and resource disovery Simpson, Robby (GE Energy Management) schreef op 2013-01-16 17:13: > +1 > > There's a lot to do here (IMHO) and I would attend a follow-up BoF. > > > > On 1/7/13 1:38 PM, "Alf Watt" wrote: > >> I'm looking at the IETF 86 meeting dates and notice the following: >> >> € 2012-12-10 (Monday): Working Group and BOF scheduling begins. >> € 2013-01-14 (Monday): Cutoff date for requests to schedule Working >> Group meetings at UTC 24:00. >> € 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area >> Directors at UTC 24:00. >> € 2013-01-31 (Thursday): Cutoff date for Area Directors to approve >> BOFs >> at UTC 24:00. >> >> I don't think we have enough activity here to justify a new WG at >> this >> time, but it would be good to have a follow-up BoF if we can get it >> approved. >> >> Comments? >> >> Best, >> Alf >> _______________________________________________ >> 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 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 EF17E21F8AD8 for ; Wed, 16 Jan 2013 08:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxxdYYZfE0yN for ; Wed, 16 Jan 2013 08:13:17 -0800 (PST) Received: from exprod5og116.obsmtp.com (exprod5og116.obsmtp.com [64.18.0.147]) by ietfa.amsl.com (Postfix) with ESMTP id 21A5121F8AD4 for ; Wed, 16 Jan 2013 08:13:17 -0800 (PST) Received: from alpmlip12.e2k.ad.ge.com ([165.156.5.1]) (using TLSv1) by exprod5ob116.postini.com ([64.18.4.12]) with SMTP ID DSNKUPbRnBHNiXDndaMFCDSYwYip4awJlU2f@postini.com; Wed, 16 Jan 2013 08:13:17 PST Received: from unknown (HELO cinmlef12.e2k.ad.ge.com) ([3.159.213.59]) by alpmlip12.e2k.ad.ge.com with ESMTP; 16 Jan 2013 11:13:15 -0500 Received: from alpmlef03.e2k.ad.ge.com ([3.159.18.12]) by cinmlef12.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 11:13:14 -0500 Received: from cinmlch01.e2k.ad.ge.com ([3.159.212.50]) by alpmlef03.e2k.ad.ge.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jan 2013 11:13:13 -0500 Received: from CINMBCNA12.e2k.ad.ge.com (3.159.212.41) by cinmlch01.e2k.ad.ge.com (3.159.212.50) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 16 Jan 2013 11:13:10 -0500 Received: from CINMBCNA02.e2k.ad.ge.com ([169.254.2.118]) by CINMBCNA12.e2k.ad.ge.com ([169.254.6.102]) with mapi id 14.02.0318.004; Wed, 16 Jan 2013 11:13:10 -0500 From: "Simpson, Robby (GE Energy Management)" To: Alf Watt , "mdnsext@ietf.org" Thread-Topic: [mdnsext] mDNSext BoF at IETF 86? Thread-Index: AQHN7QYpCRfy7Msl5ke8X75JT8hA45hMLrIA Date: Wed, 16 Jan 2013 16:13:10 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [3.159.212.187] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jan 2013 16:13:13.0850 (UTC) FILETIME=[62D0A5A0:01CDF404] Cc: Stuart Cheshire Subject: Re: [mdnsext] mDNSext BoF at IETF 86? 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, 16 Jan 2013 16:13:18 -0000 +1 There's a lot to do here (IMHO) and I would attend a follow-up BoF. On 1/7/13 1:38 PM, "Alf Watt" wrote: >I'm looking at the IETF 86 meeting dates and notice the following: > > =80 2012-12-10 (Monday): Working Group and BOF scheduling begins. > =80 2013-01-14 (Monday): Cutoff date for requests to schedule Working >Group meetings at UTC 24:00. > =80 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area >Directors at UTC 24:00. > =80 2013-01-31 (Thursday): Cutoff date for Area Directors to approve BOFs >at UTC 24:00. > >I don't think we have enough activity here to justify a new WG at this >time, but it would be good to have a follow-up BoF if we can get it >approved. > >Comments? > >Best, >Alf >_______________________________________________ >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 273B321F8953 for ; Mon, 14 Jan 2013 06:26:34 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAWfe1OCuLOu for ; Mon, 14 Jan 2013 06:26:33 -0800 (PST) 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 A146021F8959 for ; Mon, 14 Jan 2013 06:26:32 -0800 (PST) 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 r0EEQJC4026415; Mon, 14 Jan 2013 14:26:19 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r0EEQJC4026415 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1358173580; bh=esQeOhy7bGli0aRdLcWn3uSqtoE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=RVMf8AP/UrPfttRX4PK/FFgVWZVNFuOcgm1DR7uhgtpTK1rqCl1tTzg0r1MdKQdLK fMDpswroGSjbWoK6jYCAK77d+LWYr6qTIOHDMMn1GTZ2T0mKwsyjAbQQa2BVvhUv88 sa6FLZ5SEZ64HVPUeXs12TQAP9KNmASHehcx2AxQ= 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 p0DEQJ0430634362K2 ret-id none; Mon, 14 Jan 2013 14:26:20 +0000 Received: from ip-162-213.eduroam.soton.ac.uk (ip-162-213.eduroam.soton.ac.uk [152.78.162.213]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r0EEQGi8022842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 14 Jan 2013 14:26:17 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: Date: Mon, 14 Jan 2013 14:26:16 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4FC664B4-9272-4F07-9878-1CC0EFE33C70@ecs.soton.ac.uk> To: "Brzozowski, John" X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p0DEQJ043063436200; tid=p0DEQJ0430634362K2; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r0EEQJC4026415 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: Stuart Cheshire , "mdnsext@ietf.org" , Alf Watt Subject: Re: [mdnsext] mDNSext BoF at IETF 86? 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, 14 Jan 2013 14:26:34 -0000 On 9 Jan 2013, at 02:35, "Brzozowski, John" = wrote: > There seems to be a great deal to discuss here. I for one would like = to > see the conversations around premise wide service discovery continue. = I > admit I have not kept up with the list activity to date, however, I = will > try to do so in the weeks leading up to IETF86. Hi Jon, I have contacted Ralph to see what his views are, with a view to a = second BoF at Orlando. We as yet have seen no progress on the requirements draft; it would be = good to see some movement there. It would also be good to understand which vendors are doing what, e.g. I = know from our own campus that Cisco are implementing certain = functionality in their WLC/WiSM platforms for v7.4 and then 8.0 of their = controller software. Reviewing such activity might help us understand = the problem space, and the initial steps being taken that we might seek = to harmonise via IETF work. 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 E90AB21F853C for ; Tue, 8 Jan 2013 18:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.897 X-Spam-Level: X-Spam-Status: No, score=-100.897 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l1JVWe36-qE for ; Tue, 8 Jan 2013 18:35:35 -0800 (PST) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 065C021F866F for ; Tue, 8 Jan 2013 18:35:34 -0800 (PST) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.39493940; Tue, 08 Jan 2013 21:25:00 -0500 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.184]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Tue, 8 Jan 2013 21:35:31 -0500 From: "Brzozowski, John" To: Alf Watt , "mdnsext@ietf.org" Thread-Topic: [mdnsext] mDNSext BoF at IETF 86? Thread-Index: AQHN7QYpCRfy7Msl5ke8X75JT8hA45g/4B0A Date: Wed, 9 Jan 2013 02:35:30 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [24.40.55.72] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6C300FFC79BD8B4682EB3EB3CD4B4A6A@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Stuart Cheshire Subject: Re: [mdnsext] mDNSext BoF at IETF 86? 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, 09 Jan 2013 02:35:36 -0000 There seems to be a great deal to discuss here. I for one would like to see the conversations around premise wide service discovery continue. I admit I have not kept up with the list activity to date, however, I will try to do so in the weeks leading up to IETF86. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) +1-609-377-6594 e) mailto:john_brzozowski@cable.comcast.com o) +1-484-962-0060 w) http://www.comcast6.net =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Alf Watt Date: Monday, January 7, 2013 1:38 PM To: "mdnsext@ietf.org" Cc: Stuart Cheshire Subject: [mdnsext] mDNSext BoF at IETF 86? >I'm looking at the IETF 86 meeting dates and notice the following: > > =80 2012-12-10 (Monday): Working Group and BOF scheduling begins. > =80 2013-01-14 (Monday): Cutoff date for requests to schedule Working >Group meetings at UTC 24:00. > =80 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area >Directors at UTC 24:00. > =80 2013-01-31 (Thursday): Cutoff date for Area Directors to approve BOFs >at UTC 24:00. > >I don't think we have enough activity here to justify a new WG at this >time, but it would be good to have a follow-up BoF if we can get it >approved. > >Comments? > >Best, >Alf >_______________________________________________ >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 A530921F84BC for ; Mon, 7 Jan 2013 10:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP54WRxknnro for ; Mon, 7 Jan 2013 10:38:23 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2764721F849A for ; Mon, 7 Jan 2013 10:38:22 -0800 (PST) Received: from mail117-ch1-R.bigfish.com (10.43.68.240) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Mon, 7 Jan 2013 18:38:21 +0000 Received: from mail117-ch1 (localhost [127.0.0.1]) by mail117-ch1-R.bigfish.com (Postfix) with ESMTP id 3C8DCC020F; Mon, 7 Jan 2013 18:38:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT003.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zz936eIdf9Izz1de0h1202h1e76h1d1ah1d2ahzzz32i2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail117-ch1 (localhost.localdomain [127.0.0.1]) by mail117-ch1 (MessageSwitch) id 1357583899515308_1349; Mon, 7 Jan 2013 18:38:19 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.238]) by mail117-ch1.bigfish.com (Postfix) with ESMTP id 722D32A0074; Mon, 7 Jan 2013 18:38:19 +0000 (UTC) Received: from CH1PRD0811HT003.namprd08.prod.outlook.com (157.56.245.85) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 7 Jan 2013 18:38:19 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.38]) by CH1PRD0811HT003.namprd08.prod.outlook.com ([10.255.155.38]) with mapi id 14.16.0245.002; Mon, 7 Jan 2013 18:38:18 +0000 From: Alf Watt To: "mdnsext@ietf.org" Thread-Topic: mDNSext BoF at IETF 86? Thread-Index: AQHN7QYpCRfy7Msl5ke8X75JT8hA4w== Date: Mon, 7 Jan 2013 18:38:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.155.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: <88A989B079AF984D964000B48FCA6360@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com Cc: Stuart Cheshire Subject: [mdnsext] mDNSext BoF at IETF 86? X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 18:38:23 -0000 I'm looking at the IETF 86 meeting dates and notice the following: =95 2012-12-10 (Monday): Working Group and BOF scheduling begins.=20 =95 2013-01-14 (Monday): Cutoff date for requests to schedule Working Grou= p meetings at UTC 24:00.=20 =95 2013-01-28 (Monday): Cutoff date for BOF proposal requests to Area Dir= ectors at UTC 24:00.=20 =95 2013-01-31 (Thursday): Cutoff date for Area Directors to approve BOFs = at UTC 24:00. I don't think we have enough activity here to justify a new WG at this time= , but it would be good to have a follow-up BoF if we can get it approved. Comments? Best, Alf=