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/proxying of DNS-SD advertisements between L3 segments would be a fundamental use case.

How the information gets displayed, searching etc would be left up to the client GUI.

Stephen

-----Original Message-----
From: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] On Behalf Of Dan Harkins
Sent: Tuesday, January 29, 2013 12:24 PM
To: David Farmer
Cc: mdnsext@ietf.org; Andrew Sullivan
Subject: Re: [mdnsext] mDNSext features/requirements rollup

  Hello,

On Mon, January 28, 2013 5:07 pm, David Farmer wrote:
>
> So you hear a bunch of us pushing to solve this with network hacks, or 
> 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.

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