Subject: RE: Comments on draft-ietf-zeroconf-reqts-02

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 25 Feb 2000 08:51:43 -0800

To say this:

> Also, I think it would be equally impractical to build 
> a product that did not operate in the presence of a DHCP server.

anothe way ...

Also, I think it would be equally impractical to build 
a product that did not take advantage of the presence of a DHCP server.

-myron

> Hi Richard,
> 
> Daniel's response represents my understanding of the common 
> thinking. I also
> agree with these thoughts because many home networks will 
> have DHCP servers.
> I hope to advance a solution that does not require a DHCP 
> server in a home
> network, but IMHO it would be impractical to have an IP host config ZC
> protocol that does not operate in the presence of a DHCP 
> server. Also, I
> think it would be equally impractical to build a product that did not
> operate in the presence of a DHCP server.
> 
> -myron
> 
> ----- Original Message -----
> From: Daniel Senie <[email-masked]>
> To: Richard Humpleman - SISA <[email-masked]>
> Cc: Hattig, Myron <[email-masked]>; <[email-masked]>
> Sent: Thursday, February 24, 2000 2:49 PM
> Subject: Re: Comments on draft-ietf-zeroconf-reqts-02
> 
> 
> > Richard Humpleman - SISA wrote:
> > >
> > > >>    A host using a Zeroconf protocol must easily 
> transition in three
> > > >>    ways:
> > > >>    1. from a Zeroconf protocol to a non-Zeroconf protocol,
> > > >>    2. from a non-Zeroconf protocol to a Zeroconf protocol, and
> > > >>    3. from a Zeroconf protocol back to a Zeroconf 
> protocol (possibly
> > > >>      with new values).
> > > >>
> > > >> I think of the wording of the third case doesn't make 
> sense.  I think
> it
> > > >> makes more sense to say, "ZEROCONF protocols must be 
> prepared to
> > > reconfigure
> > > >> when the network environment changes.  This is a 
> general rule for all
> > > >> ZEROCONF protocols."
> > > >
> > > >Your suggestion is true for all three case. In fact it 
> is a common
> > > >pre-requisite to any them. Also, the "host" must be prepared, not
> > > >the "protocol". How about this:
> > > >
> > > >Hosts using ZEROCONF protocols must be prepared to 
> reconfigure when the
> > > >network environment changes.  This is a general rule for 
> all ZEROCONF
> > > >protocols. This requires a host using a Zeroconf 
> protocol to transition
> in
> > > >three ways:
> > > >1. from a Zeroconf protocol to a non-Zeroconf protocol,
> > > >2. from a non-Zeroconf protocol to a Zeroconf protocol, and
> > > >3. a Zeroconf protocol must be able to re-initialize 
> with possibly with
> new
> > > >   values.
> > > >
> > >
> > > Hello Myron,
> > >
> > > Is the intention of the writing here that there is no stand-alone
> Zeroconf
> > > host ie all Zeroconf hosts must support the office-LAN-config? For
> example
> > > an internet alarm clock or toaster that will never be taken to the
> office
> > > must still include DHCP client?
> >
> > I would argue that YES, you have to be able to handle being 
> DHCP client.
> > At least some users, EVEN HOME USERS, will have networks 
> large enough
> > and complex enough to be running DHCP and want to be able 
> to still talk
> > to their alarm clock and toaster.
> >
> > >
> > > Is a Zeroconf host = (Zeroconf + Office-LAN-config) host?
> >
> > The issue here is whether the case where DHCP or other 
> config is in use
> > is necessarily an "Office." I disagree (as stated above) with that
> > assessment.
> >
> > If you build a device which cannot handle transitioning to 
> a configured
> > case, then how do you have that device function on a LAN 
> with devices
> > that DO transition? The user workstations are not 
> necessarily capable of
> > communicating using multiple IP addresses, one zeroconf, 
> one assigned.
> > If we went to IPv6 this would be less of an issue, since there is
> > provision in IPv6 for multiple IP addresses on a node and site-local
> > addresses.
> >
> > While SOME systems using IPv4 will handle multiple 
> addresses, many will
> > not. I don't think it's a reasonable requirement that 
> Zeroconf systems
> > be able to handle multiple IP addresses (and figure out which one to
> > use) to accomodate devices which don't handle the transition case.
> >
> > >
> > > If so maybe we shouldn't call it Zeroconf (call it 
> Multiconf instead?)
> or
> > > take out the requirement for the office protocols?
> >
> > I guess I thought the goal was to allow devices to function when no
> > master config server or human configuration is performed. 
> That devices
> > still need to be able to function in the case where someone does
> > configure addresses or a config server is present is, I 
> hope, assumed.
> >
> > Just my two cents on the issue...
> >
> > --
> > -----------------------------------------------------------------
> > Daniel Senie                                        [email-masked]
> > Amaranth Networks Inc.            http://www.amaranthnetworks.com
> >
> >
> 
> 
>

---

From: Rajesh Krishnan <[email-masked]>
Date: Fri, 25 Feb 2000 13:22:16 -0500 (EST)

> a product that did not take advantage of the presence of a DHCP server.

It is easy to accidentally introduce a mis-configured DHCP server (perhaps 
appliances with wireless interfaces) into a DHCP network. Should all hosts 
in the ZeroConf network necesarily acquiesce to DHCP in this case? 

Debugging such situations may be beyond the resources of those needing
ZeroConf and will tie network operation to the need to understand how 
to configure the network. Some checks may be useful in the interest of
robustness.

One option is to consider adding extensions to a DHCP server in order 
to automatically reconfigure the DHCP server when an operational ZeroConf 
network is detected (I am not presuming to know how to do this.) This will 
be a step towards eventual full site auto-configuration.

-Rajesh