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

From: Stuart Cheshire <[email-masked]>
Date: Tue, 1 Feb 2000 20:26:33 -0800

>By the strict definition in the doc now, such a network would be
>a ZC network because it would have at least one ZC protocol.

That is precisely the point I am raising. Right now, the draft says:

>A Zeroconf network is a network that at some point in time has
>one or more Zeroconf protocols.

I'm starting to wonder how useful this definition is. Under this 
definition you can call a network a "Zeroconf network" even if it is 
currently using no ZC protocols at all, just as long as at it ran at 
least one of the Zeroconf protocols, however briefly, sometime in the 
past.

I wonder how much sense that will make to people outside the Working 
Group. I'm sure that's not what they have in mind when they think of 
setting up a Zeroconf network. Perhaps we should talk about a "pure 
Zeroconf network" as one running Zeroconf protocols in all of the four 
areas we are discussing (Figures 1 and 2), and a "hybrid Zeroconf 
network" as one currently running at least one Zeroconf protocol (Figures 
3 and 4).

Stuart Cheshire <[email-masked]>
 * <A HREF="http://ResComp.Stanford.EDU/~cheshire/">Web Page</A>
 * Wizard Without Portfolio, Apple Computer

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 1 Feb 2000 20:27:31 -0800

>ICMP echo for this, ICMP get netmask for that. seems to me you'll end
>up reinventing router discovery (rfc1256), which, by the way, is based
>on icmp. is there any reason not to use that? 

I think this is a *VERY* good question, which needs discussion.

I must admit that I had assumed that ZEROCONF would use two complementary 
but disjoint mechanisms: Something like net 169.254 claim-and-defend for 
purely link-local (non-routable) addresses, and DHCP server-assigned 
addresses for all larger scope (routable) addresses.

However, Myron points out a viable alternative, which is to say that the 
ZEROCONF WG does NOT endorse DHCP as the recommended configuration 
mechanism for routed networks, but instead recommends a different 
mechanism whereby a host discovers the network numbmer and then uses 
claim-and-defend to grab addresses at will on that (sub)network.

Or, we could say that ZEROCONF hosts are required to implement all three 
configuration mechanisms.

Comments?

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 22 Feb 2000 14:43:04 -0800

Stuart,

This response isn't as quick ;-) but none the less here it is ...

> Thanks for this quick response Myron.
> 
> I'll try to answer your questions.
> 
> >First, AutoNet is used as an example. People understand 
> autonet, thus they
> >understand the example. If we change AutoNet to something 
> else they will be
> >thinking about the something else instead of the purpose of 
> the example.
> 
> Well, currently, 'AutoNet' is just a draft, and you can't reference a 
> draft in an RFC. AutoNet would have to be published as an 
> RFC, and in its 
> current form, I don't think that would be appropriate without some 
> significant revisions. The revisions I think will be necessary are 
> breaking the artifical dependency between IPv4 link-local 
> addresses (aka 
> 'AutoNet') and DHCP, hence my comment about not implying too 
> much of an 
> interdependency in this document.

We should have the requirements draft done in within a month. Do you think
you can produce an "autonet" RFC in a month???

I think the rules are that it is okay to reference an I-D as long as it is
clearly labeled as "a work in progress".  

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 22 Feb 2000 14:47:09 -0800

Where discussion has ceased, the changes have been made. I'm in the process
of catching up on the other discussion points. Please follow through with
additional mail if you have additional opinions.

-myron

-----Original Message-----
From: Hattig, Myron 
Sent: Friday, January 28, 2000 1:15 PM
To: 'Stuart Cheshire'
Cc: 'Thomas Narten'; 'Erik Guttman'; 'Erik Nordmark'
Subject: FW: Comments on draft-ietf-zeroconf-reqts-02

Stuart,

Thanks for taking the time to read the draft so carefully and to make such
detailed comments!! Personally, I prefer the comments get posted to the list
to avoid surprising anyone and to start building consensus sooner instead of
later. 

Please send future emails to [email-masked].

> One general comment I have is that I think we need to stress ZEROCONF
> protocols rather than ZEROCONF networks.  Talking about ZEROCONF networks
> raises the question of what is and what is not a ZEROCONF network.  I
think
> we're finding that that can be pretty ambiguous.  I think that talking
about
> what is and what is not a ZEROCONF protocol is much easier to define.  It
> might be worth putting some explanation to that effect into the abstract
or
> the introduction which says that although a ZEROCONF network is a useful
> concept, the purpose of this document is not to classify any particular
> network as being either the ZEROCONF or non-ZEROCONF.  Instead, there is a
> spectrum of networks that may use some all all or none of the ZEROCONF
> protocols.

I think section 2 says this, but the abstract/intro may need some work. 

> On page 4 you reference the IPv4 Auto-Configuration Internet draft.  I'm
> planning on taking over that draft and recasting it as IPv4 Link Local
> Addressing which is independent from DHCP.  At some stage we will have to
> update the reference.

Just to let you know I'm working a AutoNet related draft also. It allows
auto-addressing across multiple IP subnets. I'm calling it AutoNet++. We
have already implemented it on Linux. ;-)  Regardless of either of our
drafts, I'm hesitant to change the reqmts draft for a couple of reasons.

First, AutoNet is used as an example. People understand autonet, thus they
understand the example. If we change AutoNet to something else they will be
thinking about the something else instead of the purpose of the example.

Second, I don't want to appear to favor one solution over another. I've gone
to great pains to make this obvious to the reader and WG members. If I start
changing examples to use "new" protocols, I may appear to be favoring that
protocol. Right now the doc only uses examples published before summer 1999.

> Page 5:
>
>    A non-Zeroconf protocol requires user configuration or relies on a
>    centralized server.
>
> I would say, "Requires user configuration or relies on configuration
> information received from a centralized server."

Agree. Will change.

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

>    For example, if a DHCP server comes on-line after
>    hosts are configured with [AutoNet], then hosts must re-configure
>    with DHCP.
>
> After I recast Autonet as IPv4 link local addressing, this will no longer
> make sense, because hosts may always have link local addresses all the
time.
> I think it should say, "If a DHCP server comes on-line, then hosts which
are
> waiting for DHCP configuration should detect the server's appearance and
> obtain an address."

Again, this is an example to illustrate a point. I'm not promoting any
particular protocol. If the example is changed to something the reader is
not familiar with, they will focus on the new protocol and miss the point of
the example. I think the text should remain unchanged.

>    For example, if a bridge is
>    installed between two networks where hosts were already configured
>    using [AutoNet], then hosts must re-configure with [AutoNet] to
>    ensure duplicate IP addresses do not exist.
>
> "...if a bridge is installed between two networks then hosts which are
using
> IPv4 link local addresses will have to detect addressing conflicts and
> reconfigure if necessary."

Your wording is better so I'll use it, but I'll leave [Autonet].

> Page 6:
>
>    For example if the DHCP server broadcasts an "DHCPAck" with a new
>    "I'm Here" option or "I'm Leaving" option as the proactive
>    mechanism, then [AutoNet] must still send a periodic DCHPDiscover
>    message.
>
> "...then DHCP clients must still send a periodic DCHPDiscover message."

Good catch!

>    Within a single network, the non-Zeroconf protocol-B (with its
>    server) may coexist with the Zeroconf protocol-C.
>
> I would suggest Zeroconf addressing protocol-A with non-Zeroconf name
> resolution protocol-D for the example.  I personally think it is less
> convincing that someone would set up a DNS server on the network but not
set
> up a DHCP server.  For example, the Apple AirPort base station implements
a
> DHCP server but not a DNS server.

I didn't think it mattered whether the point is made with a realistic or
non-realistic example. Since it may cause a distraction to the reader, I'll
change it.

>    Alternately, Zeroconf and non-Zeroconf protocols from a single
>    area SHOULD not coexist during normal operation. They may coexist
>    during a transition, but the coexistence period SHOULD be minimal.
>
> "In contrast, Zeroconf and non-Zeroconf protocols..."

Yours is better wording, I'll change it.

> Page 7:
>
>    Web browsing to an URL utilizes domain name to IP resolution. This
>    resolution capability allows applications (and sometimes users) to
>    remain blissfully unaware of IP addresses.
>
> I don't know what "(and sometimes users)" adds to that sentence.  I think
it
> can be deleted.

I'll add an FTP exmple that shows a person entering a name instead of IP
address then change "(and sometimes users)" to "and users". This will
clarify the point I was trying to make.

> Page 8:
>
>    Service - A service is set of processes that do a wide range of
>    network related things. Services range from printing to
>    transferring a file to providing on-line pizza order and delivery
>    service. A service may find some network management information,
>    perform some action, control some resource, or perform just about
>    any network-related function.
>
> A user may think of a service as a process that does something. I think
that
> for the purpose of this document we need to be a very precise.  For the
> purpose of this document a service is a process that speaks a particular
> protocol.  A user may think of a printing (in an abstract sense) as a
> service. From the point of view of a piece of software which is an LPR
> client, the LPR service is any process which speaks the LPR protocol.
Some
> other printing process which speaks some other printing protocol does not
> provide any service to the LPR client.  Also, some process which speaks
the
> LPR protocol but does not print may not be considered to a printing
service
> by a human user but nevertheless it is a service from the point of view of
> the LPR client.  This service is most definitely an LPR service.  Whether
> the service prints on white paper or prints on transparencies or send the
> document via fax or archives of the document onto a recordable CD is
> something that can be discovered via means such as SLP attributes.  It may
> be tempting to to try to define "service" in terms of human concepts but
> human concepts are notoriously vague, and vagueness is death in network
> protocols.

Good point. I'll change it to "A service is set of processes that speaks a
particular  protocol."

>    Service Characteristics - Characteristics differentiate services.
>    They may differential the same type of service in terms of
>
> "They may differentiate ..."

I'll fix the typo.

>    Service Discovery Protocol - A service discovery protocol enables
>    a client (or clients) to discover a server (or servers) of a
>    particular service. A service discovery protocol is an application
>    layer protocol that relies on, but does not interact with, network
>    and transport protocol layers.
>
> I don't know what you mean by "does not interact with" .  I think that it
> can be deleted.

Agree. It will be deleted.

> Page 9:
>
>    Peer - A process that is both a client and service for a specific
>    service protocol.
>
> This mean "... both a client and server ...".  However I'm not sure that
> saying "both a client and server" fully explains a peer to peer protocol.
> ARP is a peer to peer protocol.  Would you say that a host using the ARP
> protocol is both an ARP client and an ARP server?

We're not trying to describe a peer-to-peer protocol. We are describing a
peer within serivce discovery. I almost left the definition out until seeing
it used in Erik's example, thus a definition was required. In the context of
a
service discovery protocol, I think the definition is accurate. I'd like to
hear more thoughts on this.

>    Server - A process that offers a service to clients through a
>    service discovery protocol.
>
> You should delete, "through a service discovery protocol." A particular
FTP
> server may not use a service discovery protocol but that doesn't mean that
> it's not offering FTP service.

Again the context is service discovery not "network services". If a service
can't be found by a service discovery protocol, then it has no relevance
within the context of our discussion. I think the current definition is
okay.

>    Service Advertisement - A solicited response issued by a server or
>    registry. The advertisement provides the service identifier and
>    possibly service characteristics.
>
> I think that an advertisement is normally considered an unsolicited
> response.  If you think about the way that word is normally used in the
> English language, it means unsolicited information, not information that
you
> asked for.  I don't think that there is any difference between an
> advertisement and an announcement.

This is a typo. Should have been "unsolicited".

> Page 10:
>
>    A service discovery protocol MUST allow a client to discover then
>    utilize a service.
>
> I think this statement is too strong.  I think it would be sufficient to
> say, " A service discovery protocol MUST allow a client to discover a
> service."  I can discover LPR service without necessarily having an LPR
> client on my computer.  I think it is requiring too much of a service
> discovery protocol to say that it MUST allow me to utilize a service that
I
> have discovered.

Okay, I'll change it.

>    A service discovery protocol SHOULD limit the use of Service
>    Announcement messages so as to not flood the network unnecessarily
>    and most importantly not cause 'broadcast storms'.
>
> I think if we can delete of the comment about broadcast storms.
Unnecessary
> network traffic is not the same as a broadcast storm.

True. It will be changed to your suggestion.

>    A service discovery protocol MUST not cause scalability or
>    operational problems in larger non-Zeroconf networks if clients
>    and servers somehow transition to such networks.
>
> I think we can delete the word "somehow" in this sentence.

Delete will be done.

>    A Zeroconf network is a network that at some point in time has one
>    or more Zeroconf protocols. By this definition, almost all
>    networks are Zeroconf networks. This definition is intentionally
>    broad to avoid mandating a network to be Zeroconf or exclude
>    another network from using a Zeroconf protocol. The Internet and
>    corporate LANs are considered non-Zeroconf networks because,
>    today, these networks have little use for Zeroconf protocols.
>
> I wonder if this definition is too strong.  Perhaps we should say that a
> ZEROCONF network to is one where one or more of the hosts on that network
> are *currently* correctly running ZEROCONF protocols.

I'll think about this more ...

> Page 12:
>
>    The Figure 2 Zeroconf network has a small number of hosts
>    connected through an Ethernet hub. This may be a small office
>    network or a gaming network.
>
> I think it might be interesting to to give a slightly different examples
> here.  Instead of having physical wires and a hub we could have a
collection
> of laptop computers with 802.11 wireless interfaces, communicating peer to
> peer without a base station.

What is the benefit of the different example? Just seems like more work to
me. ;-)

> Page 13:
>
>    In this topology, broadcast packets reach all hosts and routing
>    only occurs to communicate between Zeroconf and non-Zeroconf
>    networks. All hosts SHOULD rely on netmask and the default route
>    as a normal IP host does when determining to ARP or to forward
>    packets to the default route.
>
> I don't think I understand this example.  If this is truly a ZEROCONF
> network then how do the hosts discover their netmask and the default
gateway
> they are supposed to use?

Is it that you don't understand the assumed requirements of using 
netmask and default route? OR 
Is it that there is no current ZC solution for the problem? 
Since I'm 99.99% sure that you understand the example and assumed
requirements ;-) 

> Page 15:
>
>    Zeroconf protocols that communicate between a host and a router to
>    configure the host MAY be considered.
>
> This sentence seems to be self contradictory.  If a host communicates with
> some distinguished machine on the network to configure itself, how can
that
> possibly be called ZEROCONF? The protocol you are talking about is DHCP
and
> DHCP is a non-ZEROCONF protocol.

The source of the text comes from comments in our last meeting and on the
list from Matt Squire, Steve Deering, and others that hope to extend these
protocols into a multiple IP network solution some day. My understanding of
the group concensus is that no one wants to solve this problem today, but we
don't want to preclude a future solution. 

How about this:
Zeroconf protocols may include communication between a host and a router,
but only if the router appears as just another host. In otherwords, the
protocol MUST NOT require the host to act differently in any way when a
router is present.

> Page 16:
>
>    All Zeroconf protocols MUST operate in single IP networks
>    (isolated and connected)
>
> I think this is unclear.  Perhaps it should say, "All ZEROCONF protocols
> must operate both in single isolated IP networks, and in single IP
networks
> that are connected to larger networks."

Okay, I'll change it.

Stuart, I'll respond to the other comments individually. (The scenarios 
section still needs a lot of work.) I'll either change the document, 
ask you directly, or take the issue to the list. 

Erik, have your heard back from the DNS/Mcast folks about ideas for
scenarios?

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 22 Feb 2000 14:53:32 -0800

Stuart,

> >peer within serivce discovery. I almost left the definition out until
> >seeing it used in Erik's example, thus a definition was 
> required. In the
> >context ofa service discovery protocol, I think the 
> definition is accurate.
> >I'd like to hear more thoughts on this.

I removed the definition of peer and will modify later sections so it does
not have to be defined.

> I thought we were defining terminology, as it is currently 
> understood. As 
> it is currently understood, not all services on the net are 
> discoverable 
> using a service discovery protocol. I expect that as we move forward, 
> more services will be discoverable, but not necessarily all.

I find myself wanting to repeat the same response I gave last time. Maybe
someone else can provide some insight. For now I'll leave it.

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Tue, 22 Feb 2000 15:30:20 -0800

Stuart,

Here is the intro to 2.3 Zeroconf Networks
-------
A Zeroconf network is a network that at some point in time has one or more
Zeroconf protocols. By this definition, almost all networks are Zeroconf
networks. This definition is intentionally broad to avoid mandating a
network to be Zeroconf or exclude another network from using a Zeroconf
protocol. The Internet and corporate LANs are considered non-Zeroconf
networks because, today, these networks have little use for Zeroconf
protocols. 

This section describes the existing Internet network model, the Zeroconf
topologies, and a summary of the key points. 
-------
To me this addresses the concerns you express. More thoughts???

-myron

> From: Stuart Cheshire [mailto:[email-masked]]
> Sent: Tuesday, February 01, 2000 8:27 PM
> To: [email-masked]
> Subject: RE: Comments on draft-ietf-zeroconf-reqts-02
> 
>

---

From: Richard Humpleman - SISA <[email-masked]>
Date: Fri, 25 Feb 2000 12:02:09 -0800

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

ZC can probably operate still, though not inter-operate with DHCP, but does
that matter?

DHCP doesn't require that every device on the network use DHCP for IP
address choice. According to the DHCP spec ARP should be used by a DHCP
Client to verify a given IP address. So devices using a DHCP derived
address should have a unique address even in the presence of devices whose
address is arrived at by other means eg ZC-only.

If there is no actual won't-work-unless requirement that ZeroConf be linked
up to DHCP-Config then I question whether there are sufficient grounds for
making the link in the ZC spec.

Thanks,
Richard.

>>> From: Paul Ferguson [mailto:[email-masked]]
>>> Sent: Friday, February 25, 2000 9:21 AM
>>> To: Myron Hattig
>>> Cc: [email-masked]
>>> Subject: Re: Comments on draft-ietf-zeroconf-reqts-02
>>> 
>>> 
>>> At 11:47 PM 02/24/2000 -0800, Myron Hattig wrote:
>>> 
>>> >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.
>>> 
>>> I concur.
>>> 
>>> - paul
>>> 
>>>

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Mon, 28 Feb 2000 17:20:40 +1100

> I agree, no one seems to be considering IPv6 in any of these discussions.
> This is despite the fact that Home networking  would be a perfect market
> for it, considering that it basically solves half the problems in the
> charter of this WG.
> 
> Hesham
> 
> From:	Dave Thaler [SMTP:[email-masked]]
> Sent:	Monday, 28 February 2000 6:22
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > "McDonald, Ira" wrote:
> > > I also concur.  And strongly urge that we not plan to make
> > > ZC-capable devices support multiple IP addresses (e.g.,
> > > link-local and also DHCP-derived) on the same interface.
> > 
> > FWIW, I agree completely:
> > 
> >    it's important that ZC-capable devices can operate in a 
> >    "normal" IP environment.
> > 
> >    and adding multiple IP address support to ZC-cabable 
> >    devices overly complicates several issues.
> > 
> > Take care,
> > Pax.
> 
> Aren't multiple IP addresses a "normal" IPv6 environment?
> 
> -Dave

---

From: "McDonald, Ira" <[email-masked]>
Date: Mon, 28 Feb 2000 12:06:21 -0800

Hi Erik,

I think it's fine to consider that *some* ZC-capable devices
will be able to support multiple IPv4 addresses (let's keep
the IPv6 discussion separate - the IAB and IESG are still
far from concensus on methods/protocols for IPv4/IPv6
coexistence, in my reading of the I-Ds).

But implementors at both of my current clients (Sharp and
Xerox) are very concerned about making low-priced network
printers *have* to support multiple IPv4 addresses on the
same physical interface, because the protocol stacks they
have bought from third-parties uniformly do NOT support
that capability (and deployed printer client software
doesn't recognize the possibility).

Separate profiles for ZC protocols for IPv4 and IPv6 are
a good idea, in my opinion.  And while the IPv6 profiles
may need to be completed before the ZC WG has finished
its task, the IPv4 profiles can and should be finished
first, in my opinion.

Cheers,
- Ira McDonald (consulting architect at Sharp Labs America)
  High North Inc

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Monday, February 28, 2000 4:28 AM
To: McDonald, Ira; Garry M. Paxinos
Cc: [email-masked]; [email-masked]
Subject: Re: Comments on draft-ietf-zeroconf-reqts-02

>    devices overly complicates several issues.

Ira, Garry,

I understand that current hosts do not support >1 address per
interface.  But they don't support ZC features either.  

I believe it may be worth while supporting both a ZC (local)
address and a configured (global) address to ease transition
in and out of ZC mode.  If you have a ZC network which is fully
numbered and works fine (say your house), you don't want to have
to renumber and see stuff stop working (even temporarily) when
your dial-up networking comes up, your cable modem gets plugged
in again, etc.

The argument actually applies to all ZC protocols (host conf,
addressing, service discovery, mc addr conf).  As long as these
configurations are only used locally, they may not conflict with
the global configuration.  This is more complicated, agreed.  But
let's consider it.

Erik