Subject: Re: comments on requirements draft 04

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

>I think we should say that no pair of ZEROCONF-compliant hosts, when 
>properly connected together by a common physical link technology, should 
>be prevented from communication merely by lack of additional 
>infrastructure services.

I've been thinking about this some more, and I think I'm convinced that 
stating the requirement this way is the best way to express what zeroconf 
is about. Trying to talk about servers, or lack thereof, or a priori 
configuration, or lack thereof, or numbers of hosts or size of network 
always seems to end up self-contradictory. (When every host is running a 
mini-mDNS server, then does that make them non-zeroconf because there are 
"servers" in the network?)

What we're really trying to achieve is simply the ability for IP hosts to 
communicate. Presence of DHCP servers, routers, and DNS servers helps 
enable hosts to communicate with other hosts worldwide. Lack of DHCP 
servers, routers, and DNS servers should not render the hosts deaf and 
mute. They may have reduced IP communication capability, but they should 
not be reduced to no IP communication capability at all.

With that in mind, I think we should say that:

  A zeroconf protocol is able to operate correctly in the absence
  of either user configuration or external infrastructure services
  (e.g. conventional DHCP or DNS servers).

  Correct operation means that
  a pair of zeroconf-compliant hosts
  using compatible link-layer interfaces,
  not physically separated beyond
  the reasonable operating range of those interfaces,
  are never prevented from communicating by
  lack of manual configuration or external infrastructure.

Some explanations for the wording:

1. Note that this says, "*able* to operate correctly...." It does not 
say, "MUST NOT use user configuration", or, "MUST NOT use infrastructure 
services." If a user wants to chose ("configure") a name for their host, 
then they can (and they should be told when it is invalid for some 
reason). However, if they don't then the protcol should be able to make 
up a sensible name on its own. If a user wants to chose ("configure") an 
IP address for an interface, then they should be able to do that (and 
they should be told when it is invalid for some reason). However, if they 
don't then the protcol should be able to make up a sensible address on 
its own.

2. In my previous version of the text, I said, "properly connected 
together by a common physical link technology." I realized later that if 
you have to connect two Ethernet ports using a crossover cable, and you 
don't have a crossover cable, then you are prevented from communicating 
due to lack of that "infrastructure". If a vendor labels a product 
"zeroconf", but the user then has to go out and buy an Ethernet crossover 
cable to make it work, how is that qualitatively different to having to 
buy an Ethernet hub, or having to buy a little mini-router with a DHCP 
server in it?

I think our definition of zeroconf can and should address this. If a 
vendor wants to label a product "zeroconf", then the box must contain 
*everything* required for communication with other link-compatible 
zeroconf devices. If the product doesn't have a bidirectional 
auto-sensing Ethernet port, then the box needs to include a crossover 
cable as well. If the product has some wireless technology that can't 
communicate peer-to-peer, then the box needs to include a wireless hub. 
If the hub's too expensive to include one with every unit, then you can't 
put "zeroconf" on the box.

3. Note also that I said, "using compatible link-layer interfaces." 
Zeroconf IP can't be more compatible than the underlying link-layer it is 
running over. For this reason, vendors who choose to label their products 
"zeroconf" will need to label their products as 
"zeroconf-over-something", as shown below:

    ----------    ----------    ----------
    |Zeroconf|    |Zeroconf|    |Zeroconf|
    |--------|    |--------|    |--------|
    |Ethernet|    |802.11DS|    |  IrDA  |
    ----------    ----------    ----------

This gives customers a reasonable expectation that if they buy two 
"Zeroconf/802.11DS" devices, then they won't need to buy *anything* else 
to make them communicate.

4. "...not physically separated beyond the reasonable operating range..." 
Zeroconf IP does not guarantee that a Zeroconf device will be able to 
communicate with *every* other Zeroconf device in the world, including 
the ones currently on the far side of the planet. Communication beyond 
the range of the link-layer technology requires some kind of external 
infrastructure to forward those packets, and zeroconf does not address 
that case.

-----------------------------------------------

Comments please.

Ross is right that until we can agree on what zeroconf means, it is hard 
to have meaningful discussions about how to achieve it.

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

---

From: Peter Johansson <[email-masked]>
Date: Thu, 17 Aug 2000 16:15:52 -0700

At 03:23 PM 8/17/00, Stuart Cheshire wrote:

>"A zeroconf protocol is able to operate correctly in the absence of either 
>user configuration or external infrastructure services (e.g. conventional 
>DHCP or DNS servers)."

With all due respect to what is a cleaner, more elegant definition than 
many advanced thus far, I think it still misses the point made by Ross 
Finlayson. ANY definition, at the moment, would miss the point.

It is hard enough to craft a succinct definition when one knows what is to 
be said. This working group does not yet know what it wishes to say.

Maybe, as Ross suggested, by examining a reasonably large set of examples 
and sorting them into a "Not ZeroConf" pile and a "ZeroConf" pile, the 
criteria will, ex post facto, stand out on their own. Once they are 
perceived in agreement by the group, then you can write the charter.

If a third pile emerges, examples for which there are no clear consensus, 
its simple existence may help the working group. I have the impression that 
the various charter definitions put forth thus far are being pushed and 
pulled by various individuals wishes to include or exclude examples from 
ZeroConf. It's a lot easier to see what's under discussion if you stick to 
the immediate subject matter (the examples) and not their abstraction (the 
definition).

I think Marshall Eubank's contribution of two examples is a step in the 
right direction.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]