1 / 6

mdnsext requirements

mdnsext requirements. draft-lynn-mdnsext-requirements. Kerry Lynn <kerlyn@ieee.org> Stuart Cheshire <cheshire@apple.com> 06 November 2012. mdnsext requirements. Scalable. Usable. Deployable. Scalable. Enable DNS-based Service Discovery across lots of links (LoL )

cirila
Télécharger la présentation

mdnsext requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. mdnsext requirements draft-lynn-mdnsext-requirements Kerry Lynn <kerlyn@ieee.org> Stuart Cheshire <cheshire@apple.com> 06 November 2012

  2. mdnsext requirements Scalable Usable Deployable

  3. Scalable • Enable DNS-based Service Discovery across lots of links (LoL) • Suitable for both local (zero-config) and global (little-config) use • Scalablility in terms of: • Network traffic • CPU and memory requirements on network entities • Architecture • Common terminology/concepts (e.g. many subnets may “map” to a link, many links may “map” to a subnet) • Granularity of services available on a server (extend the traditional notion of service?)

  4. Usable • Zero configuration operation possible but not mandatory. Zero-config is supported by the protocols, but administrative control is also available on networks or in situations where that is desirable (e.g. user opts-in for service to be publicly visible) • A smooth continuum of operation and experience from local link to site to global, rather than wildly different incompatible modes of operation at different network scales • User interface (huge flat list is not user friendly)

  5. Deployable • Incremental deployability (e.g. "islands" of infrastructure-less functionality can be merged) • Identify what changes to existing network elements will be required, and attempt to minimize those changes(e.g. may be easier to revise the clients) • Suitable out-of-the box defaults should enable zero-config use on many small- to medium-sized networks, while still allowing for administrative control in networks where that's appropriate

  6. Secure • Authorization versus authentication (e.g. which services are authorized to advertise?) • Avoid manual config of every service entry in a directory

More Related