re: mdns-08 draft

[Erik Guttman <erik.guttman@sun.com>]

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.

---

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

---

  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!

---
  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!)

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