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

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Jan 2000 20:04:37 -0800

Myron, here are my comments about the latest draft.

I think we're making good progress.

It starts off pretty well, but it gets a bit verbose towards the end.
There's lots of stuff in "mom and apple pie" style about the wondrous 
things
that a service discovery protocol has to do, which I think can be reduced.

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.  

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.

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

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

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

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

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

   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.

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

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.  

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.

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

"They may differentiate ..."

   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.  

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?

   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.

   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.

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.  

   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.

   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.

   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.

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.

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?

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.

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

   This scenario applies to single IP network topologies (isolated or
   with a gateway). Only the IP address must be configured. The
   netmask can be configured to a value or assumed to be
   255.255.255.255. No default route is needed.

I think you mean that the net mask should be 0.0.0.0. A net mask of
255.255.255.255 means that *no* other hosts are reachable on that network.

Page 17: 

   - Network numbers of IP addresses MUST be unique within the entire
     Zeroconf network.

How about "... within the entire ZEROCONF internetwork."

Page 18: 

   There is an addition requirement to your "periodic conflict
     detection" requirement. It is an active mechanism to restart
     conflict detection. This is needed in case the period is too
     large for a hosts needs.

I don't agree that there is any requirement for periodic conflict 
detection.
Suppose I wander within range of your wireless network with a laptop
computer that happens to have a conflicting IP address, and then I wander
away again without sending any packets, is there any reason to do any 
harm?
Once my laptop computer tries to communicate we will discover the address
conflict.  Until then there is no reason to do any harm.

Page 19: 

   This protocol should include the ability for a host to
   choose a name, determine if the name is in use, and then choose a
   different name if it is re-used.

I think this should say, "... choose a different name if it is already in
use.  " 

   - A host that wishes to be addressable by name MUST select a
     domain name.

"... select a host name." I think we are talking about the name of a host
here, not the name of a domain.

   - At various times a host MUST actively determine if another host
     is using its name.

I do not believe that this is a requirement.  Active periodic checks are a
waste of network bandwidth.  Some protocols may work this way, but this is
not a requirement of all protocols.

Page 20: 

   Printer discovery must allow a printing client to discover the
   location of a printer and enough information about the print job
   submission protocol to be able to submit jobs.  Further printer
   discovery must discriminate between printers which are useful and
   those which are not.

I do not agree that this is a requirement. If I want to use the printer
which has plenty of spare ink cartridges sitting on the table beside it, 
it
is a mistake to *require* all discovery protocols to be able to find that
for me.

I think it is about here that the requirements document gets into
unsubstantiated rhetoric. I think there is a lot more text in this section
than there needs to be.

   - The service discovery mechanism has to allow for discriminating
     queries.  A client has to be able to discover a printer for
     which it has a driver, for instance.

I think that is part of discovering a service that speaks a particular
protocol.

   - Service discovery has to be able to discover the characteristics
     of an advertised service.

I do not agree. You may argue that it is useful, but it is not required.

    3.4.2  Discover File Access Server

Is this different from a "File Server"?

Page 21: 

   File sharing is done on a 'session basis'

What about AFS, DFS, CODA? Are they done on a 'session basis'? What does
this mean?

   Further, existing service discovery mechanisms for file access
   servers (from Novell, Apple and Microsoft proprietary protocols)
   allow the user to discover something about the file system they
   would access.  This include the name of the file system, a human
   readable description of it as well as a 'group' or 'groups' that
   the file system was shared to.

Not true. AppleTalk NBP locates all servers offering "AFP" protocol. That 
is
all.

   Since there may be many 'peers' in a network of personal computing
   devices, it is critical that some grouping is possible, so that
   users can locate file access servers that are meaningful to them
   (located nearby, shared by colleagues close to them in the
   organization, shared by those who will allow the user access to
   the files, file systems whose content is of a general kind, etc.)

I do not agree that this is "critical". Large AppleTalk networks have
managed fine for fifteen years without it.

   AppleTalk, Novell networks and Microsoft networks all suffer in
   performance for this reason. Finally, file access is typically

You will need to define "performance". AppleShare is currently one of the
fastest file servers on the planet. It's performance clearly doesn't 
suffer
that much.

Page 22: 

3.4.2.3   Protocol Requirements

I think a lot of this stuff can be deleted. For example:

   - Clients can discover some information about file systems that
     they could choose to access (the name of the file system, a
     description of it and whether the user has access permission,
     at the very least).

I do not agree that verifying a user's cryptographic credentials and 
access
permissions is a necessary requirement for just discovering a list of
servers. Does the service directory need to know every password for every
user on every file server in order to determine whether they have access
permission?

   One important application of service discovery is the discovery of
   manageable devices by a 'management' system.  Conversely,
   manageable devices may need to discover their manager.  The
   relationship between manager and managed system is different than
   is the case in most service discovery applications since the
   manageable device is in many respects a service with respect to
   the manager, but there is usually only one manager and many
   manageable systems.

This is exactly the same as me discovering printers. I have only one 
laptop
computer but I am discovering many printers on the network.

Page 23: 

   The management system (manager) needs to be able to discover
   devices which support appropriate management services (management
   agents).

I don't see how this is different to any other kind of service discovery. 
If
I want to use SNMP, then I have to discover all the entities on the 
network
that will speak SNMP to me (SNMP 'servers', if you wish). This is why I
think it is useful to define a 'service' as something that speaks a given
protocol, not something that performs some abstract action like printing.

   - Managers have to be able to discover only the subset of agents
     that are relevant.  This means that managers have to be able to
     discover agents on the basis of their hardware, software or
     there device specification or status.

I think that if you require the service discovery protocol to be able to
evaluate arbitrary queries like this, you've reinvented the management
protocol itself.

Page 24: 

   Clients and servers using a service discovery protocol in a
   zeroconf environment have to be able to obtain configuration.

I think this could be worded better. Right now, it sounds
self-contradictory.

This is the end of my comments for now.

Thanks again for all your work on this.

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: Fri, 28 Jan 2000 20:40:26 -0800

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.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Jan 2000 20:42:35 -0800

>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 ofa service discovery protocol, I think the definition is accurate.
>I'd like to hear more thoughts on this.

I have an intuitive idea what "peer" means, but it is hard to explain, so 
I got this from the dictionary:

peer
A person who has equal standing with another or others, as in rank, 
class, or age.
One of the same rank, quality, endowments, character, etc.; an equal; a 
match; a mate.
A companion; a fellow: "To stray away into these forests drear,/Alone, 
without a peer" (John Keats).
A unit of communications hardware or software that is on the same 
protocol layer of a network as another.

It describes being "at the same level", not anything to do with clients 
and servers.

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

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.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Jan 2000 20:43:19 -0800

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

I have recently come to realize that wireless is a *much* more compelling 
example. If three people with laptops with Ethernet want to network them, 
they need to have cables, and someone needs to have remembered to bring a 
hub. If they are on the beach, then the hub needs to be battery powered, 
which I have never seen :-) If three people with laptops with 802.11 
wireless want to network them, they don't need anything else.

Around my circle of friends, lots of them have bought Apple iBooks, and 
not one of them has bought one without the $99 11Mb/s wireless card. They 
are absolutely ubiquitous, and that changes the way you think about 
things. In the old days, if you had a group of people with laptop 
computers in a room, they could make a little Ethernet network (but they 
usually didn't, unless they were there to play Bolo). Now, if you had a 
group of people with laptop computers in a room, it is pretty hard *not* 
to have a network. If we do our jobs right in this WG, they will be able 
to do useful things with that network.

---

From: Stuart Cheshire <[email-masked]>
Date: Fri, 28 Jan 2000 20:46:27 -0800

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

I'm prepared to agree that with IPv4 link-local addresses, we can assume 
that every host knows the netmask is /16. However, how does the host 
discover the IP address of the gateway machine, if not by using some 
configuration 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.

I think this gets back to the question of, "What is a ZEROCONF network?" 
Maybe Figure 3 is a hybrid ZEROCONF/non-ZEROCONF network, using 
non-ZEROCONF address/mask/gateway configuration (e.g. DHCP) in 
conjunction with ZEROCONF name resolution?

Or are you thinking that Figure 3 could be a pure ZEROCONF internetwork, 
not using DHCP?

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 28 Jan 2000 22:28:19 -0800

Stuart,

> I'm prepared to agree that with IPv4 link-local addresses, we 
> can assume that every host knows the netmask is /16. 

I agree, /16 MUST be true for link local addresses.

> However, how does the host 

ICMP get default route works if supported by the router.

Another method is to ping 224.0.0.2 - the source IP address in the 
echo reply is always a router. ... I didn't believe this at first,
but it is true for the routers on our corporate LAN. ;-) I'm curious
to hear if most routers support this or not.

ICMP get netmask returns the netmask. It can be supported by hosts
or a router. 

> >My understanding of the group consensus is that no one wants to solve

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.
 
> Or are you thinking that Figure 3 could be a pure ZEROCONF 
> internetwork, not using DHCP?

Yes. Actually fig 3, 4, and 5. But of course fig 5 requires some 
router to router communication that is absolutely outside the 
scope of ZC WG. I think the host portion of the protocol can 
remain the same for networks in all three figures. However, 
DHCP is already widely deployed for such networks so what I'm 
thinking of may not be a "real-world" solution.

Back to the original point. I think the text your questioning 
represents group consensus. I'm not claiming that it
is consensus (that's your job ;-), but it appears to me that 
it is consensus. 

-myron

---

From: Gabriel Montenegro <[email-masked]>
Date: Sat, 29 Jan 2000 09:46:05 -0800

>ICMP get netmask returns the netmask. It can be supported by hosts

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?

---

From: "Hattig, Myron" <[email-masked]>
Date: Sun, 30 Jan 2000 11:29:34 -0800

Gabriel,

I don't want to derail the discussion about the requirements 
draft since that is our near-term deliverable. Here is a response
to your question, but if we wish to continue this conversation we
should probably do so offline ...

From RFC 1256:
5.3. Host Behavior
   On any interface on which the host supports IP multicast, the host
   will be a member of the all-systems IP multicast group (224.0.0.1).
   This occurs automatically, as specified in [4]; no explicit action is
   required on the part of the router discovery protocol implementation.
   A host never sends a Router Advertisement message.
   A host silently discards any Router Advertisement message that
   arrives on an interface for which the host's configured
   PerformRouterDiscovery flag is FALSE, and it never sends a Router
   Solicitation on such an interface.
   A host cannot process an advertisement until it has determined its
   own IP address(es) and subnet mask(s) for the interface on which the
   advertisement is received.  (On some links, a host may be able to use
   some combination of BOOTP [3], RARP [5], or ICMP Address Mask
   messages [7] to discover its own address and mask.)  While waiting to
   learn the address and mask of an interface, a host may save any valid
   advertisements received on that interface for later processing; this
   allows router discovery and address/mask discovery to proceed in
parallel.

As the above text indicates, RFC 1256 defines a method to get the default 
route but not the netmask. The other two methods to get the default route 
(ping 224.0.0.2 or ICMP get default route) seem easier to me.

-myron

> -----Original Message-----
> From: Gabriel Montenegro [mailto:[email-masked]]
>