Subject: [mdnsext] mDNSext features/requirements rollup

From: Alf Watt <[email-masked]>
Date: Wed, 23 Jan 2013 20:18:16 +0000

I've worked back through the mail log and assembled all the common features and requirements that I could identify, there's likely some personal bias in this list as I have preferences on how to implement some of these, but hopefully 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, briefly:
		Bonjour packets are proxied between two multicast domains, optionally with 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 instead of registration by clients
	- resolve namespace collision issues (each multicast domain may need a separate .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 possible to unicast 
	- use multicast to discover the local proxy (or lack thereof) and switch to 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 mechanism (see above)
	- this 'breaks' some features but is better than complete suppression which 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, whether it is an original or proxy advertisement"

I'm sure I missed a few, please feel free to fill in the list.

Best,
Alf

---

From: peter van der Stok <[email-masked]>
Date: Tue, 29 Jan 2013 10:25:31 +0100

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