Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

[Tim Chown <[e-mail]>]

Hi,

Ralph and I will take further comments to the list in advance of the dnssd meeting on Monday.

Comments of the form ‘this is ready to ship’ are also very useful.

Tim


> On 17 Mar 2016, at 22:36, Tim Chown <[e-mail]> wrote:
> 
> Dear dnssd WG participants,
> 
> We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03>.
> 
> The call runs for two weeks, and will thus close on Thursday 31st March.
> 
> Please send any comments (including indications of support for progression of the document as is) to the [e-mail] <mailto:[e-mail]> list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. We are aware of a small number of minor outstanding comments from the list, but will consider these as part of the WGLC process.
> 
> We will discuss the comments arising from the WGLC in the WG meeting in BA on Monday 4th April.
> 
> Abstract
> 
>    Performing DNS-Based Service Discovery using purely link-local
>    Multicast DNS enables discovery of services that are on the local
>    link, but not (without some kind of proxy or similar special support)
>    discovery of services that are outside the local link.  Using a very
>    large local link with thousands of hosts facilitates service
>    discovery, but at the cost of large amounts of multicast traffic.
> 
>    Performing DNS-Based Service Discovery using purely Unicast DNS is
>    more efficient and doesn't require excessively large multicast
>    domains, but requires that the relevant data be available in the
>    Unicast DNS namespace.  This can be achieved by manual DNS
>    configuration (as has been done for many years at IETF meetings to
>    advertise the IETF Terminal Room printer) but this is labor
>    intensive, error prone, and requires a reasonable degree of DNS
>    expertise.  The Unicast DNS namespace can be populated with the
>    required data automatically by the devices themselves, but that
>    requires configuration of DNS Update keys on the devices offering the
>    services, which has proven onerous and impractical for simple devices
>    like printers and network cameras.
> 
>    Hence, to facilitate efficient and reliable DNS-Based Service
>    Discovery, a compromise is needed that combines the ease-of-use of
>    Multicast DNS with the efficiency and scalability of Unicast DNS.
> 
> 
> Thanks,
> 
> Ralph and Tim
> dnssd WG co-chairs
> 
> 
> 
>