Subject: RE: How to overcome this WG's flailing

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 17 Aug 2000 18:46:42 -0400

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

...

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

Right, everybody's intention is to come up with a definition that completely
and clearly covers zeroconf from each possible perspective: the ultimate.
Well, I doubt that's possible. We must lower the expectations.

Although ignored so far, I am gonna make a final and shameless attempt to
point you to the definition I proposed a while ago:

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

I think it may be useful not necessarily as is, but as a different approach
example. I'll spare you the pain to read the associated rationale I sent. It
is archived at http://www.merit.edu/mail.archives/zeroconf/msg00722.html.

The other thing I thought of was scoping/prioritizing to linklocal goals
(http://www.merit.edu/mail.archives/zeroconf/msg00738.html). The AutoIP and
mDNS specs do that anyway.

Still waiting for comments, even destructive.

Thanks,
/dan

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 17 Aug 2000 18:32:14 -0700

Ross, Only our arms are flailing. ;-) I think your suggestion would cause
all of our limbs to flail. ;-) I think we should keep flailing along our
current path a little longer.

The idea of ZC to mean no "user" configuration was mostly an attempt to
flesh out the problems with past definitions.  I can certainly live with a
definition of zc that does not only apply to "user" configuration if that
definition is crisp and can be applied to real problems we are trying to
solve. I think now, as group, we agree on a common set of problems with the
version 3 and 4 definitions of zc and non-zc protocols. 

Here's an alternative idea to version 3 & 4. Stop trying to define what a zc
and a non-zc protocol is and isn't (I think someone already suggested this
but I couldn't see how to apply the idea before). Instead we should simply
say that we are working on protocols with the following behavior: protocols
may use configuration when it's available yet remain or become operational
when configuration is not available. Configuration can be defined as user
configuration, DHCP/DNS/MADCAP servers, configured routers, and many other
things. It is very easy to apply this statement to link-local
addressing->DHCP, mDNS->DNS, and ???->MADCAP; it neatly encompasses all the
messy transitions. It also easily applies to the "strangers on a train"
scenario.

Stuart's definition:
  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).
is also close to this idea if "either user configuration or external
infrastructure services" is replaced with the word "configuration", then
configuration is defined by example as above. The difference in the two
statements is the "may use configuration when it's available" clause. 

-myron

---

From: "Nicolae, Dan" <[email-masked]>
Date: Thu, 17 Aug 2000 22:56:07 -0400

> when configuration is not available. 
> 

Right, you can't simplify and deal with just two cases: zeroconf and
non-zeroconf. There are no two opposed (one is the negation of the other)
protocols that MAY coexist. 

The *reality* is *a single protocol* that intelligently transitions between
a minimum a maximum *functionality* based on how much configuration is
available at a certain time.
In between the maximum and the minimum there are discrete intermediate
levels. The transitions are multiple and the (only) rule is to always make
*the best* use of the available configuration to function on *the highest*
functionality level. 
The minimum is the two host linked with crossover cable. The maximum is a
fully administratively configured infrastructure.

The protocol is intelligent. It is able to perform *learning*. Learning does
not preclude a priori configuration (initialization). Neural nets are
intelligent and still depend on initialization as a starting point. Even the
ultimate *real* intelligent machines, the humans, are born with hard-coded
initialization (genetic code and a set of instincts).
User configuration is not an argument either, as is not the existence of
extra boxes (servers, agents, routers), nor the burn-in defaults. Regardless
of where the configuration comes from, the protocol finds it and uses it
with a maximum efficiency. 
Goal: the user intelligence is compensated and transmuted in protocol's
intelligence. This is the ultimate zeroconf definition. Because zeroconf is
an utopia and we deal with the real world, settle for a selfconfig
definition because that's all we're gonna get. Zeroconf is untouchable
unless you're God.

/dan

P.S. With the risk of becoming a persona-non-grata, I am still curious if
the latest discussions are not, at least roughly, touched in the proposal at
http://www.merit.edu/mail.archives/zeroconf/msg00722.html