RE: mdns-08 draft

["Levon Esibov" <levone@windows.microsoft.com>]

> -----Original Message-----
> From: Erik Guttman [mailto:erik.guttman@sun.com]
> Sent: Thursday, December 20, 2001 10:15 AM
> To: aboba@internaut.com
> Cc: cheshire@apple.com; erik.guttman@sun.com; Levon Esibov; Dave Thaler;
> sra@hactrn.net; namedroppers@ops.ietf.org
> Subject: re: mdns-08 draft
>
> Bernard,
>
> This document is moving in the right direction.  A few comments.
>
> ---
>
> Please change the title of the draft to
>
>   Link-local Multicast DNS
>
> In the future, we may define Multicast DNS to be something grander.
>
> ---
>
>   For the purpose of this document a host that sends a multicast query is
>   called a "sender", while a host that listens to (but not necessarily
>   responds to) a multicast query is called "responder". A host configured
>   to be a "responder" may also be a "sender". A host configured to not be
>   a "responder" cannot be a "sender".
>
> Why?  This is an arbitrary rule.  I can imagine a very simple client
> that might not need a responder.  Every feature costs.
>
[Levon Esibov] I have no objections.
> ---
>
>   If the multicast query is not positively resolved ("positively resolved"
>   refers in this document to a response with the RCODE set to 0) during a
>   limited amount of time,
>
> Non-positively resolved multicast queries won't get replies.  This is
> stated later
>
>   A response to an mDNS query MUST have RCODE set to
>   zero. mDNS responders may respond only to queries which they can resolve
>   positively.
>
> So, maybe you just want to say 'If the multicast query is not resolved
> during
> a limited amount of time...'
>
> ---
[Levon Esibov] Agree. In this case we should explain what "positively"
means in the second section that you quote above.


>
>   The sender MUST anticipate receiving multiple replies to the same
>   multicast query, in the event that several multicast DNS enabled
>   computers receive the query and respond with valid answers.  When this
>   occurs, the responses MAY first be concatenated, and then treated in the
>   same manner that multiple RRs received from the same DNS server would,
>   ordinarily.
>
> There are 2 ways of reading this.  The sender may get back >1 response
> while they are waiting.  This is OK.  Or the sender has to wait for a
> while till it gets back all the responses being sent.  This is not good.
> I say leave it up to the implementor.  I send a request, get a response
> back in 10 msec, and exit the resolver.  Or, I could send a request and
> gather all responses I get in a second.  What I don't like is the notion
> that a resolver is REQUIRED to wait for all the requests it gets back in
> a bounded period of time.  This means that even though I get a response
> in 10 msec, I end up waiting for (say) 3 seconds.  Poor performance
> has been rescued from the jaws of excellence!
>
[Levon Esibov]
our intend was not to require client to wait for all possible responses.
I agree that a decision on whether use the first or some or all of the
responses should be left up to implementers.

I thought that having MAY in the text doesn't require one to implement
it this way. Feel free to propose a clarifying text.

> ---
>   Where a host is configured to respond to multicast DNS queries on more
>   than one interface, the host MUST verify resource record uniqueness on
>   each interface for each UNIQUE resource record that could be used on
>   that interface. To accomplish this, the host MUST multicast a dynamic
>   DNS update request as specified in [RFC2136] for each new UNIQUE
>   resource record.
>
> Why don't you just use mDNS to multicast a request for UNIQUE before
> you answer for it?  This reduces the complexity of the protocol
> quite a bit (doesn't need dynamic update which isn't really used
> anyway, removes a normative reference and page 10 can be dropped!)
[Levon Esibov]
No ambiguity regarding the intent of the request is the main benefit of
using dynamic DNS opcode vs regular query. At this point I don't have
the exact scenario when this feature could be useful, but it is possible
that a host doesn't want for some reason to respond to a particular
query (e.g. if it is currently overloaded), but wants to defend its
name...

>
> ---
> [mDNSEnable]   Guttman, E., "DHCP mDNS Enable Option", Internet draft
>                (work in progress), draft-guttman-mdns-enable-01.txt,
>                July 2001.
>
> I need to carry this forward.  Please send feedback on this draft
> so that I can issue a revision.
>
> Erik


to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.