Subject: comments on requirements draft 04

From: Erik Guttman <[email-masked]>
Date: Tue, 8 Aug 2000 15:41:39 +0200 (MET DST)

The following are comments on draft-ietf-zeroconf-reqts-04.txt

These issues were brought up by comments on the draft and
discussed during the IETF 48 WG meeting.  The WG discussion
is covered in a separate message.

I want to emphasize:

 ***  These issues are for discussion.  I'm sending them  ***
 ***  as a working group participant, not as the working  ***
 ***  group chair.  Please send your comments!            ***

===========================================================================

The highest impact issues effect the direction of document,
and could fundamentally change the focus of the working group.

 1. The definition of a zeroconf protocol is too narrow.  We need
    to broaden it.

    I contend that a zeroconf protocol requires no external configuration,
    be it from burned in defaults, user configuration or via a network 
    based configuration protocol (like DHCP).  That is not to say a host
    can't use these mechanisms to become configured, but in that case, the
    host is not using a zeroconf protocol to obtain its configuration
    parameters.

    Zero configuration means zero a priori configuration, Locke's blank
    slate.  All configuration is done a posteriori - in collaboration with 
    other hosts on the network and on the basis of what is learned and 
    determined over the course of time.  This is different than saying there
    is no configuration (ever) which would be absurd - networking would be
    impossible.

    This implies a change to the following sections:

   section 1.2.1, p 3 
     A zeroconf protocol requires no user configuration.  
    
     A non-zeroconf protocol requires user configuration. 

   ->
     A zeroconf protocol requires no a prior configuration.  A host
     obtains all configuration a posteriori, on the basis of
     interactions with other hosts or routers on the network, over
     time.

     A non-zeroconf protocol requires configuration (for instance
     user configuration, configuration burned into hardware,
     configuration obtained from a client-server dynamic configuration
     protocol, etc.)

   section 1.2.5, p 5
     Centralized servers such as DHCP servers are being deployed in 
     home networks to relieve user configuration. However, networks 
     accidentally operating with multiple DHCP servers present new 
     configuration challenges. Today’s solution is for a person to 
     configure one of the DHCP servers to stop operating; since a user 
     must do something (turn off a DHCP server) this is a non-zeroconf 
     solution.  

     In order for a centralized server protocol to be zeroconf while 
     operating with multiple servers, there must be mechanisms to 
     ensure all clients use the appropriate server. Of course, these 
     mechanisms must operate without any user configuration. 

    ->
     Centralized dynamic allocation mechanisms such as DHCP servers
     are deployed to allow automatic configuration to reduce the effort
     of administering networks.  A host MAY use a dynamic configuration 
     protocol such as DHCP, but this is distinct from any configuration
     it obtains using a zeroconf protocol.

 2. Is reconfiguration required when infrastructure detected?

    The current document REQUIRES these transitions to take place.
  
    This is undesirable for several reasons:  (1) Some devices
    may be designed/implemented to only use local configuration
    obtained from zero configuration protocols, (2) Some devices 
    may want to continue to use local configuration *and* use
    global configuration, (3) Forcing reconfiguration will result
    in software having to be robust to frequent renumbering.  This
    is especially onerous to servers, hardly any of which (today) 
    would recover if they lost their IP configuration.

    There are serious implications which have to be worked out.
    Allowing both local and global configuration effectively means
    we have a scoped architecture (like IPv6).  One could argue that
    this would not be an issue if we required transitions from (when
    non-zeroconf protocols were detected, since a host could only be
    in one scope).  These issues will be explored in a separate internet
    draft on scoped address behavior for IPv4.  The essential concern
    is that local configuration only be used on the link in which it
    was configured.  Hosts must have simple rules to select which 
    scope of address and which interface to use to send datagrams to
    a given destination address.  Other implications:  Scalability
    issues may preclude using admin scope and instead argue for link
    local scope or some new 'zeroconf local' multicast scope, potential 
    inconsistencies (as when DNS servers won't have the  same 
    configuration as hosts which respond to name to address
    resolution requests) and implications of proxying protocols 
    destined for hosts which use zeroconf generated configuration
    parameters.

    Sections effected:

   p3
     For example, if 
     a DHCP server comes online after hosts are configured with a 
     zeroconf IP host configuration protocol then hosts MUST re-
     configure with DHCP. 

    MUST -> MAY 

   p4

     In contrast, zeroconf and non-zeroconf protocols from a single 
     area MUST NOT be able to coexist during normal operation. They MAY 
     coexist during a transition, but the coexistence period MUST be 
     minimal.   

    ->

     Zeroconf and non-zeroconf protocols from a single area MAY
     coexist during normal operation.  

    Other sections which discuss transition need to be reviewed as well.

    In general, the meaning of 'transition' changes.  It is no longer
    a requirement - there are in effect 3 states 'zeroconf only',
    'configured only' and 'both'.  Transition is to and from the
    state where configured is supported, but not necessarily to and
    from support of zeroconf (which can be used at any time).

 3. Host name (not domain name) to IP Address Resolution

    The motivation for this change is the following:  Host names
    do not imply that the domain name system is used for naming the
    host, but does not preclude it.  It is entirely different to name
    my host bob than to name my host bob (as a TLD, or in some implied
    domain). What we want in the ZEROCONF setting may be more like the
    /etc/hosts (local host configuration) than DNS configuration.  We
    may want local host names as opposed to global names.

    The main thing is that the current document discusses sub-domain
    delegation, which may not really appropriate for a zeroconf protocol.

   p6
     It is assumed that sub-domain delegation is not done within the 
     zone that a zeroconf domain name to IP address resolution protocol 
     is performed. In other words, a zeroconf zone contains all of the 
     names in its domain. 

    At the IETF 48 ZEROCONF meeting Bill Manning pointed out that there
    is a lot of history behind the distinction between host names and
    domain names.  That may make it unwise to pursue this distinction.

    This issue effects the text many places, but we'd need to decide
    if this is a fruitful avenue to pursue.

 3. IP Host configuration is defined in terms of default routers,
    IP subnets, and subnet masks.  This is inappropriate.

    The essential requirements for a host are that they know their address
    and that they have routing state.  That is, the host must know with
    which interface and with which method to forward IP datagrams.  One
    such implementation is to use subnet masks as discussed in section 
    2.1.1.  Another is to maintain a routing table with network numbers.
    Another still is to only use link local addresses and to always use
    ARP (or neighbor discovery). 

    For this reason, text describing subnet masks should be removed from
    the draft and in particular the text (which is rather didactic and not
    a propos to requirements) in section 2.1.1 should be removed.

    The requirements would change as follows (likely a reworded a little):

   p9
     - The ability to determine the netmask for an IP subnet. 
     - The ability to determine the default route for an IP subnet. 
     - The ability to have unique IP addresses within an IP subnet. 
     - The ability to have unique IP subnets within an internet.  
   ->
     - The ability to determine which interface to forward an IP datagram.
     - The ability to determine whether an IP address is on a connected
       network.
     - The ability to determine the default route, if there is one.

    This follows from RFC 1122, section 3.3.1.

    If the IP address of the destination is on a directly connected network
    the datagram is sent directly to the destination address.  Otherwise,
    the datagram is sent to a gateway on a connected network.  But, as
    RFC 1122, Section 3.3.1 states:

            The host IP layer MUST operate correctly in a minimal
            network environment, and in particular, when there are no
            gateways.  For example, if the IP layer of a host insists on
            finding at least one gateway to initialize, the host will be
            unable to operate on a single isolated broadcast net.

    This section makes no mention of subnets.  The essential thing is that
    a host has some way of mapping a destination address to a policy (ARP
    or FORWARD) using, for example, a routing table filled with network
    numbers, not that the host use subnet masks and the algorithm in the
    current requirements draft.

 5. Several places in the document discuss periodic messages.  This is
    *not* the requirement - in fact it is a highly undesirable protocol
    feature.

    Due to the possibility that topologies may change - claim and defend
    protocols cannot be considered conclusive when they detect no conflict.
    Consider host HA on network NA claims address A.  On a distinct network
    NB, host HB also claims HB.  Now networks NA and NB are joined to form
    NC.  Hosts HA and HB must detect this condition and resolve the conflict.

    One way to do this is to send periodic messages to detect conflicts.
    This is what is suggested in

   section 2.1.3, p 9
     These scenarios require the periodic actions as well as specific 
     actions at startup.

   p 10
     - The ability to detect the presence or absence of a DHCP server 
       at startup of a device and periodically after a devices starts. 

   section 2.1.4, p 10
     - The ability to detect the presence or absence of a DHCP server 
       at startup of a device and periodically after a devices starts.

   section 2.2.3, p 11
     - The ability to periodically ensure the uniqueness of a selected 
       host name. 

   section 2.2.5, p 12
     - The ability to periodically ensure the uniqueness of a selected 
       host name. 

   section 2.3.3, p 14
     - The ability for a host to determine if another host has 
       allocated an address that has been allocated by itself; this 
       SHOULD be done periodically.  

   section 2.3.5, p 15
     - The ability to detect the presence or absence of a MADCAP server 
       at startup of a device and periodically after a devices starts. 

   section 2.3.6, p 16
     - The ability for a host to determine if another host has 
       allocated an address that has been allocated by itself; this 
       SHOULD be done periodically.  

    In each case there are protocol design alternatives.  For instance,
    if ARP, mDNS, AAP replies were multicast instead of unicast, then
    hosts could detect collisions through the normal use of the protocol.
    Note these protocols either don't exist yet or do not support this
    operation today, but they could be enhanced to do so.  The requirement
    is detection of conflicts after allocation, not that periodic messages
    be sent.  In fact, it is never desirable to send periodic messages.
    This has been the death of many protocols and networking suites which
    mandated them!  If hosts are not actively communicating, they should 
    not need to issue any messages onto the network.

 6. Service discovery protocol requirements include notification that
    a service is going off line.

    No peer to peer service discovery protocol which is deployed today 
    allows notification that a peer is going off line.  This is not 
    possible using NBP, SLP, etc.  Thus the following is inappropriate
    and should be removed from the specification:

   section 2.4.1, p 17
     - The protocol SHOULD allow services that are no longer active to 
       notify clients in a time (within seconds) manner.  

   section 2.4.3, p 18
     - The protocol SHOULD allow services that are no longer active to 
       notify clients in a time (within seconds) manner.  

    It is still possible to have very responsive human interfaces, for
    instance - if a browser in the foreground it can poll the network.
    Other optional features are possible (notification) for specialized
    applications - but this is not a requirement.

 7. As discussed on the mailing list, we will be silent with respect to
    secure IP Host Configuration (ARP, IPv6 neighbor discovery, DHCP,
    etc.)

    ARP is not secure and there is no plan to secure it.

    !!!  The point of security requirements for Zeroconf protocols is  !!!
    !!!  to not make the IP suite any less secure than it already is.  !!!
    !!!  That has to be added to section 3 and kept in mind.           !!!

    For this reason, section 3.1 should be dropped.
  
===========================================================================

These comments are important, but aren't likely to require much discussion.

a. Add to the Introduction Stuart's suggested motivating text

   Zero configuration networking is not intended to replace or compete
   with existing mechanisms deployed in today's large-scale IP networks
   such as the Internet.  Instead, zero configuration networking is
   aimed at small scale isolated networks that are poorly served by
   today's IP mechanisms, beginning with the extreme case of just two
   devices and scaling up as far as is reasonable.
   
b. Replace some text for clarity

   I like Stuart's formulation more.

  section 1.2.3, p 4
   To illustrate this point, suppose there are standard zeroconf and 
   non-zeroconf protocols for IP host configuration and domain name 
   to IP address resolution. 
    
   For IP host configuration, the zeroconf protocol is "protocol-A."  
   The non-zeroconf protocol is "protocol-B", supported by a fully 
   conformant "protocol-B" server. 
    
   For domain name to IP address resolution, the zeroconf protocol is 
   "protocol-C".  The non-zeroconf protocol is "protocol-D" supported 
   by a fully conformant "protocol-D" server. 
    
   Within a single network, the IP host configuration zeroconf 
   protocol-A MUST be able to coexist with the domain name to IP 
   address resolution non-zeroconf protocol-D.  

  ->
   It is not necessary to always use zeroconf protocols in all four
   areas.  For example, it might make sense on some networks to provide
   a DHCP server for configured address allocation, but perform name to
   address resolution using a zeroconf protocol.  Zeroconf protocols used
   in one or more areas should be compatible with configured networking
   protocols in other areas.

c. Scalability is not the primary concern, but it is still a concern for
   zeroconf network protocols.

  section 1.2.4, p 4-5
    Scalability is not of great concern because it is expected that 
    zeroconf protocols will operate in networks of limited size. In 
    addition, it is likely that as a network grows, the owners of that 
    network will migrate to using non-zeroconf protocols before     
    scalability becomes an issue. For this reason, this document 
    mentions little of scalability requirements. 

  ->
    Scalability is not a primary requirement for zeroconf networks,
    but it is an important consideration.  If there are two protocols
    which otherwise meet the requirements, one which scales up better
    will be preferred for standardization over a protocol which does
    not scale well to larger networks or larger numbers of hosts.

    There is a limit to the scalability of any zeroconf protocol. 
    At some point for performance or operational reasons a network
    may become too large to operate without administrative configuration.

   Stuart's text for this section follows, but I like mine better :-)

    Scalability in the conventional sense is not an overriding
    constraint for zeroconf protocols because they are designed
    explicitely for small networks.  Zeroconf protocols should be
    made as scalable as possible, but not moreso.

d. The following text makes it sound as if a boundary router is required
   for networks which use Zeroconf protocols:

  section 1.2.8, p 6
     Zeroconf solutions are only concerned with IP multicast addresses 
     scoped as Local (i.e. 239.255.0.0/16), link-local, node-local, and 
     Single-source IP multicast addresses of any scope. It is assumed 
                                                        ^^^^^^^^^^^^^
     that a boundary router (as described in RFC 2365) is present to 
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     appropriately control multicast packets from entering and leaving 
     the scope boundaries.  

    This text has to be changed to say that if there are routers,
    then routers must be configured at the boundary of the zeroconf
    network so that zeroconf protocols will not exit the administrative
    boundary.  

    The routers themselves need to be configured, so they can take this
    configuration (ie. that they define the boundary of admin scope mc).

e. Unclear text

   What does this mean?

  section 2.1.2, p 9
    This creates two problems. First, hosts may have duplicate IP 
    addresses. Second, there may be competing netmask and default 
    route values that disrupt communication. 

   I don't understand this text at all.  If two zc networks merge,
   both will use the same automatic IP address configuration protocol
   and there will be no conflict - both will know how to forward pkts
   and share the same network number (the link local prefix).  Also,
   if there are two routers - each of which could be used as a default 
   route, provided the hosts could detect the router.

f. Unclear text

   What does this mean?

  section 2.2.2, p 11
    A domain name consists of a host name and the name of the domain 
    itself. A host has control over its host name, but some other 
    entity configures or determines the name of the domain.

   In what way does a host have control over its own domain name?
   Normally an administrator has control over it.  In a peer to 
   peer network, where there is no administrator (where only zeroconf
   protocols are used) then there may be something to what you say.
   Or, if you are using DHCP and support the ability of a host to
   request a host name, you may get the results you describe.  

   Using the zeroconf name to address resolution protocol we could 
   detect name conflicts.  This is not a fundamental requirement of 
   this protocol, but rather an application of it.  This would change
   the sense of this section a little bit, which needs to be reworked
   regardless.

g. Too many transitions and other issues.

  section 2.2.4, p 11-12

   There are four transitional cases to consider. Note that 
   unless a host is configured with the IP address of the DNS server, 
   none of these transitions can occur. 

    I would state this as 'unless a host can obtain the address
    of a DNS server as configuration,'...

    This is because there may be ways to detect the DNS server
    address than to be configured with its address (a priori).

   The first is a zeroconf to non-zeroconf transition that occurs 
   when the host is first configured with the IP address of the DNS 
   server and the host can actually reach the DNS server (i.e. the 
   DNS server responds to requests). 

    Now the host can use DNS.  It doesn't necessarily want to stop
    using zeroconf name to address resolution (say for local names,
    if those names can be distinguished from global names).

   The second is a non-zeroconf to zeroconf transition that occurs 
   when for some reason the DNS server can no longer be reached. One 
   such reason may be that the host is moved to a network without 
   connectivity to the DNS server. In this case the zeroconf domain 
   name to IP address resolution protocol MUST be invoked. 
    
    I agree with the above paragraph except with the last sentence.
    No host is required to use zeroconf protocols.  What you want
    to say is that the host can only get name to address resolution
    if it uses the zeroconf domain name to address protocol.

   The third transition is from zeroconf back to non-zeroconf. This 
   occurs when the DNS server becomes reachable again. Following the 
   above example, the host is moved back to the original network with 
   connectivity to the DNS server. 

    This is the same as the first.
    
   The final transition is a non-zeroconf to zeroconf transition that 
   occurs when the IP address of the DNS server is removed from the 
   host.    

    This is the same as the second.
  
h. admin range allocation should be moved to the IANA considerations
   section:

  section 2.3.2, p 14
    To date, no range has been reserved for dynamic allocation of 
    Single-source addresses in IPv6.  Hence, until such a range is 
    reserved, dynamic allocation of Single-source addresses applies 
    only to IPv4. 

  section 2.3.3, p 14
    To date, no range has been reserved for dynamic allocation of 
    Link-scoped addresses in IPv4.  Hence, unless such a range is 
    reserved, dynamic allocation of Link-scoped addresses applies only 
    to IPv6. 

  section 2.3.7, p 16 repeates the above.
   
  These 2 paragraphs can go to section 4.

i. The idea that the last sender to a group should deallocate it
   is simplistic.

  section 2.3.4, p 15
    Here, the first source that needs the IP address MUST allocate the 
    address, yet it may not be the host that deallocates the multicast 
    address. This is because the first source may leave the multicast 
    group before all the other sources stop sending packets to that IP 
    multicast address. This requires, the last source using the IP 
    multicast address to deallocate the IP multicast address after it 
    is done sending. 

   It is quite imaginable that there would be a protocol which would
   want to allocate a mc address as long as there was a member of the
   group (receiver).  That way, if anyone ever wanted to send a message
   to a member of that group it would go to that stable membership set.

   The text should simply add 'or group member' where it says source
   and I think it would work.

j. The 'Print Manager' example has problems.

  section 2.4.2, p 17
    A printer manager acts as a proxy to various printers. A printer 
    manager improves scalability by providing a single location from 
    which clients can find all printers. 

   HP, Lexmark and Axis Communications all use SLP for their printer
   management software so that it can dynamically discover all printers
   (manufactured by their specific company) on the network.  This is a
   value add product they offer. 

   What people mean by print manager is software which manages printers.
   What you are describing in this section is not a print manager.

   This section should be called 'network print server proxy'.  
    
    In addition, a printer manager provides an evolutionary path for 
    service discovery deployment. For example, if an existing printer 
    does not support the zeroconf service discovery protocol, the 
    printer manager can use a legacy printer specific protocol to 
    learn the existence and characteristics of a printer then expose 
    that printer and its characteristics through the zeroconf service 
    discovery protocol. This allows new printer clients that support 
    the service discovery protocol to discover legacy printers that do 
    not support the zeroconf service discovery protocol. 
 
   This is true.

    A print manager requires a registry to cache information about 
    services and characteristics of services. Clients MUST be able to 
    extract data from the registry without knowledge that they are 
    talking to a registry. In other words, the client and server sides 
    of the service discovery protocol MUST NOT be any different 
    whether a registry is involved or not. Registry updates that 
    maintain the registry are required of the service discovery 
    protocol but are optionally implemented for a particular service; 
    this allows legacy protocols or the zeroconf service discovery 
    protocol to update and maintain the registry. 

   This is not true at all.  A network print server proxy could
   answer service discovery requests on behalf of a print client 
   directly, without requiring a registry.

   There are only operational reasons to deploy a service discovery
   registry, not functional ones.  Registries make service discovery
   more responsive, robust, administrable, and scale better.

Erik

---

From: Erik Guttman <[email-masked]>
Date: Wed, 9 Aug 2000 09:34:55 +0200 (MET DST)

>The excerpts from the draft below say SHOULD, not MUST. NBP, SLP, etc. don't
>include "going-off-line" notifications, but is this a reason that a protocol
>should not do this. (IGMP did not have the concept of leaving a group,
>IGMPv2 does.) To me, a "going-off-line" notification seems like a fine and
>reasonable thing for a service discovery protocol. 

If it isn't in AppleTalk/NBP, Netbios/SMB, nor SLP, why is it so reasonable?   
 There is a similar feature in IPX/SAP which involved updating the available
set of services every three minutes.  This was a major disaster as deployments
grew.  This was the principal reason SAP was abandoned!  Netware v5 uses SLP 
to support the same APIs as SAP - which shows that the going-off-line 
mechanism is not required to support the ***function***.

Other cases where it has been tried is in JINI which has RMI features 
to allow notification to scale (somewhat, since each subscriber gets 
a unicast notification) and SSDP which has no scaling features at all.  
Neither of these protocols are widely deployed and both would have trouble
scaling to networks with many services and many clients.

Experiments with notification in SLP have shown that to do it scalably 
requires significant state be kept in SAs and DAs in order to keep track 
of subscriptions (in order to send going-down notifications only when 
necessary) and the use of separate multicast groups for each notification. 
See 

  draft-kempf-srvloc-notify-03.txt

Feedback on SLP is that it should be less rather than more featureful, 
so requiring this feature will not go over well.  SLP notifications have
been envisioned as an optional extension - only for end to end applications
which really need it.

I therefore argue that we ***not*** require this (even as a SHOULD, which
means 'do it unless there is a good reason not to'.)  Someone MAY support 
this feature - but in this case, it has no place in a requirements document.

Erik

---

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 9 Aug 2000 09:38:41 -0700

> this feature - but in this case, it has no place in a 

You convinced me that the requirement should be removed.

-myron

---

From: "Nicolae, Dan" <[email-masked]>
Date: Wed, 09 Aug 2000 14:37:50 -0400

> 
> A _domain name_ is the name of a domain, and may or may not also
> coincidentally be a hostname.  It may or may not have dots in 
> it.  "us" is
> a domain name, for instance.
> 

A _domain name_ is the name of a _node_ in the DNS name space. 

A _domain_ is the portion of the DNS name space anchored at a particular
_node_. A _domain_ is referred to using the _domain name_ of the node where
the _domain_ is anchored.
"us" (without dots) is not a _domain name_, is just a DNS label. "us." (with
trailing dot) is a _domain name_.

Dots are omitted just to save typing or talking. Dots are always present on
the wire.

A DNS _host name_ is the _domain name_ of a _node_ that happens to represent
(among others) a physical host. Because it is a _domain name_ it always
includes the dots (it is fully qualified) on the wire. A _host name_ without
dots will be completed by the local software to a FQDN before being used on
the wire.

> A _fully qualified name_ is the combination of a hostname 
> (which may or
> may not contain dots) with a domain name (which may or may not contain
> dots), delimited by a dot.
>
A DNS hostname is a DNS domain name and it is always fully qualified (on the
wire and in the DNS name space). The local software (resolver) may use any
method to obtain a DNS hostname from the locally available information and
configuration. One particular method is to append to the UNIX hostname a DNS
domain name. UNIX or Windows etc. hostnames are different than DNS
hostnames. 
I agree with you that there is no way one can distinguish between a host
name and a domain name. 
So, unless the intention is to point out that zeroconf only cares about the
particular case when domain names are also host names, I would stick with
the more generic "Domain Name" term.

Other alternative is to use "DNS Host Name" but its meaning is not widely
accepted and understood.

My suggestion is to completely drop any implicit referral to the purpose
(connect to a host) and the protocol (DNS and IP) and simply use "Name to
Network Address Resolution". Focusing and giving examples on specific
protocols is OK, but at least the section name and the requirements should
be more generous with the terminology.

The above also applies to the other areas:
"Unicast Network Addressing Configuration" instead of "IP host
configuration"
"Multicast Network Addressing Configuration" instead of "IP multicast
address allocation"

I guess "Service Discovery" is as generic as it can be. The only problem is
that it spans the other areas. I mean that you can/could perform service
discovery using DHCP and DNS too.

Thanks,
dan

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 15 Aug 2000 19:51:31 -0700

>The excerpts from the draft below say SHOULD, not MUST. NBP,
>SLP, etc. don't include "going-off-line" notifications, but is
>this a reason that a protocol should not do this. (IGMP did not
>have the concept of leaving a group, IGMPv2 does.) To me, a
>"going-off-line" notification seems like a fine and reasonable
>thing for a service discovery protocol.

I think we need to focus on specifying the REQUIREMENTS for Zeroconf 
protocols, and *just* those things that are truly required. Adding in a 
list of additional nice-to-have features is not the role of this document.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer

---

From: "McDonald, Ira" <[email-masked]>
Date: Tue, 15 Aug 2000 19:52:01 -0700

Hi Stuart,

I agree - improving the capabilities of existing
protocols selected as part of a Zeroconf 'suite'
is NOT an appropriate goal for the ZC WG.  Take
'em as they are, please.

Cheers,
- Ira McDonald, consulting architect at Xerox and Sharp
  High North Inc

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 15 Aug 2000 19:56:47 -0700

>I wonder if we should add the requirement that there should be a way
>to discover the host names of all hosts on the local-link, at least
>all of the ones with zeroconf addresses?  Otherwise, you connect your
>computer to your neighbor's computer on the train to exchange data but 
>you don't know the name of the other computer unless you find out
>out-of-band.  Just a thought.

Service discovery covers this.

If you want to copy files using ftp, you don't want to find hosts on the 
network, you want to find services implementing the ftp protocol.

If you want to manage hosts using SNMP, you want to find services 
implementing the SNMP protocol.

If you want to long on to a host using telnet, you're actually looking 
for telnet services on the network.

I won't go on, but you get the point. Whenever you want to do anything 
useful with a host, you need to use a protocol, so what you're really 
looking for is entities that implement that protocol.

For diagnostic purposes, it may be useful to have the "I'm an IP host and 
I answer ping packets" service, which every Zeroconf host implements, but 
again that can and should be discovered with our chosen service discovery 
protocol, not some other different protocol.

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 15 Aug 2000 20:15:15 -0700

>As far as I know only senders join multicast groups, not
>receivers. If receivers don't join, they can't dealloc the
>address. I'll wait for others to comment.

In IGMP, it is receivers who join groups, but that is not the point. 
Joining a group and allocating a group address are not the same thing.

Allocating a group address is a logical management action, based on who 
is going to be using the multicast group and for what purpose. A sender 
or receiver could be responsible for it. Joining a group is an IGMP 
protocol action that tells routers to send packets your way because 
you're interested in that group address.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 17 Aug 2000 18:19:58 -0700

>Maybe, as Ross suggested, by examining a reasonably large set of examples 
>and sorting them into a "Not ZeroConf" pile and a "ZeroConf" pile, the 
>criteria will, ex post facto, stand out on their own. Once they are 
>perceived in agreement by the group, then you can write the charter.

Okay, my two zeroconf scenarios are:

1. A pair of zeroconf hosts, and nothing else.

2. A small number of hosts (<1000) on a single link, and nothing else.

My non-zeroconf scenario is:

Any IP internetwork with a router. If you've installed a router, then it 
might as well include a DHCP server to assign addresses, and however 
automatic or easy to use that might be made, the DHCP protocol already 
exists and the Zeroconf WG doesn't need to reinvent it.

That's not to say that zeroconf protocols won't run on such a network -- 
if we adopt a multicast name-to-address resolution protocol that uses 
admin-scoped multicast addresses, then such packets will span multiple 
segments.

"Being compatible with" and "solving all the problems of" multi-segment 
internetworks are not the same thing.