Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-01.txt
From: David Farmer <[email-masked]>
To: Stuart Cheshire <[email-masked]>
Cc: IETF mdnsext <[email-masked]>, Kerry Lynn <[email-masked]>, David Farmer <[email-masked]>
Date: Thu, 31 Jan 2013 18:40:46 -0600
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>

On 1/24/13 23:41 , Stuart Cheshire wrote:
> We just submitted draft-lynn-mdnsext-requirements-01.txt
>
> <http://www.ietf.org/id/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: [email-masked]
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
================================================

Date: Thu, 31 Jan 2013 16:54:21 -0500
From: Kerry Lynn <[email-masked]>
To: [email-masked]
Subject: [mdnsext] BoF postponement

--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,<br>
<br>The main organizers of the first BoF met with the responsible AD (Ralph=
 Droms)<br>yesterday to discuss our progress toward WG formation.=A0 Given =
the remaining<br>amount of work it will take to make WG formation a &quot;n=
o brainer&quot; from the IESG&#39;s<br>

perspective, it was felt prudent to delay the final BoF until Berlin.=A0 Th=
is is far<br>better than scheduling it for Orlando and then canceling it at=
 the last minute if<br>we don&#39;t make sufficient progress in the next fe=
w weeks.<br>

<br>Here&#39;s my short list of the remaining work:<br>- Converge on a set =
of use cases and derived requirements in the form of the<br>=A0 Requirement=
s draft (yours truly, editor).=A0 This includes:<br>=A0 * closer coordinati=
on with homenet and other WGs=A0 to ensure we&#39;re adequately<br>

=A0=A0=A0 capturing their requirements<br>=A0 * more discussion on the secu=
rity issues raised by extending DNS-SD/mDNS<br>=A0=A0=A0 (i.e. a fairly com=
plete &quot;Security Considerations&quot; section in the draft)<br>=A0 * mo=
re discussion and representative examples of the &quot;two namespaces&quot;=
<br>

=A0=A0=A0 issue discussed on the list<br>- Discussion of Stuart&#39;s <a hr=
ef=3D"http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid" target=3D"_=
blank">http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid</a><br>=A0 =
or other proposals<br>
- Convergence on the charter<br>
<br>We plan to hold a Bar BoF in Orlando for interested parties.=A0 Date an=
d time will<br>be announced on the mailing list when the agenda comes out, =
then a place will<br>be determined and announced in Orlando on 10 March.<br=
>

<br>We trust the work on the list will continue unabated as we refine the r=
equirements<br>and move toward a solution.=A0 Special thanks to Tim Chown f=
or pulling together<br>the BoF Request earlier in the week and for his unde=
rstanding that we&#39;ll use it<br>

all next time.<br><br>Regards, Kerry Lynn

--f46d0445187b554fe904d49cab40--

Sender: [email-masked]
Date: Wed, 30 Jan 2013 15:39:28 +0100
From: Olivier Levon <[email-masked]>
To: [email-masked]
Subject: [mdnsext]  mDNSext features/requirements rollup

--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 <[email-masked]> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mdnsext
> >
>
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

--00235429c7bc42144b04d4827a86
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><div class=3D"gmail_quote"><div><div class=
=3D"h5">Hi,<br><br>Some people did various patches to suport WAB in POSIX, =
like <a href=3D"http://www.roguelazer.com/tips/2010/02/dynamic-dns-part-two=
/" target=3D"_blank">http://www.roguelazer.com/tips/2010/02/dynamic-dns-par=
t-two/</a> or <a href=3D"https://github.com/gkaindl/Community-mdnsResponder=
" target=3D"_blank">https://github.com/gkaindl/Community-mdnsResponder</a>.=
<br>

They were published on the bonjour-dev mailing list.<br>=A0<br>For my own u=
se, I&#39;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).<br>

<br>Best,<br><br>Olivier <br><div><div><br><div class=3D"gmail_quote">On Tu=
e, Jan 29, 2013 at 8:33 PM, vortex <span dir=3D"ltr">&lt;<a href=3D"mailto:=
[email-masked]" target=3D"_blank">[email-masked]</a>&=
gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
The problem has been that the POSIX and non-apple WAB component for<br>
read/write DNS-SD under the bonjour stack has been broken and ignored<br>
for years.<br>
<br>
Integrating mDNS &amp; WAB has been close on impossible because of this<br>
(reference all the frustrations on the bonjour-dev mailing list without<br>
resolution, again, it&#39;s been years!).<br>
<br>
Alternate stacks such as avahi (non-cross platform) have waited for<br>
&quot;vital&quot; security implementations for DNSSEC before implementing w=
rite<br>
enabled DNS-SD (a big mistake IMHO!), and because DNSSEC is so hairy<br>
this has not happened either (on their roadmap unimplemented/delayed for<br=
>
years).<br>
<br>
WAB &amp; m~DNS has had the potential to be an exciting cross platform<br>
Internet-wide resource publishing and discovery mechanism, but their<br>
seems little interest in the past to make this happen,<br>
<br>
Regards to all,<br>
<br>
.v<br>
<div><div><br>
On 29/01/2013 18:39, nudge wrote:<br>
&gt; On Tue, Jan 29, 2013, at 07:07 PM, Alf Watt wrote:<br>
&gt;&gt;<br>
&gt;&gt; I think Andrew&#39;s point is worth taking the time to seriously c=
onsider. We<br>
&gt;&gt; already have dynamic DNS update but as previously mentioned config=
uration<br>
&gt;&gt; of the DNS server and it&#39;s clients out has proven to be either=
 too<br>
&gt;&gt; difficult or not of interest to various OS vendors.<br>
&gt;&gt;<br>
&gt;&gt; It&#39;s worth mentioning that Apple has all the parts in place to=
 pull this<br>
&gt;&gt; off:<br>
&gt;&gt;<br>
&gt;&gt; - A Server OS with an embedded DNS server which they provide a UI =
to<br>
&gt;&gt; manage<br>
&gt;&gt; - Traditional and Mobile Clients with mDNSResolvers running on the=
m<br>
&gt;&gt; - A profile distribution system which make pushing configuration o=
ptions<br>
&gt;&gt; including keys easy<br>
&gt;&gt;<br>
&gt;&gt; Given the will to get the features implemented Apple could solve p=
art of<br>
&gt;&gt; the problem this without any changes to mdns.<br>
&gt;&gt;<br>
&gt;&gt; There are still things that fall outside of that scope which we sh=
ould<br>
&gt;&gt; consider, but ignoring the opportunity to uses the existing protoc=
ols<br>
&gt;&gt; seems like a lot of effort to reproduce work that already exists.<=
br>
&gt;&gt;<br>
&gt;&gt; Best,<br>
&gt;&gt; Alf<br>
&gt;&gt;<br>
&gt;<br>
&gt; As someone who successfully tested and implemented WAB with TSIG<br>
&gt; protected updates[1] in an Apple environment about a year or so ago, I=
<br>
&gt; would tend to agree. It wasn&#39;t as difficult as I imagined partly b=
ecause<br>
&gt; of a lack of documentation. Of course, things have changed since and I=
<br>
&gt; need to test again soon. But back then you had to front-end named with=
<br>
&gt; dnsextd if you needed llq (obviously you do). If that&#39;s still true=
 it<br>
&gt; blocks other useful stuff such as rpz and rrl and needs fixing IMO.<br=
>
&gt;<br>
&gt; [1]I also tested TSIG protected reads DNSprivate, where&#39;s that goi=
ng ?<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; mdnsext mailing list<br>
&gt; <a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]=
</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/mdnsext</a><br>
&gt;<br>
<br>
_______________________________________________<br>
mdnsext mailing list<br>
<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a><=
br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/mdnsext</a><br>
</div></div></blockquote></div><br>
</div></div></div></div></div><br>
</div><br>

--00235429c7bc42144b04d4827a86--

Date: Wed, 30 Jan 2013 07:11:24 +0000
From: vortex <[email-masked]>
Organization: free2air
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Reply-To: [email-masked]

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

Date: Tue, 29 Jan 2013 15:04:49 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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
[email-masked]

Date: Tue, 29 Jan 2013 19:33:56 +0000
From: vortex <[email-masked]>
Organization: free2air
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Reply-To: [email-masked]

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
> 

From: David Farmer <[email-masked]>
Date: Tue, 29 Jan 2013 12:59:51 -0600
To: "Stephen Orr (sorr)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Dan Harkins <[email-masked]>
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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:[email-masked]
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)" <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf=
 Of Dan Harkins
> Sent: Tuesday, January 29, 2013 12:24 PM
> To: David Farmer
> Cc: [email-masked]; 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

From: nudge <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Tue, 29 Jan 2013 19:39:12 +0100
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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 ?

From: "Stephen Orr (sorr)" <[email-masked]>
To: Dan Harkins <[email-masked]>, David Farmer <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 29 Jan 2013 18:11:59 +0000
Accept-Language: en-US
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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: [email-masked] [mailto:[email-masked]] On Behalf =
Of Dan Harkins
Sent: Tuesday, January 29, 2013 12:24 PM
To: David Farmer
Cc: [email-masked]; 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mdnsext

From: Alf Watt <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Tue, 29 Jan 2013 18:07:57 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] mDNSext features/requirements rollup

--_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, [email-masked]<mailto:mdnsext-reque=
[email-masked]> wrote:

From: Andrew Sullivan <[email-masked]<mailto:[email-masked]=
>>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Date: January 28, 2013 9:34:00 AM PST
To: <[email-masked]<mailto:[email-masked]>>

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
[email-masked]<mailto:[email-masked]>

--_000_D99048ACAF96354EBFD6A811E3C65ACD10977A7CCH1PRD0811MB407_
Content-Type: text/html; charset="us-ascii"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; ">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>It's worth mentioning that Apple has all the parts in place to pull th=
is off:</div>
<div><br>
</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>- A Se=
rver OS with an embedded DNS server which they provide a UI to manage</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>- Trad=
itional and Mobile Clients with mDNSResolvers running on them</div>
<div><span class=3D"Apple-tab-span" style=3D"white-space:pre"></span>- A pr=
ofile distribution system which make pushing configuration options includin=
g keys easy</div>
<div><br>
</div>
<div>Given the will to get the features implemented Apple could solve part =
of the problem this without any changes to mdns.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Best,</div>
<div>Alf</div>
<br>
<div>
<div>On Jan 28, 2013, at 12:03 PM, <a href=3D"mailto:[email-masked]=
rg">[email-masked]</a> wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<div style=3D"font-family: Helvetica; font-size: medium; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text=
-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki=
t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; margin: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; color: rgb(127, 1=
27, 127); "><b>From:<span class=3D"Apple-converted-space">&nbsp;</span></b>=
</span><span style=3D"font-family: Helvetica; font-size: medium; ">Andrew S=
ullivan &lt;<a href=3D"mailto:[email-masked]">[email-masked]=
m</a>&gt;<br>
</span></div>
<div style=3D"font-family: Helvetica; font-size: medium; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text=
-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki=
t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; margin: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; color: rgb(127, 1=
27, 127); "><b>Subject:<span class=3D"Apple-converted-space">&nbsp;</span><=
/b></span><span style=3D"font-family: Helvetica; font-size: medium; "><b>Re=
: [mdnsext] mDNSext features/requirements rollup</b><br>
</span></div>
<div style=3D"font-family: Helvetica; font-size: medium; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text=
-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki=
t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; margin: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; color: rgb(127, 1=
27, 127); "><b>Date:<span class=3D"Apple-converted-space">&nbsp;</span></b>=
</span><span style=3D"font-family: Helvetica; font-size: medium; ">January =
28, 2013 9:34:00 AM PST<br>
</span></div>
<div style=3D"font-family: Helvetica; font-size: medium; font-style: normal=
; font-variant: normal; font-weight: normal; letter-spacing: normal; line-h=
eight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text=
-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webki=
t-text-size-adjust: auto; -webkit-text-stroke-width: 0px; margin: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; color: rgb(127, 1=
27, 127); "><b>To:<span class=3D"Apple-converted-space">&nbsp;</span></b></=
span><span style=3D"font-family: Helvetica; font-size: medium; ">&lt;<a hre=
f=3D"mailto:[email-masked]">[email-masked]</a>&gt;<br>
</span></div>
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">On
 Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote:</span><br style=
=3D"font-family: Helvetica; font-size: medium; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform=
: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-siz=
e-adjust: auto; -webkit-text-stroke-width: 0px; ">
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<blockquote type=3D"cite" style=3D"font-family: Helvetica; font-size: mediu=
m; font-style: normal; font-variant: normal; font-weight: normal; letter-sp=
acing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; t=
ext-indent: 0px; text-transform: none; white-space: normal; widows: 2; word=
-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0=
px; ">
Some of us would like to see mDNS support multiple IP subnets<br>
(e.g. multiple buildings, multiple groups, multiple (V)LANs)<br>
within a single administrative domain (e.g. university campus,<br>
corporate campus). &nbsp;<br>
<br>
&nbsp;This implies having a straight-forward way to configure<span class=3D=
"Apple-converted-space">&nbsp;</span><br>
&nbsp;networking devices (e.g. firewalls, routers) at the edge<span class=
=3D"Apple-converted-space">&nbsp;</span><br>
&nbsp;of one's administrative domain to exclude certain interfaces<span cla=
ss=3D"Apple-converted-space">&nbsp;</span><br>
&nbsp;(e.g. exterior uplink interfaces) from all mDNS traffic<span class=3D=
"Apple-converted-space">&nbsp;</span><br>
&nbsp;of the administrative domain using mDNS.<br>
</blockquote>
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">I
 still do not understand why this sort of thing isn't better handled</span>=
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">by
 vastly improved tools for real DNS management. &nbsp;It seems to me that</=
span><br style=3D"font-family: Helvetica; font-size: medium; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -w=
ebkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">people
 are asking for a single, unifed namespace outside the</span><br style=3D"f=
ont-family: Helvetica; font-size: medium; font-style: normal; font-variant:=
 normal; font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: non=
e; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adj=
ust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">link-local
 context, and we invented a mechanism for that many years</span><br style=
=3D"font-family: Helvetica; font-size: medium; font-style: normal; font-var=
iant: normal; font-weight: normal; letter-spacing: normal; line-height: nor=
mal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform=
: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-siz=
e-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">ago.
 &nbsp;The problem is that the support tools for that mechanism sort of</sp=
an><br style=3D"font-family: Helvetica; font-size: medium; font-style: norm=
al; font-variant: normal; font-weight: normal; letter-spacing: normal; line=
-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -web=
kit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">suck.
 &nbsp;Instead of inventing a new protocol which, by definition, is</span><=
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; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">going
 to run into conflicts with the existing protocols in this space,</span><br=
 style=3D"font-family: Helvetica; font-size: medium; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-tra=
nsform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-te=
xt-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">why
 wouldn't it be better to take that energy and expend it on the</span><br s=
tyle=3D"font-family: Helvetica; font-size: medium; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
 normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-trans=
form: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text=
-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">missing
 tools?</span><br style=3D"font-family: Helvetica; font-size: medium; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing=
: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">A</span><br style=3D"font-family: Helvetica; fon=
t-size: medium; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -w=
ebkit-auto; text-indent: 0px; text-transform: none; white-space: normal; wi=
dows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-st=
roke-width: 0px; ">
<br style=3D"font-family: Helvetica; font-size: medium; font-style: normal;=
 font-variant: normal; font-weight: normal; letter-spacing: normal; line-he=
ight: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-=
transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit=
-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">--<span class=3D"Apple-converted-space">&nbsp;</=
span></span><br style=3D"font-family: Helvetica; font-size: medium; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent=
: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: =
0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<span style=3D"font-family: Helvetica; font-size: medium; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; tex=
t-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webk=
it-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline =
!important; float: none; ">Andrew
 Sullivan</span><br style=3D"font-family: Helvetica; font-size: medium; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
 normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: 2; word-spaci=
ng: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">
<a href=3D"mailto:[email-masked]" style=3D"font-family: Helvetica; =
font-size: medium; font-style: normal; font-variant: normal; font-weight: n=
ormal; letter-spacing: normal; line-height: normal; orphans: 2; text-align:=
 -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal;=
 widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text=
-stroke-width: 0px; ">[email-masked]</a></blockquote>
</div>
<br>
</body>
</html>

--_000_D99048ACAF96354EBFD6A811E3C65ACD10977A7CCH1PRD0811MB407_--

Date: Tue, 29 Jan 2013 09:23:57 -0800 (PST)
From: "Dan Harkins" <[email-masked]>
To: "David Farmer" <[email-masked]>
Importance: Normal
Cc: [email-masked], Andrew Sullivan <[email-masked]>
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
> 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.

From: RJ Atkinson <[email-masked]>
Date: Tue, 29 Jan 2013 06:10:33 -0500
To: David Farmer <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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

Date: Tue, 29 Jan 2013 10:25:31 +0100
From: peter van der Stok <[email-masked]>
To: <[email-masked]>
Organization: vanderstok consultancy
Mail-Reply-To: <[email-masked]>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Reply-To: [email-masked]

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

Date: Mon, 28 Jan 2013 19:07:22 -0600
From: David Farmer <[email-masked]>
Organization: University of Minnesota
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked], David Farmer <[email-masked]>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Reply-To: David Farmer <[email-masked]>

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: [email-masked]
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
================================================

Date: Mon, 28 Jan 2013 18:23:37 -0600
From: David Farmer <[email-masked]>
Organization: University of Minnesota
To: RJ Atkinson <[email-masked]>
Cc: [email-masked], David Farmer <[email-masked]>
Subject: Re: [mdnsext] mDNSext features/requirements rollup
Reply-To: David Farmer <[email-masked]>

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: [email-masked]
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
================================================

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2013 22:47:54 +0000
To: IETF mdnsext <[email-masked]>
Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-01.txt

--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 <[email-masked]> =
wrote:

>>>>>> "Stuart" =3D=3D Stuart Cheshire <[email-masked]> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On 25 Jan 2013, at 16:28, Michael Richardson &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
wrote:</div><br><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote =
type=3D"cite"><blockquote type=3D"cite"><blockquote type=3D"cite">"Stuart"=
 =3D=3D Stuart Cheshire &lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt; =
writes:</blockquote></blockquote></blockquote></blockquote></blockquote><b=
r><blockquote type=3D"cite">Service discovery beyond the local link is =
probably the most<span class=3D"Apple-tab-span" style=3D"white-space:pre">=
	</span><br> &nbsp;&nbsp;&nbsp;&nbsp;important feature missing =
currently in the DNS-SD/mDNS framework.<br> &nbsp;&nbsp;&nbsp;&nbsp;The =
following describes some of the issues.<br></blockquote><br>I think it's =
important that we take these words in account, and maybe we<br>should =
rename the effort sto something like:<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;DNS-based site-wide service =
discovery<br><br>(DBSWSD? DSSD?... maybe someone else will come up with =
a nice IETF WG<br>acronym).<br></blockquote><div><br></div>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.</div><div><br></div><div>Should there be enough =
progress to warrant a WG, then the name can be revisited. &nbsp;That, at =
the moment, is by no means our main concern. &nbsp;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.</div><div><br><blockquote type=3D"cite">I think that we will =
make better progress is we talk more about the<br>problem, with the =
understanding that it involves extending mdns/DNS-SD,<br>but that it =
isn't just =
mDNS.<br></blockquote><div><br></div>Indeed.</div><div><br><blockquote =
type=3D"cite">I find the document is very clear, and I think that it is =
a good problem<br>statement for creation of a group. &nbsp;&nbsp;&nbsp;I =
very much appreciate that<br>non-multicast things are being =
considered.<br></blockquote><div><br></div>We have 4 weeks to work on =
the requirements text. &nbsp;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.</div><div><br></div><div>The =
actual deadline is Mon 25th Feb:</div><div><a =
href=3D"http://www.ietf.org/meeting/cutoff-dates-2013.html">http://www.iet=
f.org/meeting/cutoff-dates-2013.html</a></div><div><br></div><div>Tim</div=
><div><br></div></body></html>=

--Apple-Mail=_30DEE7CF-1FCB-4655-A747-51672ADA2A08--

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2013 22:32:29 +0000
To: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] mDNSext features/requirements rollup

On 28 Jan 2013, at 20:36, Andrew Sullivan <[email-masked]> =
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=

Date: Mon, 28 Jan 2013 17:20:55 -0500
From: Kerry Lynn <[email-masked]>
To: [email-masked]
Subject: [mdnsext] Fwd: Extensions to DNS-Based Service Discovery (mdnsext) BoF request

--bcaec54d3ef0d0112004d460b0df
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: Kerry Lynn <[email-masked]>
Date: Mon, Jan 28, 2013 at 5:14 PM
Subject: Extensions to DNS-Based Service Discovery (mdnsext) BoF request
To: Ralph Droms <[email-masked]>, Brian Haberman <[email-masked]
>

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<http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns>
 / RFC 6762 <http://tools.ietf.org/html/rfc6762> in AUTH48) and DNS-SD
(draft-cheshire-dnsext-dns-sd<http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd>
 / RFC 6763 <http://tools.ietf.org/html/rfc6763> 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

<br><div class=3D"gmail_quote">---------- Forwarded message ----------<br>F=
rom: <b class=3D"gmail_sendername">Kerry Lynn</b> <span dir=3D"ltr">&lt;<a =
href=3D"mailto:[email-masked]">[email-masked]</a>&gt;</span><br=
>Date: Mon, Jan 28, 2013 at 5:14 PM<br>
Subject: Extensions to DNS-Based Service Discovery (mdnsext) BoF request<br=
>To: Ralph Droms &lt;<a href=3D"mailto:[email-masked]">[email-masked]</=
a>&gt;, Brian Haberman &lt;<a href=3D"mailto:[email-masked]">bria=
[email-masked]</a>&gt;<br>
<br><br><div style=3D"margin:0px;font-size:12px">Greetings,<br><br>Please f=
ind enclosed a BoF=20
request for IETF86 in Orlando. This is a follow-up BoF<br>to the=20
&quot;Extensions to the Bonjour protocol suite&quot; (mdnsext) BoF held at =
IETF85,
 and<br>thus we appreciate is the second and final chance to form a WG in=
=20
this space.<br>(Thanks to Tim Chown for preparing this.)<br></div><div styl=
e=3D"margin:0px;font-size:12px;min-height:14px"><br>We need to see discussi=
on on the list regarding the proposed charter below.=A0 Also,<br>with input=
 from Marc Blanchet, Matthew Gast, and others we have begun to<br>

reorganize the requirements draft around use cases.=A0 See:<br>draft <a hre=
f=3D"https://datatracker.ietf.org/doc/draft-lynn-mdnsext-requirements/" tar=
get=3D"_blank">https://datatracker.ietf.org/doc/draft-lynn-mdnsext-requirem=
ents/</a><br>

I will be prompting a discussion of mdnsext security considerations on the =
list so<br>
we can include more ideas in future versions of the requirements draft.<br>=
<br>Note that there was some discussion of changing the BoF name after the =
first one.<br>We compromised by keeping the same short name (mdnsext) but c=
hanging the<br>

long name to avoid the impression that our scope is too narrowly focused.=
=A0 It&#39;s<br>something we can discuss on the list and revisit before the=
 WG is (hopefully)<br>established.<br><br>Regards, -K-<br><br><br>---------=
-<br>

</div><div style=3D"margin:0px;font-size:12px">BoF scheduling information:<=
/div><div style=3D"margin:0px;font-size:12px;min-height:14px">
<br></div><div style=3D"margin:0px;font-size:12px">

a. Extensions to DNS-Based Service Discovery (mdnsext)</div><div style=3D"m=
argin:0px;font-size:12px;min-height:14px"><br></div><div style=3D"margin:0p=
x;font-size:12px">b. Internet Area</div><div style=3D"margin:0px;font-size:=
12px;min-height:14px">

<br>

</div>
<div style=3D"margin:0px;font-size:12px">c. Conflicts: 6man homenet dhc app=
area appsawg intarea sdnrg v6ops dnsop and dnsext</div><div style=3D"margin=
:0px;font-size:12px;min-height:14px"><br></div><div style=3D"margin:0px;fon=
t-size:12px">

d. Expected Attendance: 200 (at least 164 attended at IETF85)</div>

<div style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div sty=
le=3D"margin:0px;font-size:12px">e. Special requests: None</div><div style=
=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div style=3D"marg=
in:0px;font-size:12px">

f. Number of sessions: 1</div><div style=3D"margin:0px;font-size:12px;min-h=
eight:14px"><br></div><div style=3D"margin:0px;font-size:12px">g. Length of=
 session: 2 hours=A0</div><div style=3D"margin:0px;font-size:12px;min-heigh=
t:14px">

<br></div><div style=3D"margin:0px;font-size:12px;min-height:14px"><br></di=
v><div style=3D"margin:0px;font-size:12px">Draft agenda:</div><div style=3D=
"margin:0px;font-size:12px">--------------------</div><div style=3D"margin:=
0px;font-size:12px;min-height:14px">

<br></div><div style=3D"margin:0px;font-size:12px">1. Administravia (Chairs=
, 5 mins)=A0 =A0</div><div style=3D"margin:0px;font-size:12px">=A0 =A0 Note=
 Well and agenda bashing</div><div style=3D"margin:0px;font-size:12px;min-h=
eight:14px">

<br></div><div style=3D"margin:0px;font-size:12px">2. Goals of the BoF (Cha=
irs, 15 mins)</div><div style=3D"margin:0px;font-size:12px">=A0 =A0 Review =
of IETF 85 mdsnext BoF and progress since</div><div style=3D"margin:0px;fon=
t-size:12px;min-height:14px">

<br></div><div style=3D"margin:0px;font-size:12px">3. Requirements (Kerry L=
ynn, 30 mins)</div><div style=3D"margin:0px;font-size:12px">=A0 =A0 draft-l=
ynn-mdnsext-requirements-01</div><div style=3D"margin:0px;font-size:12px;mi=
n-height:14px">

<br></div><div style=3D"margin:0px;font-size:12px">4. Open discussion (Chai=
rs, 40 mins)</div><div style=3D"margin:0px;font-size:12px">=A0 =A0 Open mic=
; includes draft charter and deliverables</div><p style=3D"margin:0px;font-=
size:12px;min-height:14px">

=A0=A0<br></p><div style=3D"margin:0px;font-size:12px">5. Key questions (Ch=
airs, 30 mins)</div><div style=3D"margin:0px;font-size:12px">=A0 =A0 Are we=
 ready to form a WG with the agreed charter, subject to mail list confirmat=
ion?=A0</div>

<div style=3D"margin:0px;font-size:12px">=A0 =A0 Note RFC5434 section 1.</d=
iv><div style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div =
style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div style=3D=
"margin:0px;font-size:12px">

Draft charter:</div><div style=3D"margin:0px;font-size:12px">--------------=
-----</div><div style=3D"margin:0px;font-size:12px;min-height:14px"><br></d=
iv><div style=3D"margin:0px;font-size:12px">Currently,
 zeroconf networking protocols are generally used to discover services=20
within<br>the scope of a single link.=A0In particular, the Bonjour protocol=
s=20
suite, comprising mDNS<br>(<a href=3D"http://tools.ietf.org/html/draft-ches=
hire-dnsext-multicastdns" target=3D"_blank">draft-cheshire-dnsext-multicast=
dns</a>=A0/=A0<a href=3D"http://tools.ietf.org/html/rfc6762" target=3D"_bla=
nk">RFC 6762</a>=A0in AUTH48) and DNS-SD<br>

(<a href=3D"http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd" target=
=3D"_blank">draft-cheshire-dnsext-dns-sd</a>=A0/=A0<a href=3D"http://tools.=
ietf.org/html/rfc6763" target=3D"_blank">RFC 6763</a>=A0in AUTH48), are wid=
ely used for discovery and<br>

resolution of services and names on a single link.=A0</div>
<div style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div sty=
le=3D"margin:0px;font-size:12px">Such
 discovery is commonly used in many scenarios, including home networks,<br>=
commercial and campus enterprise networks, and can be used in certain=20
mesh networks.<br>However, the multicast zeroconf protocols are constrained
 to link-local scope, so can<br>only be used to discover services on the=20
same link. In a typical current home network,<br>which is a single link,=20
users should experience the desired discovery behaviour. However,<br>in=20
future multi-link home networks (as envisaged by the homenet WG) and in=20
routed<br>campus or enterprise networks, devices and thus users can only=20
discover services on the<br>same link, which is a significant limitation.=
=20
Such limitations have led to calls, such as those<br>by the Educause=20
petition, to develop an appropriate solution to span multiple links, or=20
to<br>perform discovery across a wide area (not necessarily on directly=20
connected links).</div><div style=3D"margin:0px;font-size:12px;min-height:1=
4px"><br></div><div style=3D"margin:0px;font-size:12px">In
 addition, the Zigbee Smart Energy Profile 2.0=A0commercial standard=20
currently under<br>development has specified mDNS as its method of zero=20
configuration discovery. However,<br>its use of multi-link wireless mesh=20
subnets (LLNs) and disparate physical layers will require<br>extensions to=
=20
mDNS to allow it to operate across multiple links.</div><div style=3D"margi=
n:0px;font-size:12px;min-height:14px"><br></div><div style=3D"margin:0px;fo=
nt-size:12px">In
 principle DNS-SD can be used with conventional unicast DNS for wide=20
area service<br>discovery spanning multiple links,=A0but in practice this=
=20
capability is not widely used<br>(potentially due to user=20
interface/configuration issues, but potentially due to protocol<br>limitati=
ons). As a result, as demand for service discovery across wider=20
area routed<br>networks grows, some vendors are beginning to ship their own
 early solutions. It is thus<br>both timely and important that efforts to=
=20
develop improved, scalable service discovery<br>solutions for routed=20
networks are coordinated towards producing a single, standards-<br>based=20
solution.</div><div style=3D"margin:0px;font-size:12px;min-height:14px"><br=
></div><div style=3D"margin:0px;font-size:12px">Goals</div><div style=3D"ma=
rgin:0px;font-size:12px;min-height:14px"><br></div><div style=3D"margin:0px=
;font-size:12px">

To that end, the primary goals of the mdnsext WG are as follows:</div><div =
style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div style=3D=
"margin:0px;font-size:12px">1.
 To document a set of requirements for wider area service discovery in=20
routed,<br>=A0=A0=A0 multi-link networks in the following four scenarios:</=
div><div style=3D"margin:0px;font-size:12px">=A0 =A0 a) Commercial enterpri=
se networks</div><div style=3D"margin:0px;font-size:12px">=A0 =A0 b) Academ=
ic/educational/university campus networks</div>

<div style=3D"margin:0px;font-size:12px">=A0 =A0 c) Multi-link home network=
s, such as those envisaged by the HOMENET WG</div><div style=3D"margin:0px;=
font-size:12px">=A0 =A0 d) Multi-link/single subnet (mesh) networks, such a=
s ROLL/6LOWPAN subnets</div>

<div style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div sty=
le=3D"margin:0px;font-size:12px">2.
 To develop an improved, scalable solution for wide-area service=20
discovery that can<br>=A0=A0=A0=A0 operate in multi-link networks, applicab=
le to the=20
scenarios above.=A0</div><div style=3D"margin:0px;font-size:12px;min-height=
:14px"><br></div><div style=3D"margin:0px;font-size:12px">3.
 To develop a BCP for the coexistence of zeroconf (mDNS) and unicast=20
(global DNS)<br>=A0=A0=A0=A0 name services in such multi-link networks, whi=
ch should=20
include consideration of both<br>=A0=A0=A0=A0 the name resolution mechanism=
 and the=20
namespace.</div><div style=3D"margin:0px;font-size:12px;min-height:14px"><b=
r></div><div style=3D"margin:0px;font-size:12px">It
 is important that the mdnsext WG takes input from stakeholders in the=20
scenarios it is<br>considering. For example, the=A0homenet WG is currently=
=20
evaluating its own requirements<br>for naming and service discovery; it is=
=20
up to the homenet WG as to whether it wishes to<br>recommend adoption of=20
the solution developed in the mdsnext WG, and thus coordination<br>between=
=20
the WGs is desirable.=A0</div><div style=3D"margin:0px;font-size:12px;min-h=
eight:14px"><br></div><div style=3D"margin:0px;font-size:12px">Deliverables=
</div><div style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><d=
iv style=3D"margin:0px;font-size:12px">

The
 WG will produce three documents: an Informational RFC on the=20
requirements for<br>wide-area service discovery protocols; a Standards=20
Track RFC documenting a wide-area<br>service discovery solution that is=20
applicable to those scenarios; and a BCP document<br>describing the most=20
effective method to integrate mDNS and global DNS name services.</div><div =
style=3D"margin:0px;font-size:12px;min-height:14px"><br></div><div style=3D=
"margin:0px;font-size:12px">Milestones</div><div style=3D"margin:0px;font-s=
ize:12px;min-height:14px">

<br></div><div style=3D"margin:0px;font-size:12px">May 2013 Formation of th=
e WG</div><div style=3D"margin:0px;font-size:12px">Apr 2013 Adopt requireme=
nts draft as WG document</div><div style=3D"margin:0px;font-size:12px">Aug =
2013 Submit requirements draft to the IESG as an Informational RFC</div>

<div style=3D"margin:0px;font-size:12px">Sep 2013 Adopt wide-area service d=
iscovery solution draft as WG document</div><div style=3D"margin:0px;font-s=
ize:12px">Oct 2013 Adopt zeroconf and unicast DNS integration BCP draft as =
WG document</div>

<div style=3D"margin:0px;font-size:12px">Mar 2014 Submit wide-area service =
discovery solution draft to the IESG as Standards Track RFC</div><div style=
=3D"margin:0px;font-size:12px">Mar 2014 Submit zeroconf and unicast DNS int=
egration solution draft to the IESG as BCP</div>

</div><br>

--bcaec54d3ef0d0112004d460b0df--

Date: Mon, 28 Jan 2013 15:36:04 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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
[email-masked]

Date: Mon, 28 Jan 2013 14:52:51 -0500
From: Brian Dickson <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

--e89a8f83ab13541d7f04d45e9f2f
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 28, 2013 at 12:34 PM, Andrew Sullivan <[email-masked]>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
> [email-masked]
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

--e89a8f83ab13541d7f04d45e9f2f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Mon, Jan 28, 2013 at 12:34 PM, Andrew=
 Sullivan <span dir=3D"ltr">&lt;<a href=3D"mailto:[email-masked]" t=
arget=3D"_blank">[email-masked]</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div class=3D"im">On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wro=
te:<br>
<br>
&gt; Some of us would like to see mDNS support multiple IP subnets<br>
&gt; (e.g. multiple buildings, multiple groups, multiple (V)LANs)<br>
&gt; within a single administrative domain (e.g. university campus,<br>
&gt; corporate campus).<br>
&gt;<br>
&gt; =A0 This implies having a straight-forward way to configure<br>
&gt; =A0 networking devices (e.g. firewalls, routers) at the edge<br>
&gt; =A0 of one&#39;s administrative domain to exclude certain interfaces<b=
r>
&gt; =A0 (e.g. exterior uplink interfaces) from all mDNS traffic<br>
&gt; =A0 of the administrative domain using mDNS.<br>
<br>
</div>I still do not understand why this sort of thing isn&#39;t better han=
dled<br>
by vastly improved tools for real DNS management.</blockquote><div><br></di=
v><div>I think one of the fundamental problems is, that by merely existing,=
</div><div>mDNS has created two namespaces, where the link-local (yes/no)</=
div>
<div>is the only identifying attribute for which namespace applies.</div><d=
iv><br></div><div>Also, creating/improving tools, in general, has certain r=
isks, unless</div><div>improving things from implict -&gt; explicit (mDNS v=
s DNS namespace) is done first.</div>
<div><br></div><div>The risks I see (in exclusively working on tools) are:<=
/div><div>- open/standardized tools vs proprietary</div><div>- scope creep<=
/div><div>- scaling problems (in terms of development resources)</div><div>
- work done by those who do not fully understand DNS protocols</div><div>- =
work done by those who do not fully understand DNS namespaces</div><div>- w=
ork done by idiots</div><div>- work supported by vendors who have history o=
f horrible implementations</div>
<div>- tools in one space breaking things in another space (creating a Hobs=
ons&#39; choice for users)</div><div>- users</div><div>- firmware</div><div=
>- longevity of deployed hardware/firmware/software</div><div><br></div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">=A0It seems to me that<br>
people are asking for a single, unifed namespace outside the<br>
link-local context, and we invented a mechanism for that many years<br>
ago. =A0The problem is that the support tools for that mechanism sort of<br=
>
suck. =A0Instead of inventing a new protocol which, by definition, is<br>
going to run into conflicts with the existing protocols in this space,<br>
why wouldn&#39;t it be better to take that energy and expend it on the<br>
missing tools?<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></s=
pan></blockquote><div><br></div><div>Just to be clear, which mechanism is t=
hat to which you refer?</div><div><br></div><div>Brian</div><div>=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888">
<br>
--<br>
Andrew Sullivan<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
mdnsext mailing list<br>
<a href=3D"mailto:[email-masked]">[email-masked]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/mdnsext" target=3D"_blank"=
>https://www.ietf.org/mailman/listinfo/mdnsext</a><br>
</div></div></blockquote></div><br>

--e89a8f83ab13541d7f04d45e9f2f--

Date: Mon, 28 Jan 2013 12:54:29 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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
[email-masked]

From: nudge <[email-masked]>
To: [email-masked]
Date: Mon, 28 Jan 2013 18:38:36 +0100
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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 ?

Date: Mon, 28 Jan 2013 12:34:00 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

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
[email-masked]

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2013 11:51:02 -0500
To: [email-masked]
Subject: [mdnsext]  mDNSext features/requirements rollup

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.

From: RJ Atkinson <[email-masked]>
Date: Mon, 28 Jan 2013 11:39:48 -0500
To: [email-masked]
Subject: [mdnsext]  mDNSext features/requirements rollup

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

From: Stuart Cheshire <[email-masked]>
Date: Sat, 26 Jan 2013 22:46:23 -0800
To: IETF mdnsext <[email-masked]>
Subject: [mdnsext] draft-cheshire-mdnsext-hybrid-01

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:

<http://www.ietf.org/id/draft-cheshire-mdnsext-hybrid-01.txt>

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

From: Michael Richardson <[email-masked]>
To: IETF mdnsext <[email-masked]>
Date: Fri, 25 Jan 2013 11:28:20 -0500
Sender: [email-masked]
Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-01.txt

--=-=-=
Content-Transfer-Encoding: quoted-printable

>>>>> "Stuart" =3D=3D Stuart Cheshire <[email-masked]> writes:
    Stuart> We just submitted draft-lynn-mdnsext-requirements-01.txt

    Stuart> <http://www.ietf.org/id/draft-lynn-mdnsext-requirements-01.txt>

    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 <[email-masked]>, Sandelman Software Works=20

--=-=-=
Content-Type: application/pgp-signature

--=-=-=--

From: Stuart Cheshire <[email-masked]>
Date: Fri, 25 Jan 2013 22:04:11 -0800
To: IETF mdnsext <[email-masked]>
Subject: [mdnsext] draft-cheshire-mdnsext-hybrid-00

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

From: Stuart Cheshire <[email-masked]>
Date: Thu, 24 Jan 2013 21:41:43 -0800
To: IETF mdnsext <[email-masked]>
Subject: [mdnsext] draft-lynn-mdnsext-requirements-01.txt

We just submitted draft-lynn-mdnsext-requirements-01.txt

<http://www.ietf.org/id/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

From: Alf Watt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 23 Jan 2013 20:18:16 +0000
Accept-Language: en-US
Subject: [mdnsext] mDNSext features/requirements rollup

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=

Date: Mon, 21 Jan 2013 14:28:51 +0100
From: peter van der Stok <[email-masked]>
To: <[email-masked]>
Organization: vanderstok consultancy
Mail-Reply-To: <[email-masked]>
Subject: Re: [mdnsext] =?utf-8?q?mDNSext_BoF_at_IETF_86=3F?=
Reply-To: [email-masked]

+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" <[email-masked]> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
To: Alf Watt <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 16 Jan 2013 16:13:10 +0000
Accept-Language: en-US
Cc: Stuart Cheshire <[email-masked]>
Subject: Re: [mdnsext] mDNSext BoF at IETF 86?

+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" <[email-masked]> 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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: Tim Chown <[email-masked]>
Date: Mon, 14 Jan 2013 14:26:16 +0000
To: "Brzozowski, John" <[email-masked]>
Cc: Stuart Cheshire <[email-masked]>, "[email-masked]" <[email-masked]>, Alf Watt <[email-masked]>
Subject: Re: [mdnsext] mDNSext BoF at IETF 86?

On 9 Jan 2013, at 02:35, "Brzozowski, John" =
<[email-masked]> 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=

From: "Brzozowski, John" <[email-masked]>
To: Alf Watt <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 9 Jan 2013 02:35:30 +0000
Accept-Language: en-US
Cc: Stuart Cheshire <[email-masked]>
Subject: Re: [mdnsext] mDNSext BoF at IETF 86?

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:[email-masked]
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 <[email-masked]>
Date: Monday, January 7, 2013 1:38 PM
To: "[email-masked]" <[email-masked]>
Cc: Stuart Cheshire <[email-masked]>
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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: Alf Watt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Mon, 7 Jan 2013 18:38:17 +0000
Accept-Language: en-US
Cc: Stuart Cheshire <[email-masked]>
Subject: [mdnsext] mDNSext BoF at IETF 86?

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=