Subject: Re: Resolution of proposed changes to mDNS-00 draft

From: Erik Guttman <[email-masked]>
Date: Wed, 04 Jul 2001 23:17:33 -0700

> since you asked, i still prefer to continue using a single mechanism, dhcp
> in this case, as opposed to inventing new overlapping kludges.  but you knew
> that already.

Randy,

So you favor the 'mDNS enable' approach over the 'domain search list'
approach?  Or are you suggesting something else?

Erik

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Robert Elz <[email-masked]>
Date: Thu, 05 Jul 2001 09:57:10 -0700

Date:        Wed, 4 Jul 2001 23:33:35 -0700 (PDT)
    From:        Bernard Aboba <[email-masked]>
    Message-ID:  <[email-masked]>

  | >   | Submitted by: Erik Guttman, Dave Thaler
  | >   | Justification: Current language does not fully specify retransmission
  | >   | behavior.

  | Do you have a proposal for better text? Or do we just clarify, by saying
  | "1, 2, 4 seconds"?

I would just say ...

	Repetition MUST NOT be attempted more than 3 times and SHOULD NOT
	be repeated more often than once per second to reduce unnecessary
	network traffic.

[aside, my spell checker noticed a typo in the original when I pasted it,
traffic was missing the 'r' - I didn't spot that one myself]

That's sufficient.  That is, just drop the second proposed sentence
which says about exponential increases.

I don't like a 1 2 4 second requirement, in most LANs that's overkill.
That is, it generates exactly the same amount of traffic, but causes the
client to have to wait longer ...   In practice, if the node that could
answer is ever going to answer, it will do so on the first or second
transmission anyway, the extras will rarely help.

It might be worth adding

	The delay between attempts should be randomised so as to avoid
	synchronisation effects.

perhaps.   I doubt any more than that is really required.

  | > Unless and until we get some experience with this, that shows that one
  | > approach works best, leaving it implementation defined is best.
  | 
  | Yes. There's no obvious answer. Do you have proposed modified text

Just say:

	If an mDNS client sends requests over multiple interfaces, and
	receives replies from more than one, the result returned to the
	client is implementation defined.

If you want, leave in some of the explanations of what is happening.

My guess is that most clients will be gone immediately after the first
reply is received anyway "I want an answer, someone sent me the answer,
I'm done" - they won't be hanging around waiting just in case another
answer happens to come from someplace else (how long would they wait?
99% of the time there never will be any more).  So the usual result
is going to be "first answer received wins" I suspect.  But none of that
should be mentioned.

Note that the obvious case where this is likely to happen, is where not
only is the source of the mDNS query multi-homed on two (or more) interfaces,
but so is the destination - so the destination node (which is 
target.local.arpa or whatever) will see the mDNS request on both of its
interfaces, and reply on both, so there will be two replies.  While it
some circumstances the replies might be identical (containing both addresses)
I can also see mDNS server implementations returning only the address
of the interface over which they received the query (avoid problems of
nodes attempting to access some "foreign" net - there might be no router).

In the case where only link local addresses are in use (on both interfaces)
that behaviour is mandatory of course (you can't return a link local address
for one interface to nodes on a different one).   So, in that case, there
will be two different replies (even if the numeric value of the address is
the same, it is a different address) that have originated at the same
node (an undetectable difference from a name duplication).

  | >   |     ARPA domain servers MUST NOT reply to requests for
  | >   |     subdomains of '.local.arpa'.

  | Do you have a proposal for modified text?

For this part, no, no text is needed.   Just delete the offending
sentence entirely.   We don't need to give any instructions at all
to the ARPA domain servers - they just need to do what they always do.

  | > There needs to be something in here to prevent hosts sending queries
  | > for this domain to the ARPA servers (that's where it needs to be stopped
  | > not at the ARPA servers).
  | 
  | Do you have a suggestion for the "something"?

This one is hard, and I'm not sure what is best.

Perhaps something like ...

	DNS servers SHOULD NOT forward queries for domain names in the
	local.arpa domain - if the server cannot answer the query from
	its own database, it should reply with a non-authoritative NXDOMAIN.

But that is perhaps too strict, in some cases it is OK to forward
queries from a local back end resolver to a local server ...  But how
to describe this in any kind of words that makes sense is beyond me
at the minute.

kre