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

From: "Nicolae, Dan" <[email-masked]>
Date: Fri, 11 Aug 2000 17:37:59 -0400

Based on the recent discussions/clarifications I want to revise my initial
opinion. 

***********************************************
I know believe that Erik's definition is the 
best one out of the three current choices.
***********************************************

I still maintain that the "no a priori" formulation becomes clear only when
backed up by clarifications and practical examples. I still believe that the
definition leaves room to unforeseen and possibly undesirable
interpretations. I would like to see more definition proposals, as I believe
none of the three we have so far is accurate and clear. 
I am also making a two-cent proposal at the end of this message.

Erik wrote:
> 
> 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.

I think Myron is talking about the usage of ARP request to validate a
generated IP address for uniqueness, not about the IP address generation
based on the MAC address.

So, his comment is valid. ARP is non-zeroconf because *it requires* "a
priori" configuration (MAC address). Can a protocol be considered zeroconf
when it mandates the use of a non-zeroconf protocol? 

Of course, it can be argued that AutoIP may work without IP conflict
detection, without using ARP, or that ARP should be made zeroconf. Or that
"configuration" strictly refers to the protocol itself and does not apply to
auxiliary or lower-layer protocols. Anybody?

Erik wrote:
> 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.  

This makes sense if you exclude the above protocol dependency considerations
and practical security aspects. Otherwise, as defined, zeroconf is and it
may be forever just an ideal never reachable.

> 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.

It is always good to take a step back and the above quote is excellent.

It may be worth no note that the term used is *selfconfig* and not
*zeroconfig*. In my opinion *selfconfig* would not forbid the requirement of
"a priori" configuration. Defaults and burn-in configuration are tolerable.

Also, the reference is made to the *protocol suite* and not a particular
*protocol*. This preserves the system-wide view and does not take a single
protocol out of context. A self-configuring suite is not necessarily a
collection of self-configuring protocols. Some may be non-selfconfig. 
An example is AutoIP. The ultimate goal of AutoIP is to configure IP and not
itself. Despite AutoIP, IP remains non-selfconfig, but the collection of IP
and AutoIP becomes selfconfig.

Given all the considerations and arguments I've seen so far, I believe that
it may help to reduce a bit the ambition of defining a zeroconfig protocol. 

We may keep Erik's definition of a zeroconfig protocol, as an ultimate goal.

I am taking a shot at a more forgiving definition, about a selfconfig
protocol:

***********************************************************
A protocol is selfconfig if its main functionality, 
possibly reduced or less efficient, is possible 
when no explicit administrative configuration is available.
***********************************************************

"No explicit administrative configuration" was stolen from STD3, RFC1122,
section 3.2.2.9, page 46. 
I prefer using "administrative" instead of "user" to be closer to STD3 where
protocols are categorized in "user" and "support" protocols (or "control"
protocols in other cases e.g. ICMP). The main distinction is that a
"support" or "control" protocol provides auxiliary system functions while a
"user" protocol "provides service directly to the users". 
"Administrative" makes it apparent that the lack of administration is the
problem and not the configuration that may be required from an user *by
design* (e.g. provide an e-mail address or a password).

"Explicit" is still arguable but at least indicates a clear administrative
intent (like disable/enable a protocol, use this IP, use this server etc.)
as opposed to configuration that was provided as a helper "a priori" (e.g.
MAC address, digital certificate etc.) 
"Explicit" also allows for "implicit" administrative intent, such as when I
turn on a SLP DA to regulate traffic, or a new router becomes available.
Well, "explicit" (vs. "implicit") is questionable and it may be given up,
but it covers the manual maintenance of DHCP scopes and DNS zone files (the
centralized server issue).

"Main functionality" does not preclude a protocol from being declared
selfconfig when it does not provide "full functionality". For example,
AutoIP can't help with the DHCP options (e.g. DNS server addresses) but it
still is selfconfig because the main DHCP purpose is to get the IP
configuration.

"Possibly reduced or less efficient" is inspired from the "graceful
degradation" concept seen for HTTP. E.g. AutoIP may not help with
communication beyond linklocal scope when there is no router support. Or,
some "auto" algorithms may be less efficient than when configuration is
supplied by a human.

Note that the above definition does not imply the existence of selfconfig
and non-selfconfig peer protocols ("from the same area"). AutoIP would be
the selfconfig version of DHCP but DHCP is not its non-selfconfig peer; DHCP
is part of AutoIP, as DNS is part of mDNS. SLP would be selfconfig
altogether, we can't split it in selfconfig and non-selfconfig parts. The
idea is not to define a separate selfconfig protocol but to enhance a
non-selfconfig protocol and make it selfconfig.

Consequently, discussing transitions between protocols "from the same area"
is no longer appropriate. (I don't think it was appropriate with the
previous definitions either, because discussing the transition from
non-zeroconfig to zeroconfig implies that a non-zeroconfig protocol is
zeroconfig-aware, or the transition to non-zeroconfig never happened fully.
E.g. once you switch to pure DHCP how can control be given back to AutoIP
when DHCP has no idea about AutoIP? By resetting the protocol stack and
allow AutoIP come back during the initialization? That would work, but it
seems to belong to implementation rather)

The analysis switches to how a zeroconf protocol improves its functionality
based on new information (e.g. a router came on line, a conflict was
detected), and it obeys to explicit administrative configuration (e.g. must
use this IP and give up the linklocal one, can't multicast any longer) as
soon as that configuration becomes available. 

The bottom line is that the protocol makes the *best* use of the available
information at any time and it still functions. Self-configuration is a
best-effort and graceful degradation is acceptable. (This is consistent with
self-tuning techniques used by other protocols, like TCP e.g.). If there is
an *acceptable* way for the protocol to achieve its purpose than it shall be
used. Don't get killed without a fight. No IP address, make up one; no DNS
server, find one or multicast etc. This is the zeroconf idea, isn't it?

/dan

---

From: Dale Worley <[email-masked]>
Date: Mon, 14 Aug 2000 12:21:28 -0400

From: "Nicolae, Dan" <[email-masked]>

It's tough to jump into the middle of this, but it seems to me that
the distinction is this: From the point of view of a *user*, a MAC
address *is* zero-configuration because the device comes with one out
of the box -- the user doesn't have to do any configuration.  From the
point of view of the device manufacturer, the manufacturer has to
interface with the whole MAC address assignment infrastructure.  So
it's not zero-configuration from the manufacturer's point of view.

From a practical/marketing point of view, making the protocol
zero-configuration for the user is the important property.  Indeed, it
is probably an acceptable tradeoff to put *more* configuration effort
on the manufacturer if it puts less on the user.

Dale
-- 
Dale R. Worley    Engineer                  <[email-masked]>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/