Subject: RE: decision item for ZEROCONF WG: What is zeroconf?

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 9 Aug 2000 08:29:41 -0700

Hi Erik,

I agree with your new definition of ZC below.

There is a typo in the first line.  You said
'a prior' and meant 'a priori'.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Wednesday, August 09, 2000 12:04 AM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: decision item for ZEROCONF WG: What is zeroconf?

In my comments on draft 4 of the requirements, I objected to
the text in draft defining what a zeroconf protocol is.  This
is of such fundamental importance to the WG, I want a formal 
decision.

The definition in draft 03 was:

   A zeroconf protocol requires no user configuration and does not
   rely on information received from a centralized server.
 
   A non-zeroconf protocol requires user configuration or relies on
   information received from a centralized server.

The definition in draft 04 is:

     A zeroconf protocol requires no user configuration.  
    
     A non-zeroconf protocol requires user configuration. 

I believe this is a wrong turn.  The 03 definition is far closer to
what I think we mean by 'zero configuration' - namely, a host comes
up with no configuration but contains software which can collaboratively
obtain configuration state from the network.  If there is a server on the
network which configures the host (a client-server dynamic configuration
protocol), the host is not collaborating to configure itself.  We no longer
are generating configuration but obtaining it. 

The definition I propose is:

     A zeroconf protocol requires no a prior configuration.  A host
     obtains all configuration a posteriori, on the basis of
     interactions with other hosts or routers on the network, over
     time.

     A non-zeroconf protocol requires configuration (for instance
     user configuration, configuration burned into hardware,
     configuration obtained from a client-server dynamic configuration
     protocol, etc.)

             ***********************************************
             ***********************************************
             ***       For WG mailing list approval      ***
             ***                                         ***
             ***  Decide on which formulation of the     ***
             ***  definition of a zeroconf protocol.     ***
             ***                                         ***
             ***  Choose version 03, 04 or Erik's.       ***
             ***                                         ***
             ***********************************************
             ***********************************************

Please send your comments to the list in the next two weeks.

Erik

---

From: "Nicolae, Dan" <[email-masked]>
Date: Wed, 09 Aug 2000 16:59:06 -0400

> >   information received from a centralized server.

This matches the best my understanding of zeroconf ideal. The best of the
three current choices.

> >     A non-zeroconf protocol requires user configuration. 

This may be correct but the missing server issue is not apparent. The
missing server is the main issue that fuels the zeroconf wg purpose. User is
a very general term mostly associated with a human. It also covers an
administrator who configures a DHCP or DNS server, but this again is not
apparent from the definition.

> >     interactions with other hosts or routers on the network, over

According to this definition, standard DHCP is a zeroconf protocol. There is
no a priori configuration on the client.

My suggestion:
"A zeroconf protocol requires neither centralized nor manual configuration
management."

- It does not lead to the false impression that configuration itself is not
required. Managing that configuration must be seamless.
- It points out that server-based and manual management do not qualify.
- It is very close to the WG description (the initial and true motivation)
- It is similar to the rationale in RFC1001 that lead to b-node definition

Questions:
Why do we need to define what a non-zeroconf protocol is? Isn't it clear
that if a protocol is not zeroconf than it is non-zeroconf?

The "zeroconf" term works only when it clearly refers to "configuration" as
"the act of configuring" (action) as opposed of "the set of protocol
parameters that govern the protocol's behavior" (data). Isn't "zeroadmin" or
"zeromanage" less confusing? Or something else?

What is covered by a zeroconf protocol? Only the peer-to-peer operation and
the transition to a non-zeroconf protocol? Or the protocol as whole,
including the server-based operation?
I mean is DHCP non-zeroconf while AutoIP is zeroconf? Or the addition of
AutoIP to the standard DHCP makes the resulting DHCP protocol zeroconf? What
does the transition apply to? Do we change protocols or we change modes of
operation within the same protocol?

Thanks,
dan

---

From: Erik Guttman <[email-masked]>
Date: Thu, 10 Aug 2000 10:03:02 +0200 (MET DST)

This concerns my proposed formulation of the definition of a zeroconf

>      configuration obtained from a client-server dynamic configuration

The point is not to forbid a priori configuration.  The point is to not 
require it.

We aren't trying to mandate a stateless networking environment, just to 
allow it to function.  Saying that preconfiguration requires a non-
zeroconf protocol to be used (like sneaker net, etc) is not to say that
the parameters obtained that way can't be used.  Burned in unique
IDs are OK to use - if they exist.  We would unfortunately be excluding
an important set of potential hosts if we required such parameters in
every case.

Myron wrote:
> Here are some examples, a burned in MAC address is used for autonet in an
> ARP request to see if an IP address is used. Erik's definition excludes
> autonet from being a ZC protocol.

Autoconf for IPv4 uses a random #, not a mac address.  Autoconf for
IPv6 uses a MAC address, but can be used with a random # as well.
See

http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-02.txt

Donald Eastlake wrote:
> Given the choices offered, I would go with -03.  Erik's version has
> merit but I think it is too wordy, I'd prefer to minimize the latin,
> and I see no problem with zeroconf using "configuration" burned into
> hardware such as serial numbers, MAC addresses, public-private key
> pairs, etc. although perhpas that is not what we mean by
> "configuration" and is more like "identity"...

Sorry about the wordiness & latin, but I think the distinction between
being able to derive configuration from having it beforehand is important.

There is nothing *wrong* with having a mac address, certificates, etc.
preconfigured.  Its just that this is not *zero* configuration.  A 
protocol which makes use of a MAC address may be more efficient, but as
in the case of IPv6 addrconf, it is not necessary.  A protocol which
*requires* the use of serial #s, certificates, etc. should not be a
zeroconf protocol, I maintain.  This would preclude cheap generic 
off-the-shelf components from being IP enabled.  Remember the goal 
from STD-2:

      1.2.4  Configuration
 
         It would be ideal if a host implementation of the Internet
         protocol suite could be entirely self-configuring.  This would
         allow the whole suite to be implemented in ROM or cast into
         silicon, it would simplify diskless workstations, and it would
         be an immense boon to harried LAN administrators as well as
         system vendors.  We have not reached this ideal; in fact, we
         are not even close.

Erik

---

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 10 Aug 2000 12:27:57 -0400

Cuneyt Akinlar wrote:
> Some people suggested
> that a zeroconfig protocol does not use a server. I don't see why you
> cannot call a protocol zeroconfig if the server does not require
> manual configuration?  So much for the definition of a zeroconfig
> protocol.
>
So, if I design a DHCP server to automatically hand out linklocal IP
addresses unless configured otherwise, it means I just made DHCP zeroconf?
Or, if I design a DNS server to listen for dynamic DNS updates, cache them
all and use them to answer DNS queries, it means I just made DNS zeroconf?

Marshall Eubanks wrote:
> Using that principle, Zeroconfig means no human intervention 
> ANYWHERE. If that
> requires a central box, then why isn't that OK - as long as 
> the central box
> doesn't require human intervention.
>
The very fact that you need to *add* or *turn on* that central box is human
intervention.

It may be OK to assume that in most cases a central box (e.g. router) will
be present, turned on and configured. But how about the few cases when it is
not? Like home networks not connected to the Internet or the two guys using
the crossover cable in a plane?

It seems clear to me that a zeroconf protocol MUST NOT require a central
entity to function, even when no user configuration is required. If you
ignore that in the definition, lots of protocols can claim zeroconf
compliance (perhaps with minimal modifications).
[Regardless of how we call that central entity: server, proxy, cache, agent
etc., it is a *specialized* host that does community work to allow the
protocol to operate.]

I can see a possible way to get away with the *specialized* host requirement
and still be zeroconf:
Require that *each* host running the zeroconf protocol be able to perform
the *specialized* function. That is, if there is no *specialized* box
around, than one of the hosts automatically becomes one. This is similar to
Microsoft's Browser; which, regardless of what criticism can get, you have
to admit that it is as zeroconf as a protocol can possibly be.
Translated to SLP, if SLP requires a DA than each host should be able to
become one if there is no DA around.

Does this alternative sound reasonable? I doubt it. Thus I believe
definition 04 is incorrect.

dan

---

From: Erik Guttman Sun Frankfurt Staff Engineer <[email-masked]>
Date: Thu, 10 Aug 2000 19:23:49 +0-200

>"Hattig, Myron" wrote:

If you have configuration - use it.  A mac address, certificates, a unique
id serial number, whatever.  

If you have a router - and it had better be configured! - hosts can use 
configuration it provides them (say with router advertisements, etc.)

What I am arguing against is *requiring* this configuration in the zeroconf
protocols.  We want zeroconf protocols to work in the absence of configuration
and the absence of servers.  The only way we will achieve this is by being
100% clear that zeroconf protocols do not require a priori configuration.

>Going back to the "my <insert name of favorite older relative>" rule -
>If you can't just plug it in and turn it on my Mother will not use it.
>If you can, she will.
>
>Using that principle, Zeroconfig means no human intervention ANYWHERE. If that
>requires a central box, then why isn't that OK - as long as the central box
>doesn't require human intervention. I am not sure that  DHCP qualifies -
>I know we've had to fddle with it when we were setting it up.

We're writing protocol not human interface requirements. 

If we leave it open whether protocols can require central servers
or not, we leave it open whether ZC protocols can have central
points of failure, misconfigured servers, two servers (not good
when we're talking DHCP), etc etc. 

Erik