Subject: Re: comments on requirements draft 04

From: Stuart Cheshire <[email-masked]>
Date: Thu, 17 Aug 2000 13:28:32 -0700

>I didn't say that they were necessarily strangers.

But I did. The people in my example *are* strangers, and if a proposed 
solution can't solve that problem then it hasn't solved the zeroconf 
problem.

>Here is more or less what I had in mind - you buy a stereo. (The central
>box.) It comes with (or you can buy additionally) smart speakers, which you
>can plug in anywhere in the house, and they'll play from the stereo (maybe
>using s wireless protocol). The stereo has all of the smarts, and the
>multiple playback devices, and without it the speakers don't work.
>Maybe it even acts as a DHCP server for them.

>If that requires no human intervention, why isn't that zeroconf ?

It is not "zeroconf" because "zeroconf" does not exist to be a marketing 
buzzword. If you want to sell a DHCP server, then call it a DHCP server, 
not something else.

The ultimate purpose of the work that goes on in the IETF is to define 
new protocols, where new protocols are needed to facilitate development 
of interoperable products that do useful things. The scenario you 
describe can be done today, using DHCP. We don't need a new protocol (or 
a new name for an old protocol) to make that possible. DHCP may well be 
the best answer for the situation you describe. If we decide that a DHCP 
server is the right answer for all situations, then we don't need a 
"zeroconf" working group, because the DHCP protocol is already defined. 
However, a DHCP server doesn't solve the strangers-on-a-train problem, 
ergo we do need something new, and by the same logic that new thing is 
NOT a DHCP server. The new thing is for environments where there is no 
DHCP server.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 17 Aug 2000 14:07:27 -0700

>solution can't solve that problem then it hasn't solved the zeroconf

This, in a nutshell, illustrates the problem that this WG seems to be 
having.  We're flailing about, trying to define what "zeroconf" means, but 
without a firm basis for forming such a definition.

Wouldn't a better approach be to first get consensus on a small set of 
examples/situations/scenarios that we must be able to support.  (Stuart's 
"strangers on a train" scenario could be one of these.)  These 
examples/situations/scenarios would be described in sufficient detail to 
ensure that we all understand exactly what they entail, and that we have 
consensus that they must be supportable.

Then, and *only then*, we could define "zeroconf" as being "a *minimal* set 
of protocols that support these examples/situations/scenarios", and work 
towards defining what these protocols will be.

In other words, we should first try to get consensus about *what* we want 
to support, and then get consensus on *how*.

         Ross.

---

From: Thomas Marshall Eubanks <[email-masked]>
Date: Thu, 17 Aug 2000 17:30:53 -0400

> to support, and then get consensus on *how*.

OK, here is one :

An Internet radio that plugs into (wirelesses into ?) a home network and is able to receive
multicasts from (say) 232/8 by just turing it on.

If you can't do that zero config, then you might as well close the group down.

Here is another (more complicated) :

An Internet radio and a home stereo that plug into a home network and
are able to find and communicate with each other, so that (say) the radio is able to
access storage on the stereo.

I feel that this discussion gets too abstract sometimes...

                                 Regards
                                 Marshall Eubanks

T.M. Eubanks
Multicast Technologies, Inc
10301 Democracy Lane, Suite 410
Fairfax, Virginia 22030
Phone : 703-293-9624
Fax     : 703-293-9609
e-mail : [email-masked]     [email-masked]

http://www.on-the-i.com http://www.buzzwaves.com