Subject: RE: mdns-08 draft

From: "Levon Esibov" <[email-masked]>
Date: Thu, 20 Dec 2001 17:17:57 -0800

> -----Original Message-----
> From: Erik Guttman [mailto:[email-masked]]
> Sent: Thursday, December 20, 2001 10:15 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Levon Esibov; Dave Thaler;
> [email-masked]; [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Dec 2001 09:14:47 -0800 (PST)

>  In the future, we may define Multicast DNS to be something grander.

Done. See http://www.drizzle.com/~aboba/draft-ietf-dnsext-mdns-08.txt for
the new version. 

> A host configured to not be a "responder" cannot be a "sender".
>  

How about this? 

"A host configured to not be a responder SHOULD NOT be a "sender". While
hosts configured only as senders can detect name conflicts, they cannot
notify other senders of potential name conflicts for their name. Thus
implementation of both responder and sender functionality is encouraged."

> >   refers in this document to a response with the RCODE set to 0)
> during
> > a
> >   limited amount of time,
> > 

Done. 

> means in the second section that you quote above.

Moved. 

> it this way. Feel free to propose a clarifying text.

How about this? 

"However, after receiving an initial response, the sender is not required
to wait for LMDNS_TIMEOUT for additional responses."

>>"If... senders on that network are configured with the key for the top
>> zone "local.arpa."...
>
> Why is this still here? Shouldn't the last sentence be removed? 

How about this? 

"The mechanism specified in this draft does not require use of DNSSEC. As
a result, responses to LMDNS queries MAY NOT be authenticated. If
authentication is desired, and a pre-arranged security ocnfiguration is
possible, then IPsec ESP with a null transform MAY be used to authenticate
LMDNS responses. In a small network without a certificate authority, this
can be most easily accomplished through configuration of a group
pre-shared key for trusted hosts."

---

From: Erik Guttman <[email-masked]>
Date: Fri, 21 Dec 2001 23:15:18 +0100

Bernard,

> "A host configured to not be a responder SHOULD NOT be a "sender". While
s/SHOULD NOT/SHOULD

---

> to wait for LMDNS_TIMEOUT for additional responses."

I like it.
 
> a result, responses to LMDNS queries MAY NOT be authenticated. If
s/MAY NOT/may not

This text expresses a possibility not a requirement.  It should be
written in lower case.

> pre-shared key for trusted hosts."

Groovy.

Erik

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 21 Dec 2001 14:43:42 -0800 (PST)

> > "A host configured to not be a responder SHOULD NOT be a "sender". While

What are we trying to say here? That senders SHOULD be responders
too? Or that a sender MAY NOT be a responder?