[Ietf-lac] Fwd: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
Carlos M. Martinez
carlos at lacnic.net
Thu Oct 3 13:38:16 BRT 2013
Cierto. Creo que igual no hay que dejar que las IPRs se pongan en el
medio de cosas que son utiles. En todo caso, habra que buscarles la vuelta.
De todas maneras ese capaz que es un comentario interesante para hacer
al IESG.
On 10/3/13 1:18 PM, Fernando Gont wrote:
> Carlos,
>
> El topico, como algo tecnico, es interesante.
>
> Tal vez la cuestión asm controversial es que, por lo que han mencionado,
> mDNS/DNS-SD tiene IPRs desparramadas por todos lados...
>
> En tal sentido, y asumiendo que eso efectivamente es asi, creo que sería
> poco feliz si el trabajo en este area terminara siendo algo montado
> sobre esos protocolos IPR-encumbered.
>
> Lo bueno es que, al menos en teoría, el tema estará sujeto a debate
> (aunque el "highly desirable..." es medio condicionante).
>
> P.S.: Si se me pasó algo por alto, chiflen.
>
> Fernando
>
>
>
>
> On 10/03/2013 01:08 PM, Carlos M. Martinez wrote:
>> Hola!
>>
>> Se ha propuesto un nuevo grupo de trabajo. Para ello esta abierto hasta
>> el 10/10 un periodo de comentarios.
>>
>> Lo comparto por ser un tema que personalmente me resulta muy interesante.
>>
>> s2
>>
>> ~Carlos
>>
>>
>> -------- Original Message --------
>> Subject: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
>> Date: Thu, 03 Oct 2013 08:42:54 -0700
>> From: The IESG <iesg-secretary at ietf.org>
>> Reply-To: ietf at ietf.org
>> To: IETF-Announce <ietf-announce at ietf.org>
>> CC: dnssd WG <dnssdext at ietf.org>
>>
>> A new IETF working group has been proposed in the Internet Area. The IESG
>> has not made any determination yet. The following draft charter was
>> submitted, and is provided for informational purposes only. Please send
>> your comments to the IESG mailing list (iesg at ietf.org) by 2013-10-10.
>>
>> Extensions for Scalable DNS Service Discovery (dnssd)
>> ------------------------------------------------
>> Current Status: Proposed WG
>>
>> Chairs:
>> Ralph Droms <rdroms.ietf at gmail.com>
>> Tim Chown <tjc at ecs.soton.ac.uk>
>>
>> Assigned Area Director:
>> Ted Lemon <ted.lemon at nominum.com>
>>
>> Mailing list
>> Address: dnssdext at ietf.org
>> To Subscribe: dnssdext-request at ietf.org
>> Archive: http://www.ietf.org/mail-archive/web/dnssdext
>>
>> Charter:
>>
>> Background
>> ----------
>>
>> Zero configuration networking protocols are currently well suited to
>> discover services within the scope of a single link. In particular,
>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
>> referred to using Apple Computer Inc.'s trademark, Bonjour) are
>> widely used for DNS-based service discovery and host name resolution
>> on a single link.
>>
>> The DNS-SD/mDNS protocol suite is used in many scenarios including
>> home, campus, and enterprise networks. However, the zero configuration
>> mDNS protocol is constrained to link-local multicast scope by design,
>> and therefore cannot be used to discover services on remote links.
>>
>> In a home network that consists of a single (possibly bridged) link,
>> users experience the expected discovery behavior; available services
>> appear because all devices share a common link. However, in multi-link
>> home networks (as envisaged by the homenet WG) or in routed campus or
>> enterprise networks, devices and users can only discover services on
>> the same link, which is a significant limitation. This has led to
>> calls, such as the Educause petition, to develop an appropriate service
>> discovery solution to span multiple links or to perform discovery across
>> a wide area, not necessarily on directly connected links.
>>
>> In addition, the "Smart Energy Profile 2 Application Protocol Standard",
>> published by ZigBee Alliance and HomePlug Powerline Alliance specifies
>> the DNS-SD/mDNS protocol suite as the basis for its method of zero
>> configuration service discovery. However, its use of wireless mesh
>> multi-link subnets in conjunction with traditional routed networks will
>> require extensions to the DNS-SD/mDNS protocols to allow operation
>> across multiple links.
>>
>> The scenarios in which multi-link service discovery is required may
>> be zero configuration environments, environments where administrative
>> configuration is supported, or a mixture of the two.
>>
>> As demand for service discovery across wider area routed networks
>> grows, some vendors are beginning to ship proprietary solutions. It
>> is thus both timely and important that efforts to develop improved,
>> scalable, autonomous service discovery solutions for routed networks
>> are coordinated towards producing a single, standards-based solution.
>>
>> The WG will consider the tradeoffs between reusing/extending existing
>> protocols and developing entirely new ones. It is highly desirable
>> that any new solution is backwardly compatible with existing DNS-SD/mDNS
>> deployments. Any solution developed by the dnssd WG must not conflict
>> or interfere with the operation of other zero-configuration service and
>> naming protocols such as uPnP or LLMNR. Integration with such protocols
>> is out of scope for this WG.
>>
>> The focus of the WG is to develop a solution for extended, scalable
>> DNS-SD. This work is likely to highlight problems and challenges with
>> naming protocols, as some level of coexistence will be required between
>> local zero configuration name services and those forming part of the
>> global DNS. It is important that these issues are captured and
>> documented for further analysis; solving those problems is however not
>> within the scope of this WG.
>>
>> Working Group Description
>> -------------------------
>>
>> To that end, the primary goals of the dnssd WG are as follows:
>>
>> 1. To document a set of requirements for scalable, autonomous
>> DNS-based service discovery in routed, multi-link networks in the
>> following five scenarios:
>>
>> (A) Personal Area networks, e.g., one laptop and one printer.
>> This is the simplest example of a service discovery network,
>> and may or may not have external connectivity.
>>
>> (B) Home networks, as envisaged by the homenet WG, consisting of
>> one or more exit routers, with one or more upstream providers
>> or networks, and an arbitrary internal topology with
>> heterogeneous media where routing is automatically configured.
>> The home network would typically be a single zero configuration
>> administrative domain with a relatively limited number of
>> devices.
>>
>> (C) Wireless 'hotspot' networks, which may include wireless networks
>> made available in public places, or temporary or permanent
>> infrastructures targeted towards meeting or conference style
>> events, e.g., as provided for IETF meetings. In such
>> environments other devices may be more likely to be 'hostile'
>> to the user.
>>
>> (D) Enterprise networks, consisting of larger routed networks,
>> with large numbers of devices, which may be deployments
>> spanning over multiple sites with multiple upstreams, and
>> one more more administrative domains (depending on internal
>> administrative delegation). The large majority of the
>> forwarding and security devices are configured. These may
>> be commercial or academic networks, with differing levels
>> of administrative control over certain devices on the network,
>> and BYOD devices commonplace in the campus scenario.
>>
>> (E) Mesh networks such as RPL/6LoWPAN, with one or more links per
>> routable prefix, which may or may not have external connectivity.
>> The topology may use technologies including 802.11 wireless,
>> HomePlug AV and GP, and ZigBee IP.
>>
>> In the above scenarios, the aim is to facilitate service discovery
>> across the defined site. It is also desirable that a user or device,
>> when away from such a site, is still able to discover services
>> within that site, e.g. a user discovering services in their home
>> network while remote from it.
>>
>> It is also desirable that multiple discovery scopes are supported,
>> from the point of view of announcements and discovery, be the
>> scope 'site', 'building', or 'room'. A user for example may only
>> be interested in devices in the same room.
>>
>> 2. To develop an improved, scalable solution for service discovery
>> that can operate in multi-link networks, where devices may be
>> in neighboring or non-neighboring links, applicable to
>> the scenarios above. The solution will consider tradeoffs between
>> reusing/extending existing protocols and developing entirely new
>> protocols.
>>
>> The solution should include documentation or definition of the
>> interfaces that can be implemented, separately to transport of
>> the information.
>>
>> 3. To document challenges and problems encountered in the coexistence
>> of zero configuration and global DNS name services in such
>> multi-link networks, including consideration of both the name
>> resolution mechanism and the namespace.
>>
>> It is important that the dnssd 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 dnssd WG, but
>> coordination between the WGs is desirable.
>>
>> Deliverables:
>>
>> The WG will produce three documents: an Informational RFC on the
>> requirements for service discovery protocols operating on potentially
>> non-neighboring multi-link networks as described above; a Standards
>> Track RFC documenting an extended, scalable service discovery solution
>> that is applicable to those scenarios; and an Informational RFC
>> describing the problems arising when developing the extended SD solution
>> and how it affects the integration of local zero configuration and global
>>
>> DNS name services.
>>
>> Milestones:
>> Sep 2013 - Formation of the WG
>> Oct 2013 - Adopt requirements draft as WG document
>> Jan 2014 - Submit requirements draft to the IESG as an Informational
>> RFC
>> Mar 2014 - Adopt wide-area service discovery solution draft as WG
>> document
>> Mar 2014 - Adopt Informational document on the problems and challenges
>> arising for zeroconf and unicast DNS name services
>> Sep 2014 - Submit wide-area service discovery solution draft to the
>> IESG as Standards Track RFC
>> Sep 2014 - Submit the zeroconf and unicast DNS "problems and
>> challenges" draft to the IESG as Informational.
>>
>>
>>
>>
>> _____________________________________________
>> Ietf-lac mailing list
>> Ietf-lac at lacnog.org
>> Cancelar suscripcion: ietf-lac-unsubscribe at lacnog.org
>>
>>
>
More information about the Ietf-lac
mailing list