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

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 31 Jul 2013 02:57:27 -0700

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"?

- 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 guess the constraint on the number of networks has to do
   with trying to limit the traffic load from multicast packets.
   Is multicast assumed?

-- 
Regards,
Charlie P.

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 31 Jul 2013 11:41:32 -0400

Hi Charlie,

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

On Wed, Jul 31, 2013 at 5:57 AM, Charles E. Perkins
<[email-masked]>wrote:

> 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.

> 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.

> 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
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mdnsext<https://www.ietf.org/mailman/listinfo/mdnsext>
>