Subject: Re: draft-manning-multicast-dns-00.txt

From: Bill Woodcock <[email-masked]>
Date: Mon, 5 Apr 1999 22:08:30 -0700 (PDT)

Yes, this all needs to be cleaned up a bit, it does suffer a bit from
the kitchen sink phenomenon that Randy points out.

The reason for this, in large part, is because it's the product of two
projects which were converging.  One, to do local resolution using 
whatever DNS servers were available, in the absence of access to root
DNS.  Two, to provide an IP-based replacement for NBP and WINS.  Both
of these projects were already underway, and the actual means was 
getting similar enough that it seemed best to just glom them together
and try to polish the rough edges off.  I hope you all agree that 
that's preferable to having both of these shipping as separate protocols
without any IETF oversight, as would otherwise have happened.

In the wake of the Minneapolis meeting, there's a new draft which has
more specific language regarding exponential back-off on any packets
which have to be multicast, and discusses prior RFCs to look to for
guidance on determining uniqueness of service names.

Rather than throwing up our hands and saying "multicast is bad, it uses
packets, and they go all over the network!" it would be helpful to 
remember that _nearly anything_ would be an improvement over the current
situation, which is NBP and WINS, and concentrate on making as much of
an incremental improvement as possible, while we have the chance.  If we
take too much time hand-waving on this one, it'll go right by, and 
implementations that you _won't want running on your network_ will be 
shipping in large volume.

So.  New draft should be available shortly, with more on exponential 
backoff and uniqueness of names.  What else should we be looking at?

			-Bill

---

From: Randy Bush <[email-masked]>
Date: Tue, 6 Apr 1999 09:19:56 -0700 (PDT)

> situation, which is NBP and WINS

i suspect that the visceral issue here is that NBP and WINS are perceived
as being limited to a LAN and mcast is perceived as being net wide.  and i
do think i understand admin scoped mcast.  i am talking about why people's
instinctive first reactions to this proposal are not highly positive.  mcast
does not have a good rep this year.

> If we take too much time hand-waving on this one, it'll go right by, and

you forgot the "my 10,000 customers demand it" part, jim:-).  our job is to
get the engineering as correct as we can, and presume that truth and justice
will prevail.

i suspect i could be convinced to like this proposal if it was more crisp
about goals and means, and if it made a clear and believable operational
prescription for limiting the scope of the chaos.  also, maybe separate the
stub server issue out, so it can be seen as a separate set of benefits to be
worth the major hack.

randy