Re: [mdnsext] A few questions from a new participant

Hi Charlie,

I'll take a stab at answering your questions below...

On Wed, Jul 31, 2013 at 5:57 AM, Charles E. Perkins
<charliep@computer.org>wrote:

> Hello folks,
>
> I've just joined the mailing list, so my questions may already have been
> answered...
>
> - Why use the terminology "wide-area"?  It usually means a large
>   area, much more than even the (small?) enterprise scenario under
>   discussion.  What about re-using the terminology "site"?
>
> Let's begin with the distinction between DNS-SD (DNS-Based Service
Discovery [RFC6763]) and mDNS (Multicast DNS [RFC6762]).  DNS-SD
is a conventional use of existing DNS RRs (SRV, TXT, PTR, A/AAAA) for
the purpose of discovering services (which are roughly akin to service
access points).  The use of "wide-area" usually applies to DNS-SD, which
can be deployed in any DNS zone in the Internet and is accessed using
standard DNS.  (However, Andrew Sullivan and others have pointed out
that DNS labels must be LDH or IDNA-encoded, while DNS-SD permits
arbitrary NFC UTF-8.  That was the discussion around point 3 of the
charter.)

mDNS can be thought of as an optimized transport for DNS-SD, but it
is really more than that.  Unlike DNS, it will return *all* the relevant RRs
for a particular query and operates over local links using link-local mcast
and distributed responders.

- Is it assumed that only a low volume of service discovery operations
>   will be initiated (per unit time)?  This "builds on" the zeroconf /
>   single link case, but might be important to state explicitly.
>
> I have to go back and read the requirements draft, but a figure of merit
is that the total percentage of bandwidth used for discovery on a given
link should remain constant (or decrease) as the system scales across
the use cases.

- I guess the constraint on the number of networks has to do
>   with trying to limit the traffic load from multicast packets.
>   Is multicast assumed?
>
> It will probably be part of the eventual solution (especially as we have
the requirement not to break current functionality) but I expect it will be
relied upon to a lesser extent (or not at all) for off-link queries.

HTH, -K-

> --
> Regards,
> Charlie P.
>
> ______________________________**_________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>