From owner-zeroconf@merit.edu Tue Aug 1 15:54:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27536 for ; Tue, 1 Aug 2000 15:54:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D80B65DD95; Tue, 1 Aug 2000 15:53:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C82075DD94; Tue, 1 Aug 2000 15:53:46 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id B3F515DD8E for ; Tue, 1 Aug 2000 15:53:45 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.1/8.10.1) with ESMTP id e71JrjQ15451 for ; Tue, 1 Aug 2000 15:53:45 -0400 Message-ID: <39872AC8.9634611@senie.com> Date: Tue, 01 Aug 2000 15:53:44 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.73 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: requirements -04 draft comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'd read and annotated the -04 draft this morning before the zeroconf session. Due to the time constraints and the direction the discussion went, I figured I'd post my commentaries rather than bring them up during the session. Some of these are nits, some are more substantial. 1.2.2 Transitions: Second paragraph. Last sentence is an example. As such, using MUST, capitalized, seems out of place. Such usage is for requirements, and I'd prefer if examples weren't held up as requirements. Phrase the requirements with MUST, MAY, SHOULD or whatever, then give examples. 1.2.3 Coexistence: This may be moot after the discussion today in the WG meeting, but in the last paragraph, the wording "MUST NOT be able to coexist" is awkward, and difficult to parse. Remove the words "be able to" and the meaning is the same, but less confusing. 2.1.1 Ping: I'm not sure why we have so much detail here on how hosts decide to route packets. This was mentioned briefly in the WG meeting. This is long-established methodology. Reference appropriate RFCs rather than re-describing it here. Also in this section, in the conclusions from the example, is a derived requirement that zeroconf hosts have the ability to determine the default route for the subnet. This is a requirement ONLY if there is a need to converse off the local subnet. For the much-discussed light bulb case, there may be no need for a default route. Seems like we're being too strong here. Peer networks come up and function with self-assignment today, and do so without any default routes. I think we should be careful about imposing requirements which aren't required in all cases. 2.1.4 Requirements Summary: Same comments on default route discovery. Also, there are legitimate uses for having more than one possible default route on a network. This is easy to do in manually configured environments, and has some uses. The text in this section seems to imply we'd always want to harmonize default routes, and I'm not sure that's true. 2.2 Domain Name to IP Address Resolution Issues: "The problem with DNS preventing DNS ..." change second DNS to "it". Later in that sentence, change "entering" to "configuration of". 2.2.1 Web Browsing: Just a note to keep in mind the degree to which DNS is inherent in today's applications. Applications including web browsers find it useful to implement DNS Resolver functionality in the application. This permits caching, and probably has other benefits. Changing the mechanism for name resolution will be painful. I'm not arguing to not do it, just reminding folks what's involved. It may be worth mentioning in the document that applications as well as operating systems and libraries will need revamping. 2.2.2 Domain Name Selection: There's talk here about having duplicate host names for load balancing. This seems to contradict the scalability statements earlier in the draft (which state that scalability is not an issue since we expect zeroconf to be on small networks only). If the scalability statement is to be believed, why are we even talking about load balancing and such. Those tend to be large network issues. We seem to have some consistency issues here. 2.2.5 Requirements Summary: "The ability to detect the presences ..." should be presence. 3. Security Considerations & Requirements "By definition security requires configuration." and later "... this section focuses on the minimal configuration necessary to make zeroconf protocols secure" This section appears to conflict with the definition of zeroconf at the top of the document. If we go with the definition of zeroconf at the top of the document, security is necessarily out of scope. I understand the desire to address this area, but the wording of this section and of the top of the document are at odds. Some more work is required to make this document consistent with itself. 3.6 IPv6 Considerations: The document seems to dismiss the need to do anything in the security area for IPv6 since IPv6 already has security. However, this security also requires configuration. As with the overall security section, we've got issues with document consistency and applicability. -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Tue Aug 8 09:33:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21171 for ; Tue, 8 Aug 2000 09:33:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B7EB5DDD0; Tue, 8 Aug 2000 09:32:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 06EAC5DDD9; Tue, 8 Aug 2000 09:32:34 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 5966F5DDD0 for ; Tue, 8 Aug 2000 09:32:32 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28012; Tue, 8 Aug 2000 06:32:27 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id PAA29847; Tue, 8 Aug 2000 15:32:21 +0200 (MET DST) Date: Tue, 8 Aug 2000 15:41:39 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: comments on requirements draft 04 To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, cheshire@apple.com, myron.hattig@intel.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id JAA21171 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 owner-zeroconf@merit.edu Tue Aug 8 10:05:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01146 for ; Tue, 8 Aug 2000 10:05:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FA4A5DDAE; Tue, 8 Aug 2000 10:05:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4D1A95DDDA; Tue, 8 Aug 2000 10:05:24 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 100015DDAE for ; Tue, 8 Aug 2000 10:05:23 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13860; Tue, 8 Aug 2000 07:05:15 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id QAA04960; Tue, 8 Aug 2000 16:05:06 +0200 (MET DST) Date: Tue, 8 Aug 2000 16:14:24 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: decision items for ZEROCONF WG list from IETF 48 To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, cheshire@apple.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following is a synopsis of the discusson at IETF 48. The minutes are still being prepared (and should appear within a week). I'm sending this to the list as soon as possible to generate discussion. I will surround in '*' marks all decisions, approved only in principal at the WG meeting, which require approval on the mailing list. ------------------------------------------------------------------------ The agenda of the meeting was: 1. Discuss rechartering the WG 2. Discuss issues with requirements draft 04. ------------------------------------------------------------------------ 1. Rechartering discussion . Further Work (on zeroconf protocols) Area Protocol Status Host Autoconf IP Host Address Draft Standard Autoconf for IPv6 IP Host Address 2 Internet Drafts Autoconf for IPv4 NOT in DHC WG (no WG) Name to Address Resolution IPv6 Node Information Internet Draft (IPNG WG) Queries Multicast DNS Internet Draft (DNSEXT WG) Service Discovery (both are defined for IPv4 and IPv6) Service Location Proposed Standard (SVRLOC WG) Protocol, Version 2 DNS SRV RR Proposed Standard (DNSEXT WG) Multicast Addresss Allocation (will be defined for IPv4 and IPv6) Address Allocation Internet Draft (no WG) Protocol for Zeroconf networks (AAPZ) The only two work items which have no home are AAPZ and IPv4 autoconf. The concensus at the WG meeting was to take on these work items. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Expand the ZEROCONF WG charter with *** *** the following goals: *** *** *** *** - Submit Autoconf IPv4 (to Prop. Std.) *** *** - Submit MC Addr Allocation Protocol *** *** (to Prop. Std.) *** *** *** *********************************************** *********************************************** . The proposed revised charter goals were the following: *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** New list of ZEROCONF WG milestones: *** *** *** *** 09/00 Submit Zeroconf Reqts to IESG *** *** (to Informational RFC) *** *** 12/00 Submit Autoconf IPv4 *** *** (to Proposed Standard RFC) *** *** 12/00 Submit MC Addr Allocation *** *** Protocol *** *** (to Proposed Standard RFC) *** *** 03/01 Submit Zeroconf Requirements *** *** (to Informational RFC) *** *** *** *********************************************** *********************************************** ------------------------------------------------------------------------ 2. Comments on Zeroconf Requirements . Currently the Requirements state that a host MUST transition to configured operation. Shouldn't we instead say that a host MAY transition to configured operation. Arguments pro: + Some hosts may never want to be configured. + Allows local connections to persist even if configuration is possible (ie. DHCP comes up). + Does not create any arbitrary requirements - leave policy up to the implementors. Arguments contra: + This is more complicated: It leads to a scoped address architecture, as per IPv6: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-01.txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt + This may lead to different host behavior than is implemented now. Some may not like the new behavior. The WG meeting concensus was to expand the charter to allow transition and detection of infrastructure to be optional. There were only two dissenters, who expressed they thought that this would reduce our chances of completing our work in a timely way. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Hosts MAY transition to configured *** *** operation. *** *** *** *** This change will require a new set *** *** of requirements to make sure that *** *** coexistence of zeroconf and non- *** *** zeroconf configuration will neither *** *** interfere with existing IP networks *** *** nor lead to difficulties in the *** *** implementation and interoperability *** *** of IP hosts. *** *** *** *********************************************** *********************************************** . Periodic messages are not the requirement. Detecting state change (and allocation conflicts) is the requirement. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Change language in the reqts draft *** *** requiring periodic messages to a *** *** requirement to detect and correct *** *** conflicts and state changes in a *** *** timely way. *** *** *** *********************************************** *********************************************** Periodic messages should not be sent by hosts if at all possible. Hosts which are not communicating should ideally not be sending any messages at all. . Once you deploy a server which configures hosts, this is not a zeroconf protocol. This was widely agreed to at the WG meeting. This could potentially change the requirements document, so let's agree to it on the list. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Protocols in which a server configures *** *** hosts (which are clients of that *** *** protocol) are not zeroconf protocols. *** *** *** *********************************************** *********************************************** It is a separate question whether the servers which are configuring other hosts (say mini-DHCP servers) are themselves automatically configured. What we mean by a zeroconf protocol is that it is peer to peer (no host is acting as a configuration server). The act of turning on such a configuration server is in effect 'configuring' the network. The implication is that DHCP, MADCAP and DNS are not zeroconf protocols, though they may perhaps automaticly configure their server state. ------------------------------------------------------------------------- There are no doubt other discussion issues which will arise from the minutes when they are published. I wanted to start the ball rolling on these 'decision items' ASAP. Please send your comments in the next 2 weeks (before 22/08). Erik Guttman ZEROCONF WG cochair From owner-zeroconf@merit.edu Tue Aug 8 10:29:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10034 for ; Tue, 8 Aug 2000 10:29:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05DC25DDDD; Tue, 8 Aug 2000 10:29:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E77AE5DDE2; Tue, 8 Aug 2000 10:29:19 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B881C5DDDD for ; Tue, 8 Aug 2000 10:29:18 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26277; Tue, 8 Aug 2000 07:29:13 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id QAA08851; Tue, 8 Aug 2000 16:29:08 +0200 (MET DST) Date: Tue, 8 Aug 2000 16:38:25 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: proposed new charter text To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, cheshire@apple.com, Thomas Narten , Erik Nordmark Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following is a revised charter document. The changes from the existing charter are indicated by change bars in the right column. The original text is included as well, for comparison. Please discuss. Erik --------------------------------------------------------------------------- The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train. ZEROCONF requirements will make networking as easy as possible, but no easier. In some cases other considerations may dominate ease of use. For example, network security requires some configuration which may not be as easy as the unacceptable alternative of 'no security.' Networks where ZEROCONF protocols apply can include (but are not limited to) environments where no DHCP, MADCAP or DNS servers are present. This working group will address both IPv4 and IPv6. Many functions which are not of fundamental importance to host and application configuration are outside the scope of the working group. This is not because there are no other problems to solve for networking in an environment without preexisting configuration. | WAS: | for networking in an environment without administration. This | This working group will focus on an achievable subset of these problems. The ZEROCONF WG will precisely define the requirements for each of the following functions: * Automatic Host Configuration (IP address, network prefix, gateway router location, DNS server location) * Name-to-Address Translation * Service Discovery * Automatic allocation of Multicast Addresses * Sufficient security features to prevent networks | from being any less secure than networks which do not use | ZEROCONF protocols | | WAS: | * Sufficient security features to prevent ZEROCONF netoworks | from being abused | The working group will define the requirements to provide these functions on two distinct network topologies: 1. A single network segment, where all hosts are reachable by link-layer broadcast or multicast messages. 2. A set of network segments, (on different IP subnetworks) interconnected by a single router. Automatic configuration of an arbitrary topology of routers and subnets is out of the scope of the ZEROCONF WG charter. The working group will also define how such a network may | WAS: | The working group will also define how such a network will | automatically transition from 'configured' to 'unconfigured' | behavior, as well as from 'unconfigured' to 'configured'. | WAS: | automatically transition from 'administered' to 'unadministered' | behavior, as well as from 'unadministered' to 'administered'. | That is, the same hosts must be able to function on networks with no configuration as well as be capable of direct IP connectivity to the global Internet, including DNS entries supplied through standard DNS services. It is also possible that both modes (ZEROCONF and administered) may coexist on the same network; the modes may not be exclusive of each other. When ZEROCONF networks or hosts which are configured using ZEROCONF protocols are connected to the big 'I' internet, they should not automatically become vulnerable to new security threats. This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. The second, which follows the first, will detail a 'profile' specifying which standards specifically satisfy ZEROCONF requirements. The WG will also produce protocol specifications for Automatic | Address Configuration for IPv4 and a Multicast Address Allocation | Protocol for IPv4 and IPv6. | WAS: | The WG will not engage in any new protocol work. If there | is no existing standard protocol which satisfies ZEROCONF | requirements, the profile document may specify that a new | protocol should be developed or recommend a change to an | existing standard to apply to the ZEROCONF environment. | Goals and Milestones: Sep 00 | WAS: | Mar 00 | Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. | WAS: | RFC on Requirements for Zero Administration Networking. | Dec 00 | | Submit Automatic Address Configuration for IPv4 to be | considered as a Standards Track RFC. | | Dec 00 | | Submit Multicast Address Allocation Protocol for Zeroconf | Networks to be considered as a Standards Track RFC. | Mar 01 | WAS: | Jul 00 | Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking. | WAS: | RFC on Host Profile for Zero Administration Networking. | If this profile cannot be written since required | protocols are not yet standardized, recharter or | dismiss the ZEROCONF WG. RFC on Host Profile for | Zero Administration Networking. | From owner-zeroconf@merit.edu Tue Aug 8 13:52:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22327 for ; Tue, 8 Aug 2000 13:52:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBCD65DDC9; Tue, 8 Aug 2000 13:52:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA1865DDA3; Tue, 8 Aug 2000 13:52:02 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 3995F5DDA1 for ; Tue, 8 Aug 2000 13:52:01 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id KAA25287; Tue, 8 Aug 2000 10:52:31 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Aug 2000 10:51:54 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE46@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Erik Guttman'" , zeroconf@merit.edu Cc: cheshire@apple.com Subject: RE: decision items for ZEROCONF WG list from IETF 48 Date: Tue, 8 Aug 2000 10:51:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Erik, I just read all of your decision items (below) and agree with all of them. I also read through your previous message about proposed changes to the ZC Reqts doc and agree with all of them. I think defining Autoconf IPv4 is *very* high priority for vendors of network products and operating systems. Good work, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] Sent: Tuesday, August 08, 2000 7:14 AM To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com; cheshire@apple.com Subject: decision items for ZEROCONF WG list from IETF 48 The following is a synopsis of the discusson at IETF 48. The minutes are still being prepared (and should appear within a week). I'm sending this to the list as soon as possible to generate discussion. I will surround in '*' marks all decisions, approved only in principal at the WG meeting, which require approval on the mailing list. ------------------------------------------------------------------------ The agenda of the meeting was: 1. Discuss rechartering the WG 2. Discuss issues with requirements draft 04. ------------------------------------------------------------------------ 1. Rechartering discussion . Further Work (on zeroconf protocols) Area Protocol Status Host Autoconf IP Host Address Draft Standard Autoconf for IPv6 IP Host Address 2 Internet Drafts Autoconf for IPv4 NOT in DHC WG (no WG) Name to Address Resolution IPv6 Node Information Internet Draft (IPNG WG) Queries Multicast DNS Internet Draft (DNSEXT WG) Service Discovery (both are defined for IPv4 and IPv6) Service Location Proposed Standard (SVRLOC WG) Protocol, Version 2 DNS SRV RR Proposed Standard (DNSEXT WG) Multicast Addresss Allocation (will be defined for IPv4 and IPv6) Address Allocation Internet Draft (no WG) Protocol for Zeroconf networks (AAPZ) The only two work items which have no home are AAPZ and IPv4 autoconf. The concensus at the WG meeting was to take on these work items. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Expand the ZEROCONF WG charter with *** *** the following goals: *** *** *** *** - Submit Autoconf IPv4 (to Prop. Std.) *** *** - Submit MC Addr Allocation Protocol *** *** (to Prop. Std.) *** *** *** *********************************************** *********************************************** . The proposed revised charter goals were the following: *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** New list of ZEROCONF WG milestones: *** *** *** *** 09/00 Submit Zeroconf Reqts to IESG *** *** (to Informational RFC) *** *** 12/00 Submit Autoconf IPv4 *** *** (to Proposed Standard RFC) *** *** 12/00 Submit MC Addr Allocation *** *** Protocol *** *** (to Proposed Standard RFC) *** *** 03/01 Submit Zeroconf Requirements *** *** (to Informational RFC) *** *** *** *********************************************** *********************************************** ------------------------------------------------------------------------ 2. Comments on Zeroconf Requirements . Currently the Requirements state that a host MUST transition to configured operation. Shouldn't we instead say that a host MAY transition to configured operation. Arguments pro: + Some hosts may never want to be configured. + Allows local connections to persist even if configuration is possible (ie. DHCP comes up). + Does not create any arbitrary requirements - leave policy up to the implementors. Arguments contra: + This is more complicated: It leads to a scoped address architecture, as per IPv6: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-default-addr-select-01. txt ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-01.txt + This may lead to different host behavior than is implemented now. Some may not like the new behavior. The WG meeting concensus was to expand the charter to allow transition and detection of infrastructure to be optional. There were only two dissenters, who expressed they thought that this would reduce our chances of completing our work in a timely way. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Hosts MAY transition to configured *** *** operation. *** *** *** *** This change will require a new set *** *** of requirements to make sure that *** *** coexistence of zeroconf and non- *** *** zeroconf configuration will neither *** *** interfere with existing IP networks *** *** nor lead to difficulties in the *** *** implementation and interoperability *** *** of IP hosts. *** *** *** *********************************************** *********************************************** . Periodic messages are not the requirement. Detecting state change (and allocation conflicts) is the requirement. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Change language in the reqts draft *** *** requiring periodic messages to a *** *** requirement to detect and correct *** *** conflicts and state changes in a *** *** timely way. *** *** *** *********************************************** *********************************************** Periodic messages should not be sent by hosts if at all possible. Hosts which are not communicating should ideally not be sending any messages at all. . Once you deploy a server which configures hosts, this is not a zeroconf protocol. This was widely agreed to at the WG meeting. This could potentially change the requirements document, so let's agree to it on the list. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Protocols in which a server configures *** *** hosts (which are clients of that *** *** protocol) are not zeroconf protocols. *** *** *** *********************************************** *********************************************** It is a separate question whether the servers which are configuring other hosts (say mini-DHCP servers) are themselves automatically configured. What we mean by a zeroconf protocol is that it is peer to peer (no host is acting as a configuration server). The act of turning on such a configuration server is in effect 'configuring' the network. The implication is that DHCP, MADCAP and DNS are not zeroconf protocols, though they may perhaps automaticly configure their server state. ------------------------------------------------------------------------- There are no doubt other discussion issues which will arise from the minutes when they are published. I wanted to start the ball rolling on these 'decision items' ASAP. Please send your comments in the next 2 weeks (before 22/08). Erik Guttman ZEROCONF WG cochair From owner-zeroconf@merit.edu Tue Aug 8 19:07:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16388 for ; Tue, 8 Aug 2000 19:07:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13C775DD8D; Tue, 8 Aug 2000 19:06:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F17085DD9A; Tue, 8 Aug 2000 19:06:53 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 853F45DD8D for ; Tue, 8 Aug 2000 19:06:50 -0400 (EDT) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id XAA26770 for ; Tue, 8 Aug 2000 23:07:41 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 Aug 2000 23:06:43 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id <3X9RVPZM>; Tue, 8 Aug 2000 16:05:55 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B5E@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: zeroconf@merit.edu Subject: RE: comments on requirements draft 04 Date: Tue, 8 Aug 2000 16:05:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk It's great to have this level of feedback and comments!! I look forward to more discussion following. Just to let people know, I've started on a version 5 and have already made some changes based on the comments. I'll post version 5 when Stuart and Erik think the discussion and the text have settled enough to make a version 5 worth posting. > 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 disagree. I'll follow up with additional email. > 2. Is reconfiguration required when infrastructure detected? Agree 100% that this should be MAY instead of MUST. This is changed in version 5. Does anyone disagree with this? > 3. Host name (not domain name) to IP Address Resolution This change seems worth trying. Opinions? > 3. IP Host configuration is defined in terms of default routers, > IP subnets, and subnet masks. This is inappropriate. I agree with some of the below comments, but not all of them. True, a default route is not a required configuration parameter for communication on the local IP subnet - this is true for link local or non-link local addressing. The text in the draft was meant to clearup previous confusing discussions. I'll remove the text that describes sending a packet, but we still need to walk through the issues because the comments below show that we're still not on the same page. I'll bring this up in another mail with a focus on this comment: > 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). > 5. Several places in the document discuss periodic messages. This is > *not* the requirement - in fact it is a highly > undesirable protocol > feature. Where is the requirement for a periodic message. Periodic actions ARE required. I agree with the comments: > 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 statement: > The requirement is detection of conflicts after allocation, not that > periodic messages be sent. is not accurate. There are no requirements for periodic messages. I'll let someone else pick up this thread if further discussion is needed. > 6. Service discovery protocol requirements include notification that > a service is going off line. 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. > 7. As discussed on the mailing list, we will be silent with > respect to > secure IP Host Configuration (ARP, IPv6 neighbor discovery, DHCP, > etc.) ... > For this reason, section 3.1 should be dropped. Agreed and apply this to entire security section - the section should change significantly. See version 5. > 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. This has semantic problems similar to earlier versions of the text. Specifically, everyone had their own favorite definition of zero configuration networking which included some network topologies and excluded others. I don't remember who it was, but someone clearly pointed out (and garnered support from others on the list) that we should focus on protocols - not on networking and not on network topologies. > b. Replace some text for clarity > > I like Stuart's formulation more. I like Stuart's text better also. It is in version 5. > c. Scalability is not the primary concern, but it is still a > concern for > zeroconf network protocols. I'll work on this section. See version 5. > d. The following text makes it sound as if a boundary router > is required > for networks which use Zeroconf protocols: Good catch. Text will change. > 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. I'm not sure what part of the text is unclear. The comment appears to understand the text. Perhaps the comment is meant to say the text is obvious therefore unnecessary. Please provide more input. > 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. Yes this is unclear, I'll try again. See version 5. > 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. Good point. They will be moved. > 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. 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. > j. The 'Print Manager' example has problems. Unless someone objects, I'll change the text as suggested. -myron From owner-zeroconf@merit.edu Tue Aug 8 19:15:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20347 for ; Tue, 8 Aug 2000 19:15:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCBBD5DDC9; Tue, 8 Aug 2000 19:14:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BB2F45DDAC; Tue, 8 Aug 2000 19:14:55 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 4A06D5DD9A for ; Tue, 8 Aug 2000 19:14:54 -0400 (EDT) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id XAA01194 for ; Tue, 8 Aug 2000 23:15:51 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 08 Aug 2000 23:14:53 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id <3X9RVQDG>; Tue, 8 Aug 2000 16:13:57 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B5F@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: zeroconf@merit.edu Subject: zc = no server? Date: Tue, 8 Aug 2000 16:10:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk > 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. After struggling with this for a long time, my conclusion is that the existents of a server isn't the issue. The issue is USER configuration. In other words, ease of use for the user is the only concern. The server may exist but if the user doesn't see it, it doesn't matter. -myron From owner-zeroconf@merit.edu Tue Aug 8 19:23:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24287 for ; Tue, 8 Aug 2000 19:23:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 89F645DE0D; Tue, 8 Aug 2000 19:23:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 778425DE0E; Tue, 8 Aug 2000 19:23:09 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id CE72D5DE0D for ; Tue, 8 Aug 2000 19:23:07 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id QAA00324; Tue, 8 Aug 2000 16:23:40 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Tue, 8 Aug 2000 16:23:03 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE4B@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Hattig, Myron'" , zeroconf@merit.edu Subject: RE: zc = no server? Date: Tue, 8 Aug 2000 16:22:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Hy Mryon, I disagree completely. All this 'gray area' is the problem with all previous definitions of ZC. The IETF ADs are unlikely to accept word-smithing that allows ZC clients to be 'a little bit pregnant...'. I think Erik's got it just right - ZC means ABSOLUTELY no external configuration, *in particular* no fetching from routers, service repositories, etc. My two cents, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Hattig, Myron [mailto:myron.hattig@intel.com] Sent: Tuesday, August 08, 2000 4:10 PM To: zeroconf@merit.edu Subject: zc = no server? > 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. After struggling with this for a long time, my conclusion is that the existents of a server isn't the issue. The issue is USER configuration. In other words, ease of use for the user is the only concern. The server may exist but if the user doesn't see it, it doesn't matter. -myron From owner-zeroconf@merit.edu Tue Aug 8 19:28:28 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26825 for ; Tue, 8 Aug 2000 19:28:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 967945DD8D; Tue, 8 Aug 2000 19:28:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 82E2D5DDAC; Tue, 8 Aug 2000 19:28:18 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by segue.merit.edu (Postfix) with ESMTP id 0482F5DD8D for ; Tue, 8 Aug 2000 19:28:15 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.3/8.9.2) id QAA08339; Tue, 8 Aug 2000 16:28:09 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14736.38790.807404.604625@kitab.cisco.com> Date: Tue, 8 Aug 2000 16:28:06 -0700 (PDT) To: zeroconf@merit.edu Subject: RE: comments on requirements draft 04 In-Reply-To: <4148FEAAD879D311AC5700A0C969E8904F2B5E@orsmsx35.jf.intel.com> References: <4148FEAAD879D311AC5700A0C969E8904F2B5E@orsmsx35.jf.intel.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hattig, Myron writes: > > 3. Host name (not domain name) to IP Address Resolution > > This change seems worth trying. Opinions? Agreed. A "host name" is not a "domain name" unless it's in "domain name" format; i.e. contains dots. A "domain name" is not a "host name" unless it's being used to name a host. 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. I also wonder if we should add that the user should be given the option of configuring a zeroconf address and joining a network before actually doing so, unless the user has already specified in some way that the host should automatically configure zeroconf addresses and join all networks. I'm worried about having one's laptop simply automatically joining all Wavelan networks in range, whether or not the user really wants this. Of course, printers purchased for home use would want to automatically join the network when plugged in. It's a trade off. Maybe it's a security issue about which we should be silent? /raj From owner-zeroconf@merit.edu Wed Aug 9 02:44:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01782 for ; Wed, 9 Aug 2000 02:44:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 92DF95DDA8; Wed, 9 Aug 2000 02:44:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C5725DDB2; Wed, 9 Aug 2000 02:44:16 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 234E85DDA8 for ; Wed, 9 Aug 2000 02:44:15 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA28525; Tue, 8 Aug 2000 23:44:07 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id IAA11210; Wed, 9 Aug 2000 08:44:05 +0200 (MET DST) Date: Wed, 9 Aug 2000 08:53:23 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: periodic messages (was RE: comments on requirements draft 04) To: "Hattig, Myron" Cc: zeroconf@merit.edu, erik.guttman@germany.sun.com, cheshire@apple.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > > 5. Several places in the document discuss periodic messages. This is > > *not* the requirement - in fact it is a highly > > undesirable protocol > > feature. > > Where is the requirement for a periodic message. In draft 4: These scenarios require the periodic actions as well as specific actions at startup. - The ability to detect the presence or absence of a DHCP server at startup of a device and periodically after a devices starts. - The ability to periodically ensure the uniqueness of a selected host name. - 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. - The ability to detect the presence or absence of a MADCAP server at startup of a device and periodically after a devices starts. - 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. > Periodic actions ARE required. Why are periodic messages required? Imagine we have a situation where there is duplicate configuration, but no communication. In this case, we do not need to detect the situation at all. Once there is communication the detection of the duplicates should be swift. That is the meaning of my comments which follow: > I agree with the comments: > > > 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 statement: > > The requirement is detection of conflicts after allocation, not that > > periodic messages be sent. > is not accurate. There are no requirements for periodic messages. > > I'll let someone else pick up this thread if further discussion is needed. Please note there has been extensive research in this area showing that periodic messages are a complete disaster. Do you want references? Just because periodic messages are currently used doesn't mean its a good idea. For instance, current Autoconf IPv4 clients periodically request DHCP servers by sending DHCP DISCOVER messages. This could be improved by having DHCP servers announce themselves periodically. So rather than n broadcasts you have 1, per time interval. I maintain the requirement is timely detection of conflicts and the ability to resolve them, as well as the ability to detect newly available infrastructure. This should be done as efficiently as possible. Maybe we will be stuck with having each host poll the network with broadcasts. I hope not & certainly maintain we can't require that they do. Erik From owner-zeroconf@merit.edu Wed Aug 9 08:00:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10132 for ; Wed, 9 Aug 2000 08:00:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C0485DD9C; Wed, 9 Aug 2000 03:07:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49B8B5DDB2; Wed, 9 Aug 2000 03:07:03 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1E2A25DD9C for ; Wed, 9 Aug 2000 03:06:57 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA03668; Wed, 9 Aug 2000 00:06:54 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA13987; Wed, 9 Aug 2000 09:06:53 +0200 (MET DST) Date: Wed, 9 Aug 2000 09:16:11 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: comments on requirements draft 04 To: Richard Johnson , bmanning@isi.edu Cc: zeroconf@merit.edu In-Reply-To: "Your message with ID" <14736.38790.807404.604625@kitab.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Hattig, Myron writes: > > > 3. Host name (not domain name) to IP Address Resolution > > > > This change seems worth trying. Opinions? > > Agreed. A "host name" is not a "domain name" unless it's in "domain > name" format; i.e. contains dots. A "domain name" is not a "host > name" unless it's being used to name a host. Let's find out what this distinction has meant historically before we wander into any pits. Bill, can you help us out here? > 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. We are trying not to add any requirements above and beyond what we need to support features we already have, and have come to expect in non-IP zeroconf protocols like Appletalk/NBP, NetBeui/SMB, IPX/SAP. We need host config, name to address resolution, service discovery. We are also looking at MADCAP function in the absence of MADCAP servers - but that's the extent of what we are chartered to do. > I also wonder if we should add that the user should be given the > option of configuring a zeroconf address and joining a network before > actually doing so, unless the user has already specified in some way > that the host should automatically configure zeroconf addresses and > join all networks. I'm worried about having one's laptop simply > automatically joining all Wavelan networks in range, whether or not > the user really wants this. Of course, printers purchased for home > use would want to automatically join the network when plugged in. > It's a trade off. Maybe it's a security issue about which we should > be silent? No host is required to do anything unless it is configured to use an IP network, then IETF RFCs apply. Erik From owner-zeroconf@merit.edu Wed Aug 9 08:00:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10137 for ; Wed, 9 Aug 2000 08:00:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1314D5DDA8; Wed, 9 Aug 2000 03:44:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E508B5DDB4; Wed, 9 Aug 2000 03:44:03 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 82EEB5DDA8 for ; Wed, 9 Aug 2000 03:44:02 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA13282; Wed, 9 Aug 2000 00:44:00 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA17931; Wed, 9 Aug 2000 09:43:58 +0200 (MET DST) Date: Wed, 9 Aug 2000 09:53:16 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: mc addr deallocation (was RE: comments on requirements draft 04) To: "Hattig, Myron" , Dave Thaler Cc: zeroconf@merit.edu, erik.guttman@germany.sun.com In-Reply-To: "Your message with ID" <4148FEAAD879D311AC5700A0C969E8904F2B5E@orsmsx35.jf.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > The text should simply add 'or group member' where it says source > > and I think it would work. > > 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. You have it backwards. Receivers join mc groups - which initiates IGMP messages, for example. Senders merely use mc destination addresses. The point is subtle, though. The point of allocating a mc address is to distinguish one session from another - to keep them from colliding. Who knows what constitutes a session? Those who will send or those who will receive? I assert this is application dependent and Dave Thaler (who wrote the text above) will likely agree. Dave? Erik From owner-zeroconf@merit.edu Wed Aug 9 08:00:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10145 for ; Wed, 9 Aug 2000 08:00:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E6C75DDBA; Wed, 9 Aug 2000 03:25:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5CD1B5DDB4; Wed, 9 Aug 2000 03:25:54 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 061C15DDA8 for ; Wed, 9 Aug 2000 03:25:53 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08378; Wed, 9 Aug 2000 00:25:39 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA16018; Wed, 9 Aug 2000 09:25:37 +0200 (MET DST) Date: Wed, 9 Aug 2000 09:34:55 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: comments on requirements draft 04 To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, myron.hattig@intel.com, cheshire@apple.com, srvloc@srvloc.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk >> 6. Service discovery protocol requirements include notification that >> a service is going off line. > >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 owner-zeroconf@merit.edu Wed Aug 9 08:00:05 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10170 for ; Wed, 9 Aug 2000 08:00:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 557055DDB4; Wed, 9 Aug 2000 03:47:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 40EFC5DDBF; Wed, 9 Aug 2000 03:47:22 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id CD5D35DDB4 for ; Wed, 9 Aug 2000 03:47:20 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA14298; Wed, 9 Aug 2000 00:47:19 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA18301; Wed, 9 Aug 2000 09:47:16 +0200 (MET DST) Date: Wed, 9 Aug 2000 09:56:34 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: unclear text discussion (was RE: comments on requirements draft 04) To: myron.hattig@intel.com Cc: erik.guttman@germany.sun.com, zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > 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. > > I'm not sure what part of the text is unclear. The comment appears to > understand the text. Perhaps the comment is meant to say the text is obvious > therefore unnecessary. Please provide more input. I don't understand what competing netmask and default routes mean. I know of no link-local automatic IP configuration mechanism which use different network prefixes on different links. These protocols eliminate ambiguity for hosts using the same mechanism, so that it is always possible to transmit packets to hosts on the same link. Therefore - how could there be competing netmasks? Second - competing default routes simply makes no sense. As long as the default route works, its good. There's no need for this configuration to be consistent. As I suggested in my comments, I don't think subnet masks should be discussed in the reqts doc anyway. Default route configuration is needed by hosts, if it is possible to obtain. It should therefore be required that hosts can detect default routes. Detecting routers as they become available could be implemented various ways (hosts listening for router adverts, hosts using DHCP, etc etc) but this is out of scope for the reqts doc - it is material for the profile doc to come. Erik From owner-zeroconf@merit.edu Wed Aug 9 09:22:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10135 for ; Wed, 9 Aug 2000 08:00:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CCBE5DDB2; Wed, 9 Aug 2000 03:14:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 393135DDB4; Wed, 9 Aug 2000 03:14:44 -0400 (EDT) Received: from smtp1.zocalo.net (smtp1.zocalo.net [157.22.1.67]) by segue.merit.edu (Postfix) with ESMTP id 4781B5DDB2 for ; Wed, 9 Aug 2000 03:14:42 -0400 (EDT) Received: from secure (secure [157.22.1.13]) by smtp1.zocalo.net (8.9.1/8.9.1) with SMTP id AAA26940; Wed, 9 Aug 2000 00:16:40 -0700 (PDT) Date: Wed, 9 Aug 2000 00:15:39 -0700 (PDT) From: Bill Woodcock X-Sender: woody@secure To: Erik Guttman Cc: Richard Johnson , bmanning@isi.edu, zeroconf@merit.edu Subject: RE: comments on requirements draft 04 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > > > 3. Host name (not domain name) to IP Address Resolution > > > > > > This change seems worth trying. Opinions? > > > > Agreed. A "host name" is not a "domain name" unless it's in "domain > > name" format; i.e. contains dots. A "domain name" is not a "host > > name" unless it's being used to name a host. > > Let's find out what this distinction has meant historically > before we wander into any pits. > Bill, can you help us out here? I'll take advantage of the infamous Bill Anycast Protocol to interject here... A _hostname_ is the name of a host, pure and simple. It may or may not have dots in it. 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 _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. None of these are distinguishable algorithmically, without access to the Internet DNS hierarchy for actual testing of specific instances. A domain name cannot be distinguished from a host name in any case. A name can be determined to be _not a domain name_, or a _fully qualified name_ via testing against the DNS. I don't believe any other determinations can be made. -Bill From owner-zeroconf@MERIT.EDU Wed Aug 9 09:22:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10134 for ; Wed, 9 Aug 2000 08:00:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7941A5DDB7; Wed, 9 Aug 2000 02:55:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 680415DDB4; Wed, 9 Aug 2000 02:55:17 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1113E5DDB2 for ; Wed, 9 Aug 2000 02:55:16 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00962; Tue, 8 Aug 2000 23:55:03 -0700 (PDT) Received: from vayne (muc-isdn-10 [129.157.164.110]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id IAA12400; Wed, 9 Aug 2000 08:55:01 +0200 (MET DST) Date: Wed, 9 Aug 2000 09:04:19 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: decision item for ZEROCONF WG: What is zeroconf? To: zeroconf@MERIT.EDU Cc: erik.guttman@germany.sun.com, cheshire@apple.com, myron.hattig@intel.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@MERIT.EDU Precedence: bulk In my comments on draft 4 of the requirements, I objected to the text in draft defining what a zeroconf protocol is. This is of such fundamental importance to the WG, I want a formal decision. The definition in draft 03 was: A zeroconf protocol requires no user configuration and does not rely on information received from a centralized server. A non-zeroconf protocol requires user configuration or relies on information received from a centralized server. The definition in draft 04 is: A zeroconf protocol requires no user configuration. A non-zeroconf protocol requires user configuration. I believe this is a wrong turn. The 03 definition is far closer to what I think we mean by 'zero configuration' - namely, a host comes up with no configuration but contains software which can collaboratively obtain configuration state from the network. If there is a server on the network which configures the host (a client-server dynamic configuration protocol), the host is not collaborating to configure itself. We no longer are generating configuration but obtaining it. The definition I propose is: 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.) *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Decide on which formulation of the *** *** definition of a zeroconf protocol. *** *** *** *** Choose version 03, 04 or Erik's. *** *** *** *********************************************** *********************************************** Please send your comments to the list in the next two weeks. Erik From owner-zeroconf@merit.edu Wed Aug 9 10:39:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04278 for ; Wed, 9 Aug 2000 10:39:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20A605DDD1; Wed, 9 Aug 2000 10:37:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 01D595DDE5; Wed, 9 Aug 2000 10:37:07 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 5CDFB5DDD1 for ; Wed, 9 Aug 2000 10:36:56 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA22178 for ; Wed, 9 Aug 2000 07:36:55 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id HAA14860 for ; Wed, 9 Aug 2000 07:36:55 -0700 (MST)] Received: from dma.isg.mot.com (bigdog.dma.isg.mot.com [150.21.2.47]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id KAA15516 for ; Wed, 9 Aug 2000 10:36:54 -0400 (EDT) Message-Id: <200008091436.KAA15516@noah.dma.isg.mot.com> To: zeroconf@merit.edu Subject: Re: decision item for ZEROCONF WG: What is zeroconf? In-reply-to: Your message of "Wed, 09 Aug 2000 09:04:19 EDT." Date: Wed, 09 Aug 2000 10:36:54 -0400 From: "Donald E. Eastlake 3rd" Sender: owner-zeroconf@merit.edu Precedence: bulk Given the choices offered, I would go with -03. Erik's version has merit but I think it is too wordy, I'd prefer to minimize the latin, and I see no problem with zeroconf using "configuration" burned into hardware such as serial numbers, MAC addresses, public-private key pairs, etc. although perhpas that is not what we mean by "configuration" and is more like "identity"... Thanks, Donald From: Erik Guttman Date: Wed, 9 Aug 2000 09:04:19 +0200 (MET DST) To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, cheshire@apple.com, myron.hattig@intel.com Message-ID: >In my comments on draft 4 of the requirements, I objected to >the text in draft defining what a zeroconf protocol is. This >is of such fundamental importance to the WG, I want a formal >decision. > >The definition in draft 03 was: > > A zeroconf protocol requires no user configuration and does not > rely on information received from a centralized server. > > A non-zeroconf protocol requires user configuration or relies on > information received from a centralized server. > >The definition in draft 04 is: > > A zeroconf protocol requires no user configuration. > > A non-zeroconf protocol requires user configuration. > >I believe this is a wrong turn. The 03 definition is far closer to >what I think we mean by 'zero configuration' - namely, a host comes >up with no configuration but contains software which can collaboratively >obtain configuration state from the network. If there is a server on the >network which configures the host (a client-server dynamic configuration >protocol), the host is not collaborating to configure itself. We no longer >are generating configuration but obtaining it. > >The definition I propose is: > > 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.) > > *********************************************** > *********************************************** > *** For WG mailing list approval *** > *** *** > *** Decide on which formulation of the *** > *** definition of a zeroconf protocol. *** > *** *** > *** Choose version 03, 04 or Erik's. *** > *** *** > *********************************************** > *********************************************** > >Please send your comments to the list in the next two weeks. > >Erik From owner-zeroconf@merit.edu Wed Aug 9 11:28:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08832 for ; Wed, 9 Aug 2000 11:27:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB8CC5DE11; Wed, 9 Aug 2000 11:27:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99FA35DE10; Wed, 9 Aug 2000 11:27:48 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 335365DE0E for ; Wed, 9 Aug 2000 11:27:47 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.1/8.10.1) with ESMTP id e79FR5Q11269; Wed, 9 Aug 2000 11:27:09 -0400 Message-ID: <39917849.8CEB9CCB@senie.com> Date: Wed, 09 Aug 2000 11:27:05 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.74 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman Cc: "Hattig, Myron" , zeroconf@merit.edu, cheshire@apple.com Subject: Scalability vs. Periodic Messages (was Re: periodic messages) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, I'm concerned that your statements over periodic messages conflicts with the draft. Specifically, the draft states that scalability is not a major issue for zeroconf, as it is expected that zeroconf will be used in small evironments. Read section 1.2.4 of the -04 draft, then reread your comments about periodic messages. One of the two is problematic. I make no judgement over whether periodic messages are bad, or whether the scalability text in 1.2.4 is incorrect. I would like to start a discussion on the relative merits of the two. I think it's very important to the direction of zeroconf. Dan Erik Guttman wrote: > > > > > > 5. Several places in the document discuss periodic messages. This is > > > *not* the requirement - in fact it is a highly > > > undesirable protocol > > > feature. > > > > Where is the requirement for a periodic message. > > In draft 4: > > These scenarios require the periodic actions as well as specific > actions at startup. > - The ability to detect the presence or absence of a DHCP server > at startup of a device and periodically after a devices starts. > - The ability to periodically ensure the uniqueness of a selected > host name. > - 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. > - The ability to detect the presence or absence of a MADCAP server > at startup of a device and periodically after a devices starts. > - 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. > > > Periodic actions ARE required. > > Why are periodic messages required? Imagine we have a situation where > there is duplicate configuration, but no communication. In this case, > we do not need to detect the situation at all. Once there is communication > the detection of the duplicates should be swift. That is the meaning of my > comments which follow: > > > I agree with the comments: > > > > > 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 statement: > > > The requirement is detection of conflicts after allocation, not that > > > periodic messages be sent. > > is not accurate. There are no requirements for periodic messages. > > > > I'll let someone else pick up this thread if further discussion is needed. > > Please note there has been extensive research in this area showing that > periodic messages are a complete disaster. Do you want references? > > Just because periodic messages are currently used doesn't mean its a > good idea. For instance, current Autoconf IPv4 clients periodically > request DHCP servers by sending DHCP DISCOVER messages. This could > be improved by having DHCP servers announce themselves periodically. > So rather than n broadcasts you have 1, per time interval. > > I maintain the requirement is timely detection of conflicts and the > ability to resolve them, as well as the ability to detect newly > available infrastructure. > > This should be done as efficiently as possible. Maybe we will be stuck > with having each host poll the network with broadcasts. I hope not & > certainly maintain we can't require that they do. > > Erik -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Wed Aug 9 11:30:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08951 for ; Wed, 9 Aug 2000 11:30:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3F355DDC0; Wed, 9 Aug 2000 11:30:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F26125DDB7; Wed, 9 Aug 2000 11:30:06 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 7A9255DDD1 for ; Wed, 9 Aug 2000 11:30:02 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id IAA05747; Wed, 9 Aug 2000 08:30:18 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 08:29:43 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE4D@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Erik Guttman'" , zeroconf@merit.edu Cc: cheshire@apple.com, myron.hattig@intel.com Subject: RE: decision item for ZEROCONF WG: What is zeroconf? Date: Wed, 9 Aug 2000 08:29:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Erik, I agree with your new definition of ZC below. There is a typo in the first line. You said 'a prior' and meant 'a priori'. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] Sent: Wednesday, August 09, 2000 12:04 AM To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com; cheshire@apple.com; myron.hattig@intel.com Subject: decision item for ZEROCONF WG: What is zeroconf? In my comments on draft 4 of the requirements, I objected to the text in draft defining what a zeroconf protocol is. This is of such fundamental importance to the WG, I want a formal decision. The definition in draft 03 was: A zeroconf protocol requires no user configuration and does not rely on information received from a centralized server. A non-zeroconf protocol requires user configuration or relies on information received from a centralized server. The definition in draft 04 is: A zeroconf protocol requires no user configuration. A non-zeroconf protocol requires user configuration. I believe this is a wrong turn. The 03 definition is far closer to what I think we mean by 'zero configuration' - namely, a host comes up with no configuration but contains software which can collaboratively obtain configuration state from the network. If there is a server on the network which configures the host (a client-server dynamic configuration protocol), the host is not collaborating to configure itself. We no longer are generating configuration but obtaining it. The definition I propose is: 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.) *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Decide on which formulation of the *** *** definition of a zeroconf protocol. *** *** *** *** Choose version 03, 04 or Erik's. *** *** *** *********************************************** *********************************************** Please send your comments to the list in the next two weeks. Erik From owner-zeroconf@merit.edu Wed Aug 9 11:35:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09250 for ; Wed, 9 Aug 2000 11:35:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DA145DDB7; Wed, 9 Aug 2000 11:35:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 30DEE5DDC8; Wed, 9 Aug 2000 11:35:16 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id D3F1F5DDB7 for ; Wed, 9 Aug 2000 11:35:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29040; Wed, 9 Aug 2000 09:34:50 -0600 (MDT) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA00239; Wed, 9 Aug 2000 08:34:48 -0700 (PDT) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA05788; Wed, 9 Aug 2000 08:34:47 -0700 (PDT) Message-Id: <200008091534.IAA05788@nasnfs.eng.sun.com> Date: Wed, 9 Aug 2000 08:39:28 -0700 (PDT) From: James Kempf Reply-To: James Kempf Subject: Re: Scalability vs. Periodic Messages (was Re: periodic messages) To: Erik.Guttman@germany.sun.com, dts@senie.com Cc: myron.hattig@intel.com, zeroconf@merit.edu, cheshire@apple.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IlYtX1+YzKd301CFlJj9yg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-zeroconf@merit.edu Precedence: bulk Dan, I believe there was earlier a discussion on the list that zero-conf does not necessarily mean small. Therefore, I think scalability is important. If the draft does not say this, then I think it should. jak >Delivered-To: zeroconf-outgoing@merit.edu >Date: Wed, 09 Aug 2000 11:27:05 -0400 >From: Daniel Senie >X-Accept-Language: en >MIME-Version: 1.0 >To: Erik Guttman >Cc: "Hattig, Myron" , zeroconf@merit.edu, cheshire@apple.com >Subject: Scalability vs. Periodic Messages (was Re: periodic messages) >Content-Transfer-Encoding: 7bit > >Erik, > >I'm concerned that your statements over periodic messages conflicts with >the draft. Specifically, the draft states that scalability is not a >major issue for zeroconf, as it is expected that zeroconf will be used >in small evironments. > >Read section 1.2.4 of the -04 draft, then reread your comments about >periodic messages. One of the two is problematic. > >I make no judgement over whether periodic messages are bad, or whether >the scalability text in 1.2.4 is incorrect. I would like to start a >discussion on the relative merits of the two. I think it's very >important to the direction of zeroconf. > >Dan > > >Erik Guttman wrote: >> >> > >> > > 5. Several places in the document discuss periodic messages. This is >> > > *not* the requirement - in fact it is a highly >> > > undesirable protocol >> > > feature. >> > >> > Where is the requirement for a periodic message. >> >> In draft 4: >> >> These scenarios require the periodic actions as well as specific >> actions at startup. >> - The ability to detect the presence or absence of a DHCP server >> at startup of a device and periodically after a devices starts. >> - The ability to periodically ensure the uniqueness of a selected >> host name. >> - 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. >> - The ability to detect the presence or absence of a MADCAP server >> at startup of a device and periodically after a devices starts. >> - 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. >> >> > Periodic actions ARE required. >> >> Why are periodic messages required? Imagine we have a situation where >> there is duplicate configuration, but no communication. In this case, >> we do not need to detect the situation at all. Once there is communication >> the detection of the duplicates should be swift. That is the meaning of my >> comments which follow: >> >> > I agree with the comments: >> > >> > > 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 statement: >> > > The requirement is detection of conflicts after allocation, not that >> > > periodic messages be sent. >> > is not accurate. There are no requirements for periodic messages. >> > >> > I'll let someone else pick up this thread if further discussion is needed. >> >> Please note there has been extensive research in this area showing that >> periodic messages are a complete disaster. Do you want references? >> >> Just because periodic messages are currently used doesn't mean its a >> good idea. For instance, current Autoconf IPv4 clients periodically >> request DHCP servers by sending DHCP DISCOVER messages. This could >> be improved by having DHCP servers announce themselves periodically. >> So rather than n broadcasts you have 1, per time interval. >> >> I maintain the requirement is timely detection of conflicts and the >> ability to resolve them, as well as the ability to detect newly >> available infrastructure. >> >> This should be done as efficiently as possible. Maybe we will be stuck >> with having each host poll the network with broadcasts. I hope not & >> certainly maintain we can't require that they do. >> >> Erik > > >-- >----------------------------------------------------------------- >Daniel Senie dts@senie.com >Amaranth Networks Inc. http://www.amaranth.com > From owner-zeroconf@merit.edu Wed Aug 9 11:53:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10290 for ; Wed, 9 Aug 2000 11:53:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D33F5DE0E; Wed, 9 Aug 2000 11:53:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EF1BE5DE0B; Wed, 9 Aug 2000 11:53:27 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7F8EC5DDF4 for ; Wed, 9 Aug 2000 11:53:26 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA21585; Wed, 9 Aug 2000 08:53:22 -0700 (PDT) Received: from vayne (muc-isdn-15 [129.157.164.115]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id RAA14492; Wed, 9 Aug 2000 17:42:17 +0200 (MET DST) Date: Wed, 9 Aug 2000 17:51:35 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: Scalability vs. Periodic Messages (was Re: periodic messages) To: Daniel Senie Cc: Erik Guttman , "Hattig, Myron" , zeroconf@merit.edu, cheshire@apple.com In-Reply-To: "Your message with ID" <39917849.8CEB9CCB@senie.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Erik, > > I'm concerned that your statements over periodic messages conflicts with > the draft. Specifically, the draft states that scalability is not a > major issue for zeroconf, as it is expected that zeroconf will be used > in small evironments. I don't think anyone will defend periodic messages per se. We want to detect claim/defend collisions and recently become available services in a timely way. I argue in my comments on 04 that scalability isn't a requirement for zeroconf protocols as it is for other protocols the IETF develops, but it is a valuable feature. When evaluating two protocols which perform the same functions, the one which scales should be preferred for inclusion in the 'zeroconf profile' or during standardization. These goals do not conflict. We had a terrible time defining what 'small' meant and have since dropped such language from the requirements draft. Whatever we do, zeroconf protocols *will* be used on larger networks. Its only good sense and proper engineering to make the zeroconf protocol as scalable as we reasonably can. Maybe we can't do any better than periodic messages by each host - but that would be a worse outcome than if we standardized a protocol which didn't require this. Erik From owner-zeroconf@merit.edu Wed Aug 9 12:23:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12140 for ; Wed, 9 Aug 2000 12:23:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 38EC95DE70; Wed, 9 Aug 2000 12:23:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2483E5DE6F; Wed, 9 Aug 2000 12:23:21 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 3414B5DE6A for ; Wed, 9 Aug 2000 12:23:18 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id QAA29612; Wed, 9 Aug 2000 16:24:03 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Aug 2000 16:23:05 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 09:23:03 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B61@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: "'Erik Guttman'" Cc: zeroconf@merit.edu Subject: RE: periodic messages (was RE: comments on requirements draft 04) Date: Wed, 9 Aug 2000 09:23:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik, I'm in violent agreement with you. We don't want protocols with a bunch of broadcasts cluttering up the wire. I didn't think the requirements were written in such a way that would automatically require such a protocol - that's why in the previous note I made the distinction between ACTIONs and MESSAGES. From your last email: > Just because periodic messages are currently used doesn't mean its a > good idea. For instance, current Autoconf IPv4 clients periodically > request DHCP servers by sending DHCP DISCOVER messages. This could > be improved by having DHCP servers announce themselves periodically. > So rather than n broadcasts you have 1, per time interval. Both have periodic ACTIONS, not necessarily MESSAGES. In general the draft should state protocol requirements not prescribe solutions. Again, I'm 99% sure that we agree and would be surprised if anyone disagreed with your comments. The question is how do we word the requirements. Obviously the current wording allows people to confuse actions with messages so the text should change. -myron > -----Original Message----- > From: Erik Guttman [mailto:Erik.Guttman@germany.sun.com] > Sent: Tuesday, August 08, 2000 11:53 PM > To: Hattig, Myron > Cc: zeroconf@merit.edu; erik.guttman@germany.sun.com; > cheshire@apple.com > Subject: periodic messages (was RE: comments on requirements draft 04) > > > > > > > 5. Several places in the document discuss periodic > messages. This is > > > *not* the requirement - in fact it is a highly > > > undesirable protocol > > > feature. > > > > Where is the requirement for a periodic message. > > In draft 4: > > These scenarios require the periodic actions as well as specific > actions at startup. > - The ability to detect the presence or absence of a DHCP server > at startup of a device and periodically after a devices starts. > - The ability to periodically ensure the uniqueness of a selected > host name. > - 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. > - The ability to detect the presence or absence of a MADCAP server > at startup of a device and periodically after a devices starts. > - 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. > > > Periodic actions ARE required. > > Why are periodic messages required? Imagine we have a situation where > there is duplicate configuration, but no communication. In this case, > we do not need to detect the situation at all. Once there is > communication > the detection of the duplicates should be swift. That is the > meaning of my > comments which follow: > > > I agree with the comments: > > > > > 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 statement: > > > The requirement is detection of conflicts after > allocation, not that > > > periodic messages be sent. > > is not accurate. There are no requirements for periodic messages. > > > > I'll let someone else pick up this thread if further > discussion is needed. > > Please note there has been extensive research in this area > showing that > periodic messages are a complete disaster. Do you want references? > > Just because periodic messages are currently used doesn't mean its a > good idea. For instance, current Autoconf IPv4 clients periodically > request DHCP servers by sending DHCP DISCOVER messages. This could > be improved by having DHCP servers announce themselves periodically. > So rather than n broadcasts you have 1, per time interval. > > I maintain the requirement is timely detection of conflicts and the > ability to resolve them, as well as the ability to detect newly > available infrastructure. > > This should be done as efficiently as possible. Maybe we > will be stuck > with having each host poll the network with broadcasts. I hope not & > certainly maintain we can't require that they do. > > Erik > > From owner-zeroconf@merit.edu Wed Aug 9 12:38:59 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12898 for ; Wed, 9 Aug 2000 12:38:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B2B045DE0D; Wed, 9 Aug 2000 12:38:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A36735DE0C; Wed, 9 Aug 2000 12:38:49 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 26A455DDF6 for ; Wed, 9 Aug 2000 12:38:48 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id QAA09078; Wed, 9 Aug 2000 16:39:45 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Aug 2000 16:38:47 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 09:38:43 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B64@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: zeroconf@merit.edu Cc: srvloc@srvloc.org Subject: RE: comments on requirements draft 04 Date: Wed, 9 Aug 2000 09:38:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk > 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. You convinced me that the requirement should be removed. -myron From owner-zeroconf@merit.edu Wed Aug 9 14:38:18 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15849 for ; Wed, 9 Aug 2000 14:38:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E3F05DDD2; Wed, 9 Aug 2000 14:38:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3EBE95DDC8; Wed, 9 Aug 2000 14:38:07 -0400 (EDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by segue.merit.edu (Postfix) with ESMTP id D8F575DDC1 for ; Wed, 9 Aug 2000 14:38:05 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA10200 for ; Wed, 9 Aug 2000 14:38:04 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JSRPWS4C1S8ZODKR@mail.xerox.com> for zeroconf@merit.edu; Wed, 9 Aug 2000 14:37:03 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSRPWS086C8ZOFQ9@mail.xerox.com> for zeroconf@merit.edu; Wed, 09 Aug 2000 14:37:02 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 09 Aug 2000 14:37:55 -0400 Content-return: allowed Date: Wed, 09 Aug 2000 14:37:50 -0400 From: "Nicolae, Dan" Subject: RE: comments on requirements draft 04 To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62EE@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > 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 owner-zeroconf@merit.edu Wed Aug 9 16:30:07 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19457 for ; Wed, 9 Aug 2000 16:30:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FB745DDBF; Wed, 9 Aug 2000 16:29:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E4DF5DDB6; Wed, 9 Aug 2000 16:29:52 -0400 (EDT) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by segue.merit.edu (Postfix) with ESMTP id 0FA2D5DDB5 for ; Wed, 9 Aug 2000 16:29:51 -0400 (EDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id NAA28368; Wed, 9 Aug 2000 13:29:38 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Aug 2000 20:29:37 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 13:29:35 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B65@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: "'Dave Thaler'" , Erik Guttman , "Hattig, Myron" Cc: zeroconf@merit.edu Subject: RE: mc addr deallocation (was RE: comments on requirements draft 04) Date: Wed, 9 Aug 2000 13:28:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk My mistake, I confused IGMP with MCAP in RFC 2734 where sender owns a IP to IEEE 1394 mcast address mapping. -myron > -----Original Message----- > From: Dave Thaler [mailto:dthaler@Exchange.Microsoft.com] > Sent: Wednesday, August 09, 2000 10:30 AM > To: Erik Guttman; Hattig, Myron > Cc: zeroconf@merit.edu > Subject: RE: mc addr deallocation (was RE: comments on requirements > draft 04) > > > Erik Guttman writes: > > > > The text should simply add 'or group member' where it > > says source > > > > and I think it would work. > > > > > > 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. > > > > You have it backwards. Receivers join mc groups - which initiates > > IGMP messages, for example. Senders merely use mc > > destination addresses. > > The point is subtle, though. The point of allocating a mc > address is > > to distinguish one session from another - to keep them from > colliding. > > Who knows what constitutes a session? Those who will send or those > > who will receive? I assert this is application dependent and Dave > > Thaler (who wrote the text above) will likely agree. > > > > Dave? > > Yes, I agree with Erik. > > -Dave From owner-zeroconf@merit.edu Wed Aug 9 16:59:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20201 for ; Wed, 9 Aug 2000 16:59:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6D7D25DE2C; Wed, 9 Aug 2000 16:59:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D7535DE2B; Wed, 9 Aug 2000 16:59:22 -0400 (EDT) Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by segue.merit.edu (Postfix) with ESMTP id 102105DDB5 for ; Wed, 9 Aug 2000 16:59:21 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id QAA00060 for ; Wed, 9 Aug 2000 16:59:19 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JSRUV0BX9C8ZOFM1@mail.xerox.com> for zeroconf@merit.edu; Wed, 9 Aug 2000 16:58:24 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSRUUZKKPC8ZODGH@mail.xerox.com> for zeroconf@merit.edu; Wed, 09 Aug 2000 16:58:23 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 09 Aug 2000 16:59:16 -0400 Content-return: allowed Date: Wed, 09 Aug 2000 16:59:06 -0400 From: "Nicolae, Dan" Subject: RE: decision item for ZEROCONF WG: What is zeroconf? To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62EF@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > >The definition in draft 03 was: > > > > A zeroconf protocol requires no user configuration and does not > > rely on information received from a centralized server. > > > > A non-zeroconf protocol requires user configuration or relies on > > information received from a centralized server. > > This matches the best my understanding of zeroconf ideal. The best of the three current choices. > >The definition in draft 04 is: > > > > A zeroconf protocol requires no user configuration. > > > > A non-zeroconf protocol requires user configuration. This may be correct but the missing server issue is not apparent. The missing server is the main issue that fuels the zeroconf wg purpose. User is a very general term mostly associated with a human. It also covers an administrator who configures a DHCP or DNS server, but this again is not apparent from the definition. > >The definition I propose is: > > > > 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. According to this definition, standard DHCP is a zeroconf protocol. There is no a priori configuration on the client. My suggestion: "A zeroconf protocol requires neither centralized nor manual configuration management." - It does not lead to the false impression that configuration itself is not required. Managing that configuration must be seamless. - It points out that server-based and manual management do not qualify. - It is very close to the WG description (the initial and true motivation) - It is similar to the rationale in RFC1001 that lead to b-node definition Questions: Why do we need to define what a non-zeroconf protocol is? Isn't it clear that if a protocol is not zeroconf than it is non-zeroconf? The "zeroconf" term works only when it clearly refers to "configuration" as "the act of configuring" (action) as opposed of "the set of protocol parameters that govern the protocol's behavior" (data). Isn't "zeroadmin" or "zeromanage" less confusing? Or something else? What is covered by a zeroconf protocol? Only the peer-to-peer operation and the transition to a non-zeroconf protocol? Or the protocol as whole, including the server-based operation? I mean is DHCP non-zeroconf while AutoIP is zeroconf? Or the addition of AutoIP to the standard DHCP makes the resulting DHCP protocol zeroconf? What does the transition apply to? Do we change protocols or we change modes of operation within the same protocol? Thanks, dan From owner-zeroconf@merit.edu Wed Aug 9 17:51:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21743 for ; Wed, 9 Aug 2000 17:51:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B5475DE06; Wed, 9 Aug 2000 17:51:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78CD45DE1D; Wed, 9 Aug 2000 17:51:32 -0400 (EDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by segue.merit.edu (Postfix) with ESMTP id 20A185DE06 for ; Wed, 9 Aug 2000 17:51:31 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id RAA28611 for ; Wed, 9 Aug 2000 17:51:30 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31444) id <01JSRWPLU5U890WQCS@mail.xerox.com> for zeroconf@merit.edu; Wed, 9 Aug 2000 17:51:18 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSRWOHCALE8ZNDXN@mail.xerox.com>; Wed, 09 Aug 2000 17:50:24 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 09 Aug 2000 17:51:17 -0400 Content-return: allowed Date: Wed, 09 Aug 2000 17:51:13 -0400 From: "Nicolae, Dan" Subject: RE: comments on requirements draft 04 To: "'Richard Johnson'" , zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62F0@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > 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. How did you select and connect to the other computer in the first place when you didn't know its name? Directly by IP address? Then why would you need to know its name? You're already connected. One usage for DNS reverse queries is to map an IP back to a name for display purposes (e.g. in a Web browser URL box). So, this requirement may be valid. It may lead to requiring inverse queries support for mDNS. > We are trying not to add any requirements above and beyond > what we need > to support features we already have, and have come to expect in non-IP > zeroconf protocols like Appletalk/NBP, NetBeui/SMB, IPX/SAP. > We need host > config, name to address resolution, service discovery. We > are also looking > at MADCAP function in the absence of MADCAP servers - but > that's the extent > of what we are chartered to do. > Browsing support is not a new feature and both AppleTalk and NetBEUI users may expect it. Finding the names of all hosts in the local subnet falls in the browsing category. Browsing may be seen as a particular case of service discovery. But it may also be seen as belonging to the name resolution; it depends how it's done. dan From owner-zeroconf@merit.edu Wed Aug 9 18:07:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21998 for ; Wed, 9 Aug 2000 18:07:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F8D25DDB4; Wed, 9 Aug 2000 18:07:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3D6E35DDA7; Wed, 9 Aug 2000 18:07:34 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by segue.merit.edu (Postfix) with ESMTP id 0E7125DDB4 for ; Wed, 9 Aug 2000 18:07:32 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.3/8.9.2) id PAA01915; Wed, 9 Aug 2000 15:01:51 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14737.54478.748007.787875@kitab.cisco.com> Date: Wed, 9 Aug 2000 15:01:50 -0700 (PDT) To: "Nicolae, Dan" Cc: zeroconf@merit.edu Subject: RE: comments on requirements draft 04 In-Reply-To: <3654E69400ADD211A3A400805FA7CE24022A62F0@USA0111MS2> References: <3654E69400ADD211A3A400805FA7CE24022A62F0@USA0111MS2> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Nicolae, Dan writes: > How did you select and connect to the other computer in the first place when > you didn't know its name? Directly by IP address? Then why would you need to > know its name? You're already connected. > One usage for DNS reverse queries is to map an IP back to a name for display > purposes (e.g. in a Web browser URL box). So, this requirement may be valid. > It may lead to requiring inverse queries support for mDNS. I was talking about what you mention below as "browsing support" for hosts on the net. Not to mean that address to hostname mappings are not needed in the requirements as well. /raj From owner-zeroconf@merit.edu Wed Aug 9 18:41:21 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22354 for ; Wed, 9 Aug 2000 18:41:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 389725DDB6; Wed, 9 Aug 2000 18:41:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0C3385DDB5; Wed, 9 Aug 2000 18:41:11 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 8D9015DDA7 for ; Wed, 9 Aug 2000 18:41:09 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id WAA11231 for ; Wed, 9 Aug 2000 22:42:01 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 09 Aug 2000 22:41:03 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 Aug 2000 15:41:01 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B66@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: "'zeroconf@merit.edu'" Subject: RE: decision item for ZEROCONF WG: What is zeroconf? Date: Wed, 9 Aug 2000 15:40:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk In the below definition, "a priori configuration" is very important. The definition says that router information is okay, but burned-in and server (e.g. DHCP) info are not okay. In the past, others have said that router information is not okay. The problem with this type of definition is that it applies differently to each protocol area and it allows everyone to think they can exclude protocols they don't like. Here are some examples, a burned in MAC address is used for autonet in an ARP request to see if an IP address is used. Erik's definition excludes autonet from being a ZC protocol. Previously on this list I've talked about using ICMP get route and ICMP get netmask to do multi-IP subnet IP host configuration. Some claimed that was not ZC because it relied on configuration in a router. (Don't worry I'm not working on this anymore. ;-) Neither router information nor burned-in information are used in service discovery protocols, so how do we apply these ideas to service discovery? If someone claims a registry (see service discovery terms) is a server, then SLP registries cannot be ZC solutions. Applying this definition consistently is confusing. In thinking back to the original BOFs, I walked out of the meetings thinking zeroconf is exactly what our customers want - networks that are easy to use and do not require them to configure their network. At the time, I wasn't thinking about servers, routers, or burned-in configuration or any of that. I was thinking that home networking may actually have a chance of penetrating the mass market. I prefer the definition simply says "no user configuration". -myron > -----Original Message----- > From: Donald E. Eastlake 3rd [mailto:lde008@dma.isg.mot.com] > Sent: Wednesday, August 09, 2000 7:37 AM > To: zeroconf@merit.edu > Subject: Re: decision item for ZEROCONF WG: What is zeroconf? > > > > Given the choices offered, I would go with -03. Erik's version has > merit but I think it is too wordy, I'd prefer to minimize the latin, > and I see no problem with zeroconf using "configuration" burned into > hardware such as serial numbers, MAC addresses, public-private key > pairs, etc. although perhpas that is not what we mean by > "configuration" and is more like "identity"... > > Thanks, > Donald > > From: Erik Guttman > Date: Wed, 9 Aug 2000 09:04:19 +0200 (MET DST) > To: zeroconf@merit.edu > Cc: erik.guttman@germany.sun.com, cheshire@apple.com, > myron.hattig@intel.com > Message-ID: > > >In my comments on draft 4 of the requirements, I objected to > >the text in draft defining what a zeroconf protocol is. This > >is of such fundamental importance to the WG, I want a formal > >decision. > > > >The definition in draft 03 was: > > > > A zeroconf protocol requires no user configuration and does not > > rely on information received from a centralized server. > > > > A non-zeroconf protocol requires user configuration or relies on > > information received from a centralized server. > > > >The definition in draft 04 is: > > > > A zeroconf protocol requires no user configuration. > > > > A non-zeroconf protocol requires user configuration. > > > >I believe this is a wrong turn. The 03 definition is far closer to > >what I think we mean by 'zero configuration' - namely, a host comes > >up with no configuration but contains software which can > collaboratively > >obtain configuration state from the network. If there is a > server on the > >network which configures the host (a client-server dynamic > configuration > >protocol), the host is not collaborating to configure > itself. We no longer > >are generating configuration but obtaining it. > > > >The definition I propose is: > > > > 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.) > > > > *********************************************** > > *********************************************** > > *** For WG mailing list approval *** > > *** *** > > *** Decide on which formulation of the *** > > *** definition of a zeroconf protocol. *** > > *** *** > > *** Choose version 03, 04 or Erik's. *** > > *** *** > > *********************************************** > > *********************************************** > > > >Please send your comments to the list in the next two weeks. > > > >Erik > > > From owner-zeroconf@merit.edu Thu Aug 10 03:29:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12031 for ; Thu, 10 Aug 2000 03:29:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 390DB5DDF1; Thu, 10 Aug 2000 03:28:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1784E5DDDB; Thu, 10 Aug 2000 03:28:51 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id EBB175DDDB for ; Thu, 10 Aug 2000 03:28:49 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA00735; Thu, 10 Aug 2000 00:28:47 -0700 (PDT) Received: from vayne (muc-isdn-19 [129.157.164.119]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA19916; Thu, 10 Aug 2000 09:28:45 +0200 (MET DST) Date: Thu, 10 Aug 2000 09:38:03 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: periodic messages (was RE: comments on requirements draft 04) To: "Hattig, Myron" Cc: "'Erik Guttman'" , zeroconf@merit.edu In-Reply-To: "Your message with ID" <4148FEAAD879D311AC5700A0C969E8904F2B61@orsmsx35.jf.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Myron wrote: > I didn't think the requirements were > written in such a way that would automatically require such a protocol - > that's why in the previous note I made the distinction between ACTIONs and > MESSAGES. From your last email: > > Erik wrote: > > Just because periodic messages are currently used doesn't mean its a > > good idea. For instance, current Autoconf IPv4 clients periodically > > request DHCP servers by sending DHCP DISCOVER messages. This could > > be improved by having DHCP servers announce themselves periodically. > > So rather than n broadcasts you have 1, per time interval. > > Both have periodic ACTIONS, not necessarily MESSAGES. In general the draft > should state protocol requirements not prescribe solutions. The important distinction here is that there are no actions taken at all, unless there is a state change. For example, if servers announced themselves instead of being polled for, there would be no announcements if there were no servers. If peers could discover configuration conflict with other peers by observing their messages - there would be no actions to perform if the peers were not communicating. We should state the goal in the requirements draft, not the mechanism. That is especially true if the mechanism is dubious. In place of text in the draft which mentions periodic actions or messages, I suggest we add text which requires the proper behavior: --- p 9 These scenarios require the periodic actions as well as specific actions at startup. The action is the same whether it be periodic or at startup. The action is an attempt to discover a DHCP server. If the DHCP server is discovered the host uses DHCP, otherwise the host uses the zeroconf IP host configuration protocol. -> These scenarios require that hosts be able to discover DHCP servers both initially, at startup, and during normal operation. --- 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. -> - The ability to detect the presence or absence of a DHCP server at startup of a device and afterwards, during normal operation. --- p 11 - The ability to periodically ensure the uniqueness of a selected host name. -> - The ability to detect non-uniqueness of a selected host name at startup and afterwards, during normal operation. --- p 14 and 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. -> - The ability for a host to determine if another host has allocated an address that has been allocated by itself at startup and afterwards, during normal operation. --- p 15 and p 16 - The ability to detect the presence or absence of a MADCAP server at startup of a device and periodically after a devices starts. -> - The ability to detect the presence or absence of a MADCAP server at startup of a device and afterwards, during normal operation. --- Erik From owner-zeroconf@merit.edu Thu Aug 10 03:54:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12193 for ; Thu, 10 Aug 2000 03:54:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40D135DDDB; Thu, 10 Aug 2000 03:53:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 241305DDF2; Thu, 10 Aug 2000 03:53:50 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B8D555DDDB for ; Thu, 10 Aug 2000 03:53:48 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08168; Thu, 10 Aug 2000 00:53:46 -0700 (PDT) Received: from vayne (muc-isdn-19 [129.157.164.119]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id JAA23180; Thu, 10 Aug 2000 09:53:44 +0200 (MET DST) Date: Thu, 10 Aug 2000 10:03:02 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: decision item for ZEROCONF WG: What is zeroconf? To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, myron.hattig@intel.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This concerns my proposed formulation of the definition of a zeroconf protocol: > 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.) The point is not to forbid a priori configuration. The point is to not require it. We aren't trying to mandate a stateless networking environment, just to allow it to function. Saying that preconfiguration requires a non- zeroconf protocol to be used (like sneaker net, etc) is not to say that the parameters obtained that way can't be used. Burned in unique IDs are OK to use - if they exist. We would unfortunately be excluding an important set of potential hosts if we required such parameters in every case. Myron wrote: > Here are some examples, a burned in MAC address is used for autonet in an > ARP request to see if an IP address is used. Erik's definition excludes > autonet from being a ZC protocol. Autoconf for IPv4 uses a random #, not a mac address. Autoconf for IPv6 uses a MAC address, but can be used with a random # as well. See http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-02.txt Donald Eastlake wrote: > Given the choices offered, I would go with -03. Erik's version has > merit but I think it is too wordy, I'd prefer to minimize the latin, > and I see no problem with zeroconf using "configuration" burned into > hardware such as serial numbers, MAC addresses, public-private key > pairs, etc. although perhpas that is not what we mean by > "configuration" and is more like "identity"... Sorry about the wordiness & latin, but I think the distinction between being able to derive configuration from having it beforehand is important. There is nothing *wrong* with having a mac address, certificates, etc. preconfigured. Its just that this is not *zero* configuration. A protocol which makes use of a MAC address may be more efficient, but as in the case of IPv6 addrconf, it is not necessary. A protocol which *requires* the use of serial #s, certificates, etc. should not be a zeroconf protocol, I maintain. This would preclude cheap generic off-the-shelf components from being IP enabled. Remember the goal from STD-2: 1.2.4 Configuration It would be ideal if a host implementation of the Internet protocol suite could be entirely self-configuring. This would allow the whole suite to be implemented in ROM or cast into silicon, it would simplify diskless workstations, and it would be an immense boon to harried LAN administrators as well as system vendors. We have not reached this ideal; in fact, we are not even close. Erik From owner-zeroconf@merit.edu Thu Aug 10 09:33:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21578 for ; Thu, 10 Aug 2000 09:33:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A1EA5DDDB; Thu, 10 Aug 2000 09:32:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 29F8D5DDBE; Thu, 10 Aug 2000 09:32:27 -0400 (EDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by segue.merit.edu (Postfix) with ESMTP id C9B095DD9F for ; Thu, 10 Aug 2000 09:32:25 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id JAA15344 for ; Thu, 10 Aug 2000 09:32:24 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JSSTJ7DOLC8ZO857@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 09:31:26 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSSTJ78AWK8ZOGJZ@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 09:31:25 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 09:32:19 -0400 Content-return: allowed Date: Thu, 10 Aug 2000 09:32:17 -0400 From: "Nicolae, Dan" Subject: RE: Scalability vs. Periodic Messages (was Re: periodic messages) To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62F2@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > Dan, > > I believe there was earlier a discussion on the list that > zero-conf does > not necessarily mean small. Therefore, I think scalability is > important. > If the draft does not say this, then I think it should. > > jak Besides the fact that the protocol SHOULD be designed with scalability in mind, there is also other aspect: Zeroconf (potentially non scalable) and non-zeroconf (most likely scalable) protocols MAY coexist. That means an non scalable protocol MAY stay enabled even after "the owners of that network will migrate to using non-zeroconf protocols". So, the second assumption in section 1.2.4. does not quite stand up. I believe that the first assumption ("limited size") has already been challenged (no way to define "small" or "limited"), so ignoring scalability is left with no excuse. If it wasn't so far, Scalability IS an issue now. Or, a nonscalable zeroconf protocol MUST transition completely to non-zeroconf when needed (define "needed" now). Or, the non-zeroconf protocol the host just transitioned to MUST allow for disabling/enabling the zeroconf protocol coexistence. With DHCP is easy; a AutoIP option can kill AutoIP. But how about mDNS or SLP, SSDP etc.? And how about the zeroconf protocol relying on a DHCP option (non-zeroconf)? This makes it non-zeroconf. Or, ... dan From owner-zeroconf@merit.edu Thu Aug 10 09:38:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21810 for ; Thu, 10 Aug 2000 09:38:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C89A95DDF1; Thu, 10 Aug 2000 09:38:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B76505DD9F; Thu, 10 Aug 2000 09:38:03 -0400 (EDT) Received: from tictac.cs.umd.edu (tictac.cs.umd.edu [128.8.126.44]) by segue.merit.edu (Postfix) with ESMTP id 9650A5DDBE for ; Thu, 10 Aug 2000 09:38:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by tictac.cs.umd.edu (8.9.3/8.9.1) with ESMTP id JAA19676 for ; Thu, 10 Aug 2000 09:38:01 -0400 (EDT) Date: Thu, 10 Aug 2000 09:38:01 -0400 (EDT) From: Cuneyt Akinlar To: zeroconf@merit.edu Subject: Comments on IP host config requirents in draft#4 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk In this posting, my intention is to try to contribute (or add more confusion, however you look at it :-)) to the current discussion on what is a zeroconf protocol and also pinpoint some of the deficiencies in IP host config requirements as defined by draft#4. Firstly, on the definition of a zeroconf protocol I agree with Myron Hattig in the sense that I always thought a zeroconf protocol to be a protocol that does not require manual configuration. I will extend this definition as follows: "A protocol is zero-config if does not require manual configuration AND does not use an entity that requires manual configuration". According to this definition, a host using DHCP protocol for IP host config is zero-conf if the DHCP-server is also autoconfig. That is, the DHCP server was not setup by an administrator. If the DHCP-Server was setup by an admin (that is it might have been burned down to the hardware by the vendor), the host IP protocol is NOT zero-conf. My thinking process to arrive at this definition is the following: I always though of something to be zeroconfig if I buy that entity, power it up and boom it works without requiring any manual setup. So, lets say I buy a router and a couple of hosts. Hook them up, turn the power up. If this system can setup itself, I call this a zeroconf system. In this scneraio, the router might have a vendor burned in DHCP-Server and the hosts might be using DHCP for IP host config but the whole thing did not require manual setup. So, it is zeroconfig. Of course the hosts have to configure an IP address in case no DHCP-Server is available. Some people suggested that a zeroconfig protocol does not use a server. I don't see why you cannot call a protocol zeroconfig if the server does not require manual configuration? So much for the definition of a zeroconfig protocol. I actually wanted to comment on IP host config requirements as defined in draft#4. I think that some of the reqs. are too vague and some terms have to be defined before being used. In section 2.1.1, the draft talks about Ping and defines several requirements which I quote below (I numbered some of the sentences for further reference): " Specifically, the values for the IP address, netmask, and default route within a host must be chosen such that the following statements are true: (1)- All hosts on an IP subnet have a common netmask. (2)- When a host computes (HostIPAddr & netmask) the result is identical for all hosts on a single IP subnet. (3)- When a host computes (HostIPAddr & ~netmask) (inverse netmask) the result is unique for all hosts on an IP subnet. (4)- All hosts get a default route that is used for communication with other IP hosts off the local subnet. In addition IP subnets must somehow be unique on different IP subnets within an internet over which the zeroconf IP host configuration protocol is operating; this insures unique IP addresses (regardless of the value of the host portion of the IP address) across the entire internet. The zeroconf IP host configuration protocol only defines packets sent over a wire and the associated semantics. Here are zeroconf IP host configuration protocol requirements to satisfy ping: (5)- The ability to determine the netmask for an IP subnet. (6)- The ability to determine the default route for an IP subnet. (7)- The ability to have unique IP addresses within an IP subnet. (8)- The ability to have unique IP subnets within an internet. " Firstly, items (1)-(3) give the definition of an IP subnet which we already know. (4) is similar. By definition, a default route is used to communicate with hosts off the local subnet. As for (7), it does not prevent IP address conflicts in a link-layer network (as I give an example below). I belive (8) should not be the job of an IP host config protocol and should be removed. Only (5) and (6) make sense in these requirements as (5) requires a hosts to determine a netmask and (6) requires a host to determine a default router if one is available. Below I will try to give an example network that complies with all of the requirements listed above but probably is not what we are talking about. +---+ +---+ | A | | B | +---+ +---+ | | +---------+ ^ | A Segment Consider the network shown above. This is a single segment network with 2 hosts. A segment is a single link-layer network or several link-layer networks bridged together. All hosts in a segment CAN communicate only with MAC addresses. Now assume that host A comes up, sets up: IP address: 10.10.10.10. Netmask: 255.255.0.0 Since host A is the only host at that point, everything is fine. Notice that host A defines a logical IP network (an IP subnet) over the segment. This IP network's subnet number is 10.10/16. It can easily be seen that all of the requirements listed above are satisfied. Now host B comes up, and sets up the following parameters: IP address: 10.10.10.10 netmask: 255.255.255.0 So, host B defines another IP network over the same segment whose subnet number is 10.10.10/24. Again, all of the requirements listed above are satifies as the requirements are defines in terms of IP subnets and there are two IP subnets over the same segment. Each IP subnet contains a single hosts though. Obviously, there is an anamoly in the network as 2 hosts have the same IP address but requirement (7) is still satisfied as the IP addresses are unique within their own IP subnets. To make a long story short, all requirements listed above and in section 2.1.4 are all satified by this network configuration. Obviously, these two hosts cannot talk to each other and the network is useless. Of course the requirements listed in the draft are trying to say that both hosts must use the same netmask, namely, be part of the same IP subnet. Then other requirements follows. But they are not rigorous enough. So I suggest to use the following definitions and requirements: Segment: A single link-layer network or a collection of link-layer networks connected by bridges. IP Network (IP subnet): A network that consists of hosts with interfaces that share the same subnet number of their IP addresses. That is, all hosts on an IP subnet get the same value when they perform (IPAddrr&netmask) and different value when they perform (IPAddrr&~netmask). Given these 2 definitions, I suggest the following requirements: 1. All hosts connected to the same segment MUST aggree on a common netmask. That is, there must be a single IP subnet defined over a segment aggreed upon by all hosts. 2. All hosts connected to the same segment MUST have unique IP addresses and hosts must enforce this after initial configuration. 3. All hosts MUST configure a default router when at least a router is connected to the segment. 4. All hosts MUST detect the presence or absence of a DHCP-Server and MUST switch to the DHCP-Server assigned address when one is detected. I believe these 4 requirements rigoruosly handle all cases. I also believe that the requirement to make sure that all subnets within an internet to be unique is NOT a IP host config requirement but maybe a single-router autoconfig requirement as it will be the router which determines which subnets are assigned to segments connected to the router. I am saying this based on Aboba's single-router autoconfig draft which suggests to use a self-configuring router that uses mini-DHCP to configure the hosts on the segments. As for the discussion on periodic checks versus proactive IP address collision detection, req. # (2) above only mandates that IP address collisions must be detected but it does not mandate a way to do it. You could do it by periodic checks by the hosts or proactively by changing ARP. Tt is up to the implementor of the protocol. I don't know if I have added more confusion to the discussion but just wanted to express my ideas. Cuneyt From owner-zeroconf@merit.edu Thu Aug 10 09:48:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22483 for ; Thu, 10 Aug 2000 09:48:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B68225DE10; Thu, 10 Aug 2000 09:46:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A66425DE02; Thu, 10 Aug 2000 09:46:41 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 20C295DDFA for ; Thu, 10 Aug 2000 09:46:40 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23520; Thu, 10 Aug 2000 06:46:37 -0700 (PDT) Received: from timeless (timeless [129.157.44.94]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id PAA07859; Thu, 10 Aug 2000 15:46:35 +0200 (MET DST) Date: Thu, 10 Aug 2000 15:46:33 +0200 (MET DST) From: Erik Guttman X-Sender: erikg@timeless To: "Nicolae, Dan" Cc: zeroconf@merit.edu Subject: RE: Scalability vs. Periodic Messages (was Re: periodic messages) In-Reply-To: <3654E69400ADD211A3A400805FA7CE24022A62F2@USA0111MS2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 10 Aug 2000, Nicolae, Dan wrote: > > Besides the fact that the protocol SHOULD be designed with scalability in > mind, there is also other aspect: > > Zeroconf (potentially non scalable) and non-zeroconf (most likely scalable) > protocols MAY coexist. > That means an non scalable protocol MAY stay enabled even after "the owners > of that network will migrate to using non-zeroconf protocols". So, the > second assumption in section 1.2.4. does not quite stand up. I believe that > the first assumption ("limited size") has already been challenged (no way to > define "small" or "limited"), so ignoring scalability is left with no > excuse. > > If it wasn't so far, Scalability IS an issue now. > Or, a nonscalable zeroconf protocol MUST transition completely to > non-zeroconf when needed (define "needed" now). > Or, the non-zeroconf protocol the host just transitioned to MUST allow for > disabling/enabling the zeroconf protocol coexistence. With DHCP is easy; a > AutoIP option can kill AutoIP. But how about mDNS or SLP, SSDP etc.? And how > about the zeroconf protocol relying on a DHCP option (non-zeroconf)? This > makes it non-zeroconf. Creating requirements which specify that scalability is important but not the overriding consideration will help us in the standardization of protocols that scale better. It will be an important criteria which the IESG and WGs can apply when evaluating candidate protocols. Please note that it is possible to create a scalable zeroconf protocol. These protocols don't have to be relegated to link-local operation, either. We succeeded in this respect with SLP. When you turn on stateless directory agents, you effectively turn off multicast-based requests. This is a fundamental requirement of the SLP, which uses the same protocol peer to peer as when a DA is present. The same will not be possible for DHCP, as it doesn't make sense to do peer to peer DHCP. But similar things are indeed possible for mDNS / DNS and AAP for zeroconf nets / MADCAP. Erik From owner-zeroconf@merit.edu Thu Aug 10 10:03:29 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23452 for ; Thu, 10 Aug 2000 10:03:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DC995DDFB; Thu, 10 Aug 2000 10:02:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 353C75DE18; Thu, 10 Aug 2000 10:02:17 -0400 (EDT) Received: from garlic.amaranth.net (garlic.amaranth.net [216.235.243.195]) by segue.merit.edu (Postfix) with ESMTP id 84A505DDFB for ; Thu, 10 Aug 2000 10:02:15 -0400 (EDT) Received: from senie.com (garlic.amaranth.net [216.235.243.195]) (authenticated) by garlic.amaranth.net (8.10.1/8.10.1) with ESMTP id e7ADw2Q30598; Thu, 10 Aug 2000 09:58:02 -0400 Message-ID: <3992B4EA.D8FFCF0C@senie.com> Date: Thu, 10 Aug 2000 09:58:02 -0400 From: Daniel Senie Organization: Amaranth Networks Inc. X-Mailer: Mozilla 4.74 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Guttman Cc: "Nicolae, Dan" , zeroconf@merit.edu Subject: Re: Scalability vs. Periodic Messages (was Re: periodic messages) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik Guttman wrote: > > On Thu, 10 Aug 2000, Nicolae, Dan wrote: > > > > > Besides the fact that the protocol SHOULD be designed with scalability in > > mind, there is also other aspect: > > > > Zeroconf (potentially non scalable) and non-zeroconf (most likely scalable) > > protocols MAY coexist. > > That means an non scalable protocol MAY stay enabled even after "the owners > > of that network will migrate to using non-zeroconf protocols". So, the > > second assumption in section 1.2.4. does not quite stand up. I believe that > > the first assumption ("limited size") has already been challenged (no way to > > define "small" or "limited"), so ignoring scalability is left with no > > excuse. > > > > If it wasn't so far, Scalability IS an issue now. > > Or, a nonscalable zeroconf protocol MUST transition completely to > > non-zeroconf when needed (define "needed" now). > > Or, the non-zeroconf protocol the host just transitioned to MUST allow for > > disabling/enabling the zeroconf protocol coexistence. With DHCP is easy; a > > AutoIP option can kill AutoIP. But how about mDNS or SLP, SSDP etc.? And how > > about the zeroconf protocol relying on a DHCP option (non-zeroconf)? This > > makes it non-zeroconf. > > Creating requirements which specify that scalability is important > but not the overriding consideration will help us in the standardization > of protocols that scale better. It will be an important criteria which > the IESG and WGs can apply when evaluating candidate protocols. Good. I agree we should strive for scalability. I started this thread up because of a perceived inconsistency in the -04 draft. I wanted to see what other folks said before I added to the discussion further. It is indeed important that the scalability (or lack thereof) of zeroconf not affect other traffic on the wire. As rightly stated, we're going to have both zeroconf and non-zeroconf coexisting. Netbios has some attributes of what we're talking about, and in conjunction with IP autoconfig works fairly well, but is VERY chatty on the wire. I would like us to keep that example in mind as we move forward. > > Please note that it is possible to create a scalable zeroconf protocol. > These protocols don't have to be relegated to link-local operation, > either. > > We succeeded in this respect with SLP. When you turn on stateless > directory agents, you effectively turn off multicast-based requests. > This is a fundamental requirement of the SLP, which uses the same > protocol peer to peer as when a DA is present. > > The same will not be possible for DHCP, as it doesn't make sense to > do peer to peer DHCP. But similar things are indeed possible for > mDNS / DNS and AAP for zeroconf nets / MADCAP. > > Erik -- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com From owner-zeroconf@merit.edu Thu Aug 10 10:26:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24613 for ; Thu, 10 Aug 2000 10:26:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCFEA5DE2C; Thu, 10 Aug 2000 10:26:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6F285DDBE; Thu, 10 Aug 2000 10:26:03 -0400 (EDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by segue.merit.edu (Postfix) with ESMTP id 30A495DE01 for ; Thu, 10 Aug 2000 10:26:02 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id KAA11136 for ; Thu, 10 Aug 2000 10:25:59 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JSSVEL5GYO8ZNIRX@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 10:24:58 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSSVEL1OBM8ZOERF@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 10:24:58 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 10:25:52 -0400 Content-return: allowed Date: Thu, 10 Aug 2000 10:25:46 -0400 From: "Nicolae, Dan" Subject: RE: Scalability vs. Periodic Messages (was Re: periodic messages) To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62F3@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > Please note that it is possible to create a scalable zeroconf > protocol. > These protocols don't have to be relegated to link-local operation, > either. > > We succeeded in this respect with SLP. When you turn on stateless > directory agents, you effectively turn off multicast-based requests. > This is a fundamental requirement of the SLP, which uses the same > protocol peer to peer as when a DA is present. > This makes me reformulate a question a sent previously: Is a protocol that provides support for both serverless and server-based operation considered zeroconf? Or, just the serverless mode and the transition to server-based mode is zeroconf, while the server-based mode is non-zeroconf? Example for DHCP: Is AutoIP zeroconf and DHCP non-zeroconf? Or, DHCP+AutoIP is zeroconf and DHCP without AutoIP is non-zeroconf? In SLP case: SLP with DAs is not zeroconf because it relies on DAs (centralized). SLP without DAs is zeroconf but is not scalable (potentially) because there is no DA. Making SLP scalable involves turning on DAs thus making SLP non-zeroconf. Conclusion: zeroconf SLP is non-scalable; non-zeroconf SLP is scalable. Scalability involves full and automatic transition to non-zeroconf. Am I right? From owner-zeroconf@merit.edu Thu Aug 10 10:43:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25560 for ; Thu, 10 Aug 2000 10:43:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B04AD5DE25; Thu, 10 Aug 2000 10:42:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9F3665DE24; Thu, 10 Aug 2000 10:42:52 -0400 (EDT) Received: from multicasttech.com (unknown [63.105.122.8]) by segue.merit.edu (Postfix) with ESMTP id 504E95DE21 for ; Thu, 10 Aug 2000 10:42:51 -0400 (EDT) Received: from [207.176.21.133] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 510182; Thu, 10 Aug 2000 10:48:08 -0400 Message-ID: <3992C03E.93858B5D@21rst-century.com> Date: Thu, 10 Aug 2000 10:46:21 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: "Hattig, Myron" Cc: "'zeroconf@merit.edu'" Subject: Re: decision item for ZEROCONF WG: What is zeroconf? References: <4148FEAAD879D311AC5700A0C969E8904F2B66@orsmsx35.jf.intel.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit "Hattig, Myron" wrote: > In the below definition, "a priori configuration" is very important. The > definition says that router information is okay, but burned-in and server > (e.g. DHCP) info are not okay. In the past, others have said that router > information is not okay. The problem with this type of definition is that it > applies differently to each protocol area and it allows everyone to think > they can exclude protocols they don't like. > > Here are some examples, a burned in MAC address is used for autonet in an > ARP request to see if an IP address is used. Erik's definition excludes > autonet from being a ZC protocol. > > Previously on this list I've talked about using ICMP get route and ICMP get > netmask to do multi-IP subnet IP host configuration. Some claimed that was > not ZC because it relied on configuration in a router. (Don't worry I'm not > working on this anymore. ;-) > > Neither router information nor burned-in information are used in service > discovery protocols, so how do we apply these ideas to service discovery? If > someone claims a registry (see service discovery terms) is a server, then > SLP registries cannot be ZC solutions. > > Applying this definition consistently is confusing. > > In thinking back to the original BOFs, I walked out of the meetings thinking > zeroconf is exactly what our customers want - networks that are easy to use > and do not require them to configure their network. At the time, I wasn't > thinking about servers, routers, or burned-in configuration or any of that. > I was thinking that home networking may actually have a chance of > penetrating the mass market. > > I prefer the definition simply says "no user configuration". > > -myron > > > -----Original Message----- > > From: Donald E. Eastlake 3rd [mailto:lde008@dma.isg.mot.com] > > Sent: Wednesday, August 09, 2000 7:37 AM > > To: zeroconf@merit.edu > > Subject: Re: decision item for ZEROCONF WG: What is zeroconf? > > > > > > > > Given the choices offered, I would go with -03. Erik's version has > > merit but I think it is too wordy, I'd prefer to minimize the latin, > > and I see no problem with zeroconf using "configuration" burned into > > hardware such as serial numbers, MAC addresses, public-private key > > pairs, etc. although perhpas that is not what we mean by > > "configuration" and is more like "identity"... > > > > Thanks, > > Donald > > > > From: Erik Guttman > > Date: Wed, 9 Aug 2000 09:04:19 +0200 (MET DST) > > To: zeroconf@merit.edu > > Cc: erik.guttman@germany.sun.com, cheshire@apple.com, > > myron.hattig@intel.com > > Message-ID: > > > > >In my comments on draft 4 of the requirements, I objected to > > >the text in draft defining what a zeroconf protocol is. This > > >is of such fundamental importance to the WG, I want a formal > > >decision. > > > > > >The definition in draft 03 was: > > > > > > A zeroconf protocol requires no user configuration and does not > > > rely on information received from a centralized server. > > > > > > A non-zeroconf protocol requires user configuration or relies on > > > information received from a centralized server. > > > > > >The definition in draft 04 is: > > > > > > A zeroconf protocol requires no user configuration. > > > > > > A non-zeroconf protocol requires user configuration. > > > > > >I believe this is a wrong turn. The 03 definition is far closer to > > >what I think we mean by 'zero configuration' - namely, a host comes > > >up with no configuration but contains software which can > > collaboratively > > >obtain configuration state from the network. If there is a > > server on the > > >network which configures the host (a client-server dynamic > > configuration > > >protocol), the host is not collaborating to configure > > itself. We no longer > > >are generating configuration but obtaining it. > > > > > >The definition I propose is: > > > > > > 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.) > > > > > > *********************************************** > > > *********************************************** > > > *** For WG mailing list approval *** > > > *** *** > > > *** Decide on which formulation of the *** > > > *** definition of a zeroconf protocol. *** > > > *** *** > > > *** Choose version 03, 04 or Erik's. *** > > > *** *** > > > *********************************************** > > > *********************************************** > > > > > >Please send your comments to the list in the next two weeks. > > > > > >Erik > > > > > > Hello; Going back to the "my " rule - If you can't just plug it in and turn it on my Mother will not use it. If you can, she will. Using that principle, Zeroconfig means no human intervention ANYWHERE. If that requires a central box, then why isn't that OK - as long as the central box doesn't require human intervention. I am not sure that DHCP qualifies - I know we've had to fddle with it when we were setting it up. My $0.02 worth is to go witrh Draft 4, but maybe to make it clearer that you cannot push the intervention elsewhere. Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com From owner-zeroconf@merit.edu Thu Aug 10 11:07:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26816 for ; Thu, 10 Aug 2000 11:07:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 481C75DE02; Thu, 10 Aug 2000 11:06:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3769D5DE01; Thu, 10 Aug 2000 11:06:53 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id 561795DDFD for ; Thu, 10 Aug 2000 11:06:51 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA29197; Thu, 10 Aug 2000 15:07:23 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 10 Aug 2000 15:06:25 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 08:06:24 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B6B@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: "'Erik Guttman'" , "Hattig, Myron" Cc: zeroconf@merit.edu Subject: RE: periodic messages (was RE: comments on requirements draft 04) Date: Thu, 10 Aug 2000 08:06:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Agreed. Unless there's further input, I'll change the text as you suggest. Here is one of the samples. > These scenarios require that hosts be able to discover DHCP servers > both initially, at startup, and during normal operation. -myron From owner-zeroconf@merit.edu Thu Aug 10 12:28:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03943 for ; Thu, 10 Aug 2000 12:28:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 523295DE08; Thu, 10 Aug 2000 12:28:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 40E9A5DE04; Thu, 10 Aug 2000 12:28:22 -0400 (EDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by segue.merit.edu (Postfix) with ESMTP id E4E705DE01 for ; Thu, 10 Aug 2000 12:28:20 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id MAA27390 for ; Thu, 10 Aug 2000 12:28:19 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JSSZO2JABK8ZNIRX@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 12:27:09 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSSZO24NVQ8ZOL8A@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 12:27:08 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 12:28:02 -0400 Content-return: allowed Date: Thu, 10 Aug 2000 12:27:57 -0400 From: "Nicolae, Dan" Subject: RE: decision item for ZEROCONF WG: What is zeroconf? To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62F4@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Cuneyt Akinlar wrote: > Some people suggested > that a zeroconfig protocol does not use a server. I don't see why you > cannot call a protocol zeroconfig if the server does not require > manual configuration? So much for the definition of a zeroconfig > protocol. > So, if I design a DHCP server to automatically hand out linklocal IP addresses unless configured otherwise, it means I just made DHCP zeroconf? Or, if I design a DNS server to listen for dynamic DNS updates, cache them all and use them to answer DNS queries, it means I just made DNS zeroconf? Marshall Eubanks wrote: > Using that principle, Zeroconfig means no human intervention > ANYWHERE. If that > requires a central box, then why isn't that OK - as long as > the central box > doesn't require human intervention. > The very fact that you need to *add* or *turn on* that central box is human intervention. It may be OK to assume that in most cases a central box (e.g. router) will be present, turned on and configured. But how about the few cases when it is not? Like home networks not connected to the Internet or the two guys using the crossover cable in a plane? It seems clear to me that a zeroconf protocol MUST NOT require a central entity to function, even when no user configuration is required. If you ignore that in the definition, lots of protocols can claim zeroconf compliance (perhaps with minimal modifications). [Regardless of how we call that central entity: server, proxy, cache, agent etc., it is a *specialized* host that does community work to allow the protocol to operate.] I can see a possible way to get away with the *specialized* host requirement and still be zeroconf: Require that *each* host running the zeroconf protocol be able to perform the *specialized* function. That is, if there is no *specialized* box around, than one of the hosts automatically becomes one. This is similar to Microsoft's Browser; which, regardless of what criticism can get, you have to admit that it is as zeroconf as a protocol can possibly be. Translated to SLP, if SLP requires a DA than each host should be able to become one if there is no DA around. Does this alternative sound reasonable? I doubt it. Thus I believe definition 04 is incorrect. dan From owner-zeroconf@merit.edu Thu Aug 10 13:19:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05625 for ; Thu, 10 Aug 2000 13:19:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDD445DE0C; Thu, 10 Aug 2000 13:19:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DDB635DE0A; Thu, 10 Aug 2000 13:19:41 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7F2355DE01 for ; Thu, 10 Aug 2000 13:19:40 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08303; Thu, 10 Aug 2000 10:19:33 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id TAA03662; Thu, 10 Aug 2000 19:18:57 +0200 (MET DST) From: Erik Guttman Sun Frankfurt Staff Engineer Message-Id: <200008101718.TAA03662@efra05-home.Germany.Sun.COM> Date: Thu, 10 Aug 2000 19:13:49 +0-200 To: "Nicolae, Dan" , Cc: Subject: RE: Scalability vs. Periodic Messages (was Re: periodic messages) X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dan, >> Please note that it is possible to create a scalable zeroconf >> protocol. >> These protocols don't have to be relegated to link-local operation, >> either. >> >> We succeeded in this respect with SLP. When you turn on stateless >> directory agents, you effectively turn off multicast-based requests. >> This is a fundamental requirement of the SLP, which uses the same >> protocol peer to peer as when a DA is present. >> > >This makes me reformulate a question a sent previously: >Is a protocol that provides support for both serverless and server-based >operation considered zeroconf? Or, just the serverless mode and the >transition to server-based mode is zeroconf, while the server-based mode is >non-zeroconf? One step at a time. The distinction I want to draw is a priori vs. a posteriori configuration. Whether you have a peer to peer or client server protocol is a *secondary characteristic.* The primary thing is *where does the configuration come from?* In SLP, it comes from the peers. The DA only caches that info and makes it more efficient and robust to access. The DA's presense or absence does not change the result of any particular operation (except how long it takes an how likely it is to not get clobbered due to network congestion). >Example for DHCP: >Is AutoIP zeroconf and DHCP non-zeroconf? Or, DHCP+AutoIP is zeroconf and >DHCP without AutoIP is non-zeroconf? DHCP is not zeroconf. The hosts in the network *get* their configuration from the DHCP server. A separate question, which some folks seem to get hung up on is 'How does the DHCP server get configured?' If the DHCP server makes up addresses on its own, isn't that zeroconf? I say no - since the *other* hosts on the network have nothing to say about it. Once you turn on a configuration server, which determines the configuration for the network (DHCP, NIS, MADCAP, whatever) you are no longer in a zeroconf network, hosts are no longer building up configuration, servers are handing it out. That is not to say non-zeroconf protocols are bad. They are wonderful! We simply need to draw the line and leave work on these protocols to some other group. >In SLP case: >SLP with DAs is not zeroconf because it relies on DAs (centralized). No - SLP doesn't rely on DAs. If the DAs go away, everything continues to work. Being a central point of data registration and access doesn't mean that it is configured. DAs are stateless except for what they gather from the peers on the network. Disagreeing with your first premise, I don't come to your conclusion. >Conclusion: zeroconf SLP is non-scalable; non-zeroconf SLP is scalable. >Scalability involves full and automatic transition to non-zeroconf. Conceivably you could do this DNS, too. *If* a DNS servers were to announce themselves (using multicast say) and *if* all hosts were to use dynamic update to register their RRs you could achieve the same result as with SLP: A posteriori configuration drawn entirely from the network. As long as the set of RRs in the DNS server is the same as the set of RRS one could obtain from hosts issuing a peer to peer name to address resolution protocol, the DNS server would only serve to make name resolution more efficient and reliable. But the DNS server could come and go and the resolvers would continue to get the same results from their requests. DHCP and MADCAP are *allocation* protocols. That is, if you do the allocation with a server and the server fails, you lose your state. Zeroconf protocols (as I am arguing we define them) do not rely on this state - they *acquire* it from the net in a fully distributed fashion. There is no central authority with respect to network configuration. Erik From owner-zeroconf@merit.edu Thu Aug 10 13:30:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05986 for ; Thu, 10 Aug 2000 13:30:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEA275DE01; Thu, 10 Aug 2000 13:29:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DAD6A5DE0A; Thu, 10 Aug 2000 13:29:56 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 137565DE01 for ; Thu, 10 Aug 2000 13:29:51 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13478; Thu, 10 Aug 2000 10:29:21 -0700 (PDT) Received: from efra05-home.Germany.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with ESMTP id TAA04535; Thu, 10 Aug 2000 19:29:00 +0200 (MET DST) From: Erik Guttman Sun Frankfurt Staff Engineer Message-Id: <200008101729.TAA04535@efra05-home.Germany.Sun.COM> Date: Thu, 10 Aug 2000 19:23:49 +0-200 To: , "Hattig, Myron" Cc: "'zeroconf@merit.edu'" Reply-To: Subject: Re: decision item for ZEROCONF WG: What is zeroconf? X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >"Hattig, Myron" wrote: >> Here are some examples, a burned in MAC address is used for autonet in an >> ARP request to see if an IP address is used. Erik's definition excludes >> autonet from being a ZC protocol. If you have configuration - use it. A mac address, certificates, a unique id serial number, whatever. If you have a router - and it had better be configured! - hosts can use configuration it provides them (say with router advertisements, etc.) What I am arguing against is *requiring* this configuration in the zeroconf protocols. We want zeroconf protocols to work in the absence of configuration and the absence of servers. The only way we will achieve this is by being 100% clear that zeroconf protocols do not require a priori configuration. >Going back to the "my " rule - >If you can't just plug it in and turn it on my Mother will not use it. >If you can, she will. > >Using that principle, Zeroconfig means no human intervention ANYWHERE. If that >requires a central box, then why isn't that OK - as long as the central box >doesn't require human intervention. I am not sure that DHCP qualifies - >I know we've had to fddle with it when we were setting it up. We're writing protocol not human interface requirements. If we leave it open whether protocols can require central servers or not, we leave it open whether ZC protocols can have central points of failure, misconfigured servers, two servers (not good when we're talking DHCP), etc etc. Erik From owner-zeroconf@merit.edu Thu Aug 10 13:33:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06123 for ; Thu, 10 Aug 2000 13:33:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FE6C5DE20; Thu, 10 Aug 2000 13:32:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49FB45DE17; Thu, 10 Aug 2000 13:32:55 -0400 (EDT) Received: from kitab.cisco.com (kitab.cisco.com [171.69.187.233]) by segue.merit.edu (Postfix) with ESMTP id EF8495DE0A for ; Thu, 10 Aug 2000 13:32:50 -0400 (EDT) Received: (from raj@localhost) by kitab.cisco.com (8.9.3/8.9.2) id KAA01385; Thu, 10 Aug 2000 10:32:08 -0700 (PDT) (envelope-from raj) From: Richard Johnson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14738.59159.503330.998654@kitab.cisco.com> Date: Thu, 10 Aug 2000 10:32:07 -0700 (PDT) To: Erik Guttman Cc: zeroconf@merit.edu, erik.guttman@germany.sun.com, cheshire@apple.com, myron.hattig@intel.com Subject: Re: decision item for ZEROCONF WG: What is zeroconf? In-Reply-To: References: X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik Guttman writes: > The definition in draft 03 was: > > A zeroconf protocol requires no user configuration and does not > rely on information received from a centralized server. > > A non-zeroconf protocol requires user configuration or relies on > information received from a centralized server. > > The definition in draft 04 is: > > A zeroconf protocol requires no user configuration. > > A non-zeroconf protocol requires user configuration. Draft #3 is much closer to the original vision of zeroconf. I keep going back to two people trying to share files on a train where they met. Draft #3 specifically denys the existence of a central server, which is what you would need in this situation. Draft #4 would allow that the protocols may only work if a central server exists. This would not be the case between two people meeting in a random location. Nix the central server and you have something a LOT more useful. /raj From owner-zeroconf@merit.edu Thu Aug 10 14:33:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09801 for ; Thu, 10 Aug 2000 14:33:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 791505DE04; Thu, 10 Aug 2000 14:32:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 66FF55DE1F; Thu, 10 Aug 2000 14:32:26 -0400 (EDT) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by segue.merit.edu (Postfix) with ESMTP id DF3C95DE04 for ; Thu, 10 Aug 2000 14:32:24 -0400 (EDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id SAA24308; Thu, 10 Aug 2000 18:28:20 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 10 Aug 2000 18:27:21 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 11:27:20 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B6E@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: "'Nicolae, Dan'" , zeroconf@merit.edu Subject: RE: Scalability vs. Periodic Messages (was Re: periodic messages) Date: Thu, 10 Aug 2000 11:27:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk > Example for DHCP: > Is AutoIP zeroconf and DHCP non-zeroconf? Or, DHCP+AutoIP is > zeroconf and > DHCP without AutoIP is non-zeroconf? > > In SLP case: > SLP with DAs is not zeroconf because it relies on DAs > (centralized). SLP > without DAs is zeroconf but is not scalable (potentially) > because there is > no DA. Making SLP scalable involves turning on DAs thus making SLP > non-zeroconf. > Conclusion: zeroconf SLP is non-scalable; non-zeroconf SLP is > scalable. > Scalability involves full and automatic transition to non-zeroconf. I'm crossing over threads here, but that's okay I think ... Great questions/examples. These are the types of things I've struggling with ... specifically with IP host config. One scheme we had included getting info from routers. If we consider the router as has having "state", then that protocol would not have been a zc protocol. However, that protocol reverted to autonet (aka autoIP, aka link-local addressing) when the router was not available to provide the state info. So was that protocol zeroconf or not??? Extending Erik's arguement using DHCP. A network with a single DHCP server is not zc because if the DHCP server fails, then the whole protocol fails. Okay now say there are two DHCP servers - this is still not zc because both servers could fail. Now say there are 3, then 4 DHCP servers - still not a zc because they could all fail. Now lets say every host has a DHCP server and they will respond to their own queries if no "real DHCP" responds - now (I think) according to Erik's definition, this becomes solution is a ZC protocol. An early version of mDNS has the function of a DNS server in each host, each host would respond to DNS queries for itself - thus mDNS is a ZC protocol. What do you call these protocols when the "real" server exists? Are they suddenly non-ZC protocols? When state info is stored in different places such a server, router, or registry, this definition becomes harder to apply. In addition, I question the value of such a definition. Will it help protocol designers? Will it help end users? Will it help solve the problems as stated in the quote from STD-2? (nice quote btw) 1.2.4 Configuration It would be ideal if a host implementation of the Internet protocol suite could be entirely self-configuring. This would allow the whole suite to be implemented in ROM or cast into silicon, it would simplify diskless workstations, and it would be an immense boon to harried LAN administrators as well as system vendors. We have not reached this ideal; in fact, we are not even close. I don't think so. Even the STD-2 quote mentions making life easier for network admins (translates to users) and vendors (translates to fewer customer support calls). My opinion remains the same - we should just say no "user configuration". -myron From owner-zeroconf@merit.edu Thu Aug 10 17:18:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14171 for ; Thu, 10 Aug 2000 17:18:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 294115DDEC; Thu, 10 Aug 2000 17:18:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 151CC5DE11; Thu, 10 Aug 2000 17:18:24 -0400 (EDT) Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by segue.merit.edu (Postfix) with ESMTP id ACDA85DDEC for ; Thu, 10 Aug 2000 17:18:22 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id RAA00463 for ; Thu, 10 Aug 2000 17:18:21 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31444) id <01JST9TO837K90WLT4@mail.xerox.com> for zeroconf@merit.edu; Thu, 10 Aug 2000 17:18:00 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JST9SHXWM08ZO828@mail.xerox.com>; Thu, 10 Aug 2000 17:17:03 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 17:17:57 -0400 Content-return: allowed Date: Thu, 10 Aug 2000 17:17:56 -0400 From: "Nicolae, Dan" Subject: RE: Scalability vs. Periodic Messages (was Re: periodic messages) To: "'Erik Guttman Sun Frankfurt Staff Engineer'" , "Nicolae, Dan" , zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A62F8@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Erik, Thanks for the response. > > One step at a time. > > The distinction I want to draw is a priori vs. a posteriori > configuration. > > Whether you have a peer to peer or client server protocol is > a *secondary > characteristic.* The primary thing is *where does the > configuration come > from?* In SLP, it comes from the peers. The DA only caches that info > and makes it more efficient and robust to access. The example makes sense and it helps a lot. The criteria is *where from* (peers) and perhaps *how* (purely collaborative) the configuration is generated. The means it gets to a consumer is irrelevant. Right? However, I still have trouble mapping the above SLP exemplification to the proposed definition. Is it obvious that *where does the configuration come from* point translates to *a host obtains all configuration a posteriori*? I am tempted to link "a posteriori" to time (when) rather than source (where from) or method (how). BTW, "a priori" and "a posteriori" of what? Of the protocol's initialization/bootstrap? I understand that "a posteriori" refers to when the host obtains the information. It does not imply that the configuration was *built* by peers. Furthermore the configuration is built by peers "a priori". So, a zeroconf protocol requires "a priori" configuration. What is meant by configuration? Is it something like the IP address for a server (e.g. DNS server). This IS NOT needed "a priori". Or, it refers also to the information already *built* and in use by the network (e.g. data cached by a SLP DA based on previous registrations). This IS needed "a priori". Well, if I am the only one having trouble with the interpretation, I guess the definition stands up. But I would still love to see your above clarification in the draft. > The DA's presense or > absence does not change the result of any particular operation (except > how long it takes an how likely it is to not get clobbered > due to network > congestion). > I believe SLP DAs were brought up as the method of making SLP scalable. I was referring to the above exception in parenthesis. The DA absence makes SLP not scalable. Right? > >Example for DHCP: > >Is AutoIP zeroconf and DHCP non-zeroconf? Or, DHCP+AutoIP is > zeroconf and > >DHCP without AutoIP is non-zeroconf? > > DHCP is not zeroconf. The hosts in the network *get* their > configuration > from the DHCP server. > It must be my fault. It was the second attempt and I still did not get the question right. Let me try one last time: The draft talks about protocols "in the same area" and how some are zeroconf and others not: DHCP and AutoIP, DNS and mDNS, SLP and SLP (?). The draft also talks about transitions within those protocol pairs. Question: Are those protocols separate and when you make the transition you switch protocols. Or they are only modes of operation for a single protocol? Response 1: They are different protocols. Then what is the non-zeroconf peer for SLP? Response 2: The same protocol enhanced with zeroconf features; different modes of operation. Then the combination of DHCP and AutoIP (one protocol) is zeroconf or not? > A separate question, which some folks seem to get hung up on > is 'How does > the DHCP server get configured?' If the DHCP server makes up > addresses > on its own, isn't that zeroconf? I say no - since the > *other* hosts on > the network have nothing to say about it. > The other hosts don't have any contribution for AutoIP either. Except for IP conflict detection; but a DHCP client may check for IP conflicts as well and it can reject the lease. (I am figuring a DHCP server that makes up the IPs but it uses the same random algorithm as AutoIP does) > Once you turn on a configuration server, which determines the > configuration > for the network (DHCP, NIS, MADCAP, whatever) you are no > longer in a zeroconf > network, hosts are no longer building up configuration, > servers are handing > it out. > This makes sense again. The key is how the information is *built*. Purely collaborative (e.g. SLP registrations) or not. Right? However AutoIP does not use any collaborative method to build IP addresses. From this point of view the difference between AutoIP and a DHCP server that generates random linklocal IP addresses is questionable. > >In SLP case: > >SLP with DAs is not zeroconf because it relies on DAs (centralized). > > No - SLP doesn't rely on DAs. If the DAs go away, everything > continues > to work. Being a central point of data registration and > access doesn't > mean that it is configured. DAs are stateless except for what they > gather from the peers on the network. > Does SLP rely on DAs *for scalability* or not? If DAs go away from large networks does everything continue to work? Does SLP rely on boundary routers to prevent packet spillage? Does SLP automatically take any scalability-related action when there are no boundary routers; like using a lower TTL (<255)? If SLP didn't require that as soon as a DA is detected everybody must switch to unicast what would happen? I see this SLP requirement as a mandatory transition (to non-zeroconf if I may, I don't know how to call it). But zeroconf requirements leave room for coexistence. What if SLP were designed based on zeroconf requirements but the transition to DA-mode wasn't mandatory? > Conceivably you could do this DNS, too. Indeed. *If* the mDNS design mimics SLP and *if* you agree to drop some SLP enhanced functionality, then you can do with mDNS whatever SLP does. Would we need SLP for zeroconfig purposes then? *If feasible*, the idea of doing both zeroconfig name resolution and service discovery with a single protocol sounds appealing. > DHCP and MADCAP are *allocation* protocols. That is, if you do the > allocation with a server and the server fails, you lose your state. > Zeroconf protocols (as I am arguing we define them) do not rely on > this state - they *acquire* it from the net in a fully distributed > fashion. There is no central authority with respect to network > configuration. > Indeed DHCP and MADCAP fall under a different category than DNS and SLP. Would it be OK to specify that *allocation* protocols MAY coexist, while the others MUST transition? Wouldn't be easier to have separate definitions for what zeroconf is for each specific category? E.g.: An *allocation* protocol is zeroconf if the following conditions are met: 1 2 3 etc A *resolution* protocol is zeroconf if the following conditions are met: 1 2 3 etc Or, at least having a common, general and possibly interpretable definition. And then giving a clear definition and examples for each protocol category. (Something like you've given all over this reply and I found it very useful, thanks) ... > > If we leave it open whether protocols can require central servers > or not, we leave it open whether ZC protocols can have central > points of failure, misconfigured servers, two servers (not good > when we're talking DHCP), etc etc. > That's exactly the point! The definition must be very clear that a central server is unacceptable. The problem is how you formulate it to make clear? dan From owner-zeroconf@merit.edu Fri Aug 11 17:38:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05883 for ; Fri, 11 Aug 2000 17:38:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14D335DD92; Fri, 11 Aug 2000 17:38:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 011AC5DE26; Fri, 11 Aug 2000 17:38:14 -0400 (EDT) Received: from pasiphae.eastgw.xerox.com (pasiphae.xerox.com [208.140.33.23]) by segue.merit.edu (Postfix) with ESMTP id 390A95DD92 for ; Fri, 11 Aug 2000 17:38:13 -0400 (EDT) Received: from PMDF4.CINOPS.XEROX.COM (pmdf4.cinops.xerox.com [13.250.20.178]) by pasiphae.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id RAA09280 for ; Fri, 11 Aug 2000 17:38:11 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JSUOSO5EOW8ZOHU0@mail.xerox.com> for zeroconf@merit.edu; Fri, 11 Aug 2000 17:37:05 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JSUOSNP0408ZOAFK@mail.xerox.com>; Fri, 11 Aug 2000 17:37:04 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 17:38:00 -0400 Content-return: allowed Date: Fri, 11 Aug 2000 17:37:59 -0400 From: "Nicolae, Dan" Subject: RE: decision item for ZEROCONF WG: What is zeroconf? To: "'Erik Guttman'" , zeroconf@merit.edu Cc: myron.hattig@intel.com Message-id: <3654E69400ADD211A3A400805FA7CE24022A62F9@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Based on the recent discussions/clarifications I want to revise my initial opinion. *********************************************** I know believe that Erik's definition is the best one out of the three current choices. *********************************************** I still maintain that the "no a priori" formulation becomes clear only when backed up by clarifications and practical examples. I still believe that the definition leaves room to unforeseen and possibly undesirable interpretations. I would like to see more definition proposals, as I believe none of the three we have so far is accurate and clear. I am also making a two-cent proposal at the end of this message. Erik wrote: > > Myron wrote: > > Here are some examples, a burned in MAC address is used for > autonet in an > > ARP request to see if an IP address is used. Erik's > definition excludes > > autonet from being a ZC protocol. > > Autoconf for IPv4 uses a random #, not a mac address. Autoconf for > IPv6 uses a MAC address, but can be used with a random # as well. I think Myron is talking about the usage of ARP request to validate a generated IP address for uniqueness, not about the IP address generation based on the MAC address. So, his comment is valid. ARP is non-zeroconf because *it requires* "a priori" configuration (MAC address). Can a protocol be considered zeroconf when it mandates the use of a non-zeroconf protocol? Of course, it can be argued that AutoIP may work without IP conflict detection, without using ARP, or that ARP should be made zeroconf. Or that "configuration" strictly refers to the protocol itself and does not apply to auxiliary or lower-layer protocols. Anybody? Erik wrote: > There is nothing *wrong* with having a mac address, certificates, etc. > preconfigured. Its just that this is not *zero* configuration. A > protocol which makes use of a MAC address may be more efficient, but as > in the case of IPv6 addrconf, it is not necessary. > A protocol which *requires* the use of serial #s, certificates, etc. should not be a > zeroconf protocol, I maintain. This would preclude cheap generic > off-the-shelf components from being IP enabled. This makes sense if you exclude the above protocol dependency considerations and practical security aspects. Otherwise, as defined, zeroconf is and it may be forever just an ideal never reachable. > Remember the goal > from STD-2: > > 1.2.4 Configuration > > It would be ideal if a host implementation of the Internet > protocol suite could be entirely self-configuring. This would > allow the whole suite to be implemented in ROM or cast into > silicon, it would simplify diskless workstations, and it would > be an immense boon to harried LAN administrators as well as > system vendors. We have not reached this ideal; in fact, we > are not even close. It is always good to take a step back and the above quote is excellent. It may be worth no note that the term used is *selfconfig* and not *zeroconfig*. In my opinion *selfconfig* would not forbid the requirement of "a priori" configuration. Defaults and burn-in configuration are tolerable. Also, the reference is made to the *protocol suite* and not a particular *protocol*. This preserves the system-wide view and does not take a single protocol out of context. A self-configuring suite is not necessarily a collection of self-configuring protocols. Some may be non-selfconfig. An example is AutoIP. The ultimate goal of AutoIP is to configure IP and not itself. Despite AutoIP, IP remains non-selfconfig, but the collection of IP and AutoIP becomes selfconfig. Given all the considerations and arguments I've seen so far, I believe that it may help to reduce a bit the ambition of defining a zeroconfig protocol. We may keep Erik's definition of a zeroconfig protocol, as an ultimate goal. I am taking a shot at a more forgiving definition, about a selfconfig protocol: *********************************************************** A protocol is selfconfig if its main functionality, possibly reduced or less efficient, is possible when no explicit administrative configuration is available. *********************************************************** "No explicit administrative configuration" was stolen from STD3, RFC1122, section 3.2.2.9, page 46. I prefer using "administrative" instead of "user" to be closer to STD3 where protocols are categorized in "user" and "support" protocols (or "control" protocols in other cases e.g. ICMP). The main distinction is that a "support" or "control" protocol provides auxiliary system functions while a "user" protocol "provides service directly to the users". "Administrative" makes it apparent that the lack of administration is the problem and not the configuration that may be required from an user *by design* (e.g. provide an e-mail address or a password). "Explicit" is still arguable but at least indicates a clear administrative intent (like disable/enable a protocol, use this IP, use this server etc.) as opposed to configuration that was provided as a helper "a priori" (e.g. MAC address, digital certificate etc.) "Explicit" also allows for "implicit" administrative intent, such as when I turn on a SLP DA to regulate traffic, or a new router becomes available. Well, "explicit" (vs. "implicit") is questionable and it may be given up, but it covers the manual maintenance of DHCP scopes and DNS zone files (the centralized server issue). "Main functionality" does not preclude a protocol from being declared selfconfig when it does not provide "full functionality". For example, AutoIP can't help with the DHCP options (e.g. DNS server addresses) but it still is selfconfig because the main DHCP purpose is to get the IP configuration. "Possibly reduced or less efficient" is inspired from the "graceful degradation" concept seen for HTTP. E.g. AutoIP may not help with communication beyond linklocal scope when there is no router support. Or, some "auto" algorithms may be less efficient than when configuration is supplied by a human. Note that the above definition does not imply the existence of selfconfig and non-selfconfig peer protocols ("from the same area"). AutoIP would be the selfconfig version of DHCP but DHCP is not its non-selfconfig peer; DHCP is part of AutoIP, as DNS is part of mDNS. SLP would be selfconfig altogether, we can't split it in selfconfig and non-selfconfig parts. The idea is not to define a separate selfconfig protocol but to enhance a non-selfconfig protocol and make it selfconfig. Consequently, discussing transitions between protocols "from the same area" is no longer appropriate. (I don't think it was appropriate with the previous definitions either, because discussing the transition from non-zeroconfig to zeroconfig implies that a non-zeroconfig protocol is zeroconfig-aware, or the transition to non-zeroconfig never happened fully. E.g. once you switch to pure DHCP how can control be given back to AutoIP when DHCP has no idea about AutoIP? By resetting the protocol stack and allow AutoIP come back during the initialization? That would work, but it seems to belong to implementation rather) The analysis switches to how a zeroconf protocol improves its functionality based on new information (e.g. a router came on line, a conflict was detected), and it obeys to explicit administrative configuration (e.g. must use this IP and give up the linklocal one, can't multicast any longer) as soon as that configuration becomes available. The bottom line is that the protocol makes the *best* use of the available information at any time and it still functions. Self-configuration is a best-effort and graceful degradation is acceptable. (This is consistent with self-tuning techniques used by other protocols, like TCP e.g.). If there is an *acceptable* way for the protocol to achieve its purpose than it shall be used. Don't get killed without a fight. No IP address, make up one; no DNS server, find one or multicast etc. This is the zeroconf idea, isn't it? /dan From owner-zeroconf@merit.edu Mon Aug 14 12:21:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13869 for ; Mon, 14 Aug 2000 12:21:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9F6C25DDAF; Mon, 14 Aug 2000 12:21:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 88FDB5DDA8; Mon, 14 Aug 2000 12:21:35 -0400 (EDT) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by segue.merit.edu (Postfix) with ESMTP id 29AEE5DD98 for ; Mon, 14 Aug 2000 12:21:34 -0400 (EDT) Received: from agranat.com (alice.agranat.com [192.104.71.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id MAA01372 for ; Mon, 14 Aug 2000 12:21:29 -0400 Received: (from worley@localhost) by agranat.com (8.8.5/8.8.5) id MAA14174; Mon, 14 Aug 2000 12:21:28 -0400 Date: Mon, 14 Aug 2000 12:21:28 -0400 Message-Id: <200008141621.MAA14174@agranat.com> X-Authentication-Warning: alice.agranat.com: worley set sender to worley@alice.agranat.com using -f From: Dale Worley To: zeroconf@merit.edu In-reply-to: <3654E69400ADD211A3A400805FA7CE24022A62F9@USA0111MS2> (Dan.Nicolae@usa.xerox.com) Subject: Re: decision item for ZEROCONF WG: What is zeroconf? References: <3654E69400ADD211A3A400805FA7CE24022A62F9@USA0111MS2> Sender: owner-zeroconf@merit.edu Precedence: bulk From: "Nicolae, Dan" So, his comment is valid. ARP is non-zeroconf because *it requires* "a priori" configuration (MAC address). Can a protocol be considered zeroconf when it mandates the use of a non-zeroconf protocol? Of course, it can be argued that AutoIP may work without IP conflict detection, without using ARP, or that ARP should be made zeroconf. Or that "configuration" strictly refers to the protocol itself and does not apply to auxiliary or lower-layer protocols. Anybody? It's tough to jump into the middle of this, but it seems to me that the distinction is this: From the point of view of a *user*, a MAC address *is* zero-configuration because the device comes with one out of the box -- the user doesn't have to do any configuration. From the point of view of the device manufacturer, the manufacturer has to interface with the whole MAC address assignment infrastructure. So it's not zero-configuration from the manufacturer's point of view. From a practical/marketing point of view, making the protocol zero-configuration for the user is the important property. Indeed, it is probably an acceptable tradeoff to put *more* configuration effort on the manufacturer if it puts less on the user. Dale -- Dale R. Worley Engineer Agranat Systems Embedded Web Technology http://www.agranat.com/ From owner-zeroconf@merit.edu Tue Aug 15 22:38:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05026 for ; Tue, 15 Aug 2000 22:38:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 309F55DDE9; Tue, 15 Aug 2000 22:38:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 130B25DDE8; Tue, 15 Aug 2000 22:38:43 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 7D9DC5DDD7 for ; Tue, 15 Aug 2000 22:38:41 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id TAA07097 for ; Tue, 15 Aug 2000 19:38:40 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 19:38:40 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id TAA18078 for ; Tue, 15 Aug 2000 19:38:40 -0700 (PDT) Message-Id: <200008160238.TAA18078@scv1.apple.com> Subject: Re: comments on requirements draft 04 Date: Tue, 15 Aug 2000 19:40:47 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Some previous comments: >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. >After struggling with this for a long time, my conclusion is >that the existents of a server isn't the issue. The issue is >USER configuration. In other words, ease of use for the user is >the only concern. The server may exist but if the user doesn't >see it, it doesn't matter. >I think Erik's got it just right - ZC means ABSOLUTELY no >external configuration, *in particular* no fetching from >routers, service repositories, etc. I think we should say that no pair of ZEROCONF-compliant hosts, when properly connected together by a common physical link technology, should be prevented from communication merely by lack of additional infrastructure services. There may be other things that prevent ZEROCONF-compliant hosts from communicating, such as not having the correct cable (this is why wireless is good), or their batteries being dead, or, in the case of two ZEROCONF-compliant printers, them simply having nothing interesting to say to each other -- but two hosts that are capable of useful communication should not be prevented from doing so because there is no DHCP server, or no DNS server, etc. >a host using DHCP protocol for IP host config is zero-conf if the >DHCP-server is also autoconfig. >Using that principle, Zeroconfig means no human intervention >ANYWHERE. If that requires a central box, then why isn't that OK >- as long as the central box doesn't require human intervention. When two strangers on a train meet, merely requiring that one of them remembered to bring the "central box" with them is too much human intervention, no matter how automatic the central box is. This is why I keep pushing to have the motivating example of two computers in an ad-hoc situation, to remind us of what we're doing. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 22:44:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05118 for ; Tue, 15 Aug 2000 22:44:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96BF95DDEA; Tue, 15 Aug 2000 22:44:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 86D1F5DDE8; Tue, 15 Aug 2000 22:44:29 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id EB88B5DDD7 for ; Tue, 15 Aug 2000 22:44:27 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id TAA07626 for ; Tue, 15 Aug 2000 19:44:27 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 19:44:27 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id TAA13864 for ; Tue, 15 Aug 2000 19:44:26 -0700 (PDT) Message-Id: <200008160244.TAA13864@scv2.apple.com> Subject: Re: proposed new charter text Date: Tue, 15 Aug 2000 19:46:34 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >The following is a revised charter document. The changes from the existing >charter are indicated by change bars in the right column. The original >text is included as well, for comparison. > >Please discuss. > ... >* Automatic Host Configuration (IP address, network prefix, > gateway router location, DNS server location) I think we need to tidy up this wording. "DNS server location" ? ! Each interface on each host needs an appropriate IP address, and possibly an appropriate address mask. I think the term "Host Configuration" is too overloaded with additional meaning -- i.e. all the stuff that's usually in a DHCP packet -- like DNS server addresses -- and that directly conflicts with one of our other goals which is to operate without a conventional DNS server. Lets say what we mean here, which is Interface Configuration, or perhaps even just Interface Address Selection. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 22:49:35 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05154 for ; Tue, 15 Aug 2000 22:49:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15D655DDED; Tue, 15 Aug 2000 22:49:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 060585DDE8; Tue, 15 Aug 2000 22:49:27 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 1DF9C5DDD7 for ; Tue, 15 Aug 2000 22:49:25 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id TAA08229 for ; Tue, 15 Aug 2000 19:49:24 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 19:49:24 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id TAA20295 for ; Tue, 15 Aug 2000 19:49:23 -0700 (PDT) Message-Id: <200008160249.TAA20295@scv1.apple.com> Subject: RE: comments on requirements draft 04 Date: Tue, 15 Aug 2000 19:51:31 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >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 * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 22:52:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05221 for ; Tue, 15 Aug 2000 22:52:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 144ED5DDF0; Tue, 15 Aug 2000 22:52:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ECC0A5DDE8; Tue, 15 Aug 2000 22:52:06 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 58DD45DDD7 for ; Tue, 15 Aug 2000 22:52:05 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id TAA03717; Tue, 15 Aug 2000 19:52:27 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 19:52:01 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE6C@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Stuart Cheshire'" , zeroconf@merit.edu Subject: RE: comments on requirements draft 04 Date: Tue, 15 Aug 2000 19:52:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-zeroconf@merit.edu Precedence: bulk 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 -----Original Message----- From: Stuart Cheshire [mailto:cheshire@apple.com] Sent: Tuesday, August 15, 2000 7:52 PM To: zeroconf@merit.edu Subject: RE: comments on requirements draft 04 >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 * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 22:54:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05235 for ; Tue, 15 Aug 2000 22:54:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53A405DDD7; Tue, 15 Aug 2000 22:54:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 42A9F5DDE8; Tue, 15 Aug 2000 22:54:44 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id A6B5E5DDD7 for ; Tue, 15 Aug 2000 22:54:42 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id TAA01666 for ; Tue, 15 Aug 2000 19:54:40 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 19:54:40 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id TAA14277 for ; Tue, 15 Aug 2000 19:54:39 -0700 (PDT) Message-Id: <200008160254.TAA14277@scv2.apple.com> Subject: RE: comments on requirements draft 04 Date: Tue, 15 Aug 2000 19:56:47 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >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. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 23:03:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05378 for ; Tue, 15 Aug 2000 23:03:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DA3D5DDF4; Tue, 15 Aug 2000 23:02:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6CB1C5DDF3; Tue, 15 Aug 2000 23:02:24 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id BEAFE5DDE8 for ; Tue, 15 Aug 2000 23:02:22 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA09456 for ; Tue, 15 Aug 2000 20:02:22 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 20:02:21 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id UAA21807 for ; Tue, 15 Aug 2000 20:02:21 -0700 (PDT) Message-Id: <200008160302.UAA21807@scv1.apple.com> Subject: RE: periodic messages (was RE: comments on requirements draft 04) Date: Tue, 15 Aug 2000 20:04:28 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Periodic actions ARE required. >I didn't think the requirements were written in such a way that >would automatically require such a protocol - that's why in the >previous note I made the distinction between ACTIONs and MESSAGES. I think this is one of those, "If a tree falls in a forest and no one is around..." philosophical questions. If a host performs an action and sends no messages, did it really perform any action? Protocol design concerns the externally visible behaviour of devices, not their internal implementation. Any implementation that generates the correct externally visible behaviour is valid. It is only useful for us to design protocols by talking about the content of the messages on the wire, and the times at which they are sent. Everything else is an implementation decision. >I'm concerned that your statements over periodic messages conflicts with >the draft. Specifically, the draft states that scalability is not a >major issue for zeroconf, as it is expected that zeroconf will be used >in small evironments. Network scalability is not the only concern. Small networks may also slow links, so wasting bandwidth for no reason is always a bad idea. Another big concern is power management. Modern computers go to sleep to conserve power. Any requirement for periodic actions interferes with that. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 23:10:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05424 for ; Tue, 15 Aug 2000 23:10:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F9905DDF5; Tue, 15 Aug 2000 23:10:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 007475DDF3; Tue, 15 Aug 2000 23:10:31 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 9344C5DDE8 for ; Tue, 15 Aug 2000 23:10:30 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA03336 for ; Tue, 15 Aug 2000 20:10:30 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Tue, 15 Aug 2000 20:10:29 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id UAA03571 for ; Tue, 15 Aug 2000 20:10:08 -0700 (PDT) Message-Id: <200008160310.UAA03571@scv3.apple.com> Subject: Re: Comments on IP host config requirents in draft#4 Date: Tue, 15 Aug 2000 20:12:36 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >By definition, a default route is used >to communicate with hosts off the local subnet. That's not the definition of a default route. A default route is the route you use if you don't find a match in any other route in your routing table. Hence the use of the word, "default." Most Windows and Mac OS machines only allow two entries in the routing table -- "my local ethernet" and "everything else", leading people to believe that a "default route" is something fundamental about IP networking. It is not. Having a default route just says, "When you don't know what to do, send the packet to this guy, who might know what to do with it." Because Windows and Mac OS machines don't know what to do quite a lot of the time, people tend to over-emphasize the importance of that case. >All hosts MUST configure a default router Large chunks of the Internet backbone are "default-free", meaning that the machines don't have a default route entry in their routing table, because they all know exactly what to do with every packet, and never need to forward any packet to some other machine because they don't know what to do with it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 23:13:19 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05455 for ; Tue, 15 Aug 2000 23:13:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F35D5DDF3; Tue, 15 Aug 2000 23:13:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E1AB5DDF2; Tue, 15 Aug 2000 23:13:11 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id D995A5DDE8 for ; Tue, 15 Aug 2000 23:13:09 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA11023 for ; Tue, 15 Aug 2000 20:13:08 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 20:13:08 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id UAA17307 for ; Tue, 15 Aug 2000 20:13:08 -0700 (PDT) Message-Id: <200008160313.UAA17307@scv2.apple.com> Subject: RE: comments on requirements draft 04 Date: Tue, 15 Aug 2000 20:15:15 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >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. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Tue Aug 15 23:17:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05508 for ; Tue, 15 Aug 2000 23:17:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E1805DDF7; Tue, 15 Aug 2000 23:15:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1DA8F5DDF2; Tue, 15 Aug 2000 23:15:44 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 9DDC35DDE8 for ; Tue, 15 Aug 2000 23:15:42 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA11326 for ; Tue, 15 Aug 2000 20:15:42 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 15 Aug 2000 20:15:41 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id UAA22737 for ; Tue, 15 Aug 2000 20:15:41 -0700 (PDT) Message-Id: <200008160315.UAA22737@scv1.apple.com> Subject: IPv4 Scoped Address Architecture Date: Tue, 15 Aug 2000 20:17:48 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >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). > >+ This is more complicated: It leads to a scoped > address architecture, as per IPv6: I talked to Steve Deering about this and he said that the problem with IPv6 scoped addresses is knowing the scope of site-local addresses, especially on multi-homed hosts that may have two interfaces that may or may not be in the same site. As long as the scope is just one of two cases -- either "link-local" or "everything else" -- he said it should not be too hard. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Wed Aug 16 06:37:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21442 for ; Wed, 16 Aug 2000 06:37:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CF955DDAE; Wed, 16 Aug 2000 06:37:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D3055DDAA; Wed, 16 Aug 2000 06:37:03 -0400 (EDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by segue.merit.edu (Postfix) with ESMTP id 087265DD9C for ; Wed, 16 Aug 2000 06:37:02 -0400 (EDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id GAA02624; Wed, 16 Aug 2000 06:36:37 -0400 Message-Id: <200008161036.GAA02624@hygro.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IPv4 Scoped Address Architecture In-Reply-To: Message from Stuart Cheshire of "Tue, 15 Aug 2000 20:17:48 PDT." <200008160315.UAA22737@scv1.apple.com> Date: Wed, 16 Aug 2000 06:36:37 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > As long as the scope is just one of two cases -- either "link-local" or > "everything else" -- he said it should not be too hard. It also helps if a host has only one interface, i.e., is NOT multihomed. For multihomed hosts, you run into the problem that when sending to a particular given link-local address, you don't know which interface to send the packet out on. Thomas From owner-zeroconf@merit.edu Wed Aug 16 07:54:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22587 for ; Wed, 16 Aug 2000 07:54:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52ABE5DDAA; Wed, 16 Aug 2000 07:54:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 41D9F5DD9C; Wed, 16 Aug 2000 07:54:29 -0400 (EDT) Received: from multicasttech.com (ns2.multicasttech.com [63.105.122.8]) by segue.merit.edu (Postfix) with ESMTP id 34BF65DD93 for ; Wed, 16 Aug 2000 07:54:28 -0400 (EDT) Received: from [209.8.42.22] (HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.3) with ESMTP id 520722; Wed, 16 Aug 2000 07:59:03 -0400 Message-ID: <399A81DB.72A280FA@21rst-century.com> Date: Wed, 16 Aug 2000 07:58:19 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: comments on requirements draft 04 References: <200008160238.TAA18078@scv1.apple.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stuart Cheshire wrote: > >Using that principle, Zeroconfig means no human intervention > >ANYWHERE. If that requires a central box, then why isn't that OK > >- as long as the central box doesn't require human intervention. > > When two strangers on a train meet, merely requiring that one of them > remembered to bring the "central box" with them is too much human > intervention, no matter how automatic the central box is. This is why I > keep pushing to have the motivating example of two computers in an ad-hoc > situation, to remind us of what we're doing. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer I didn't say that they were necessarily strangers. Here is more or less what I had in mind - you buy a stereo. (The central box.) It comes with (or you can buy additionally) smart speakers, which you can plug in anywhere in the house, and they'll play from the stereo (maybe using s wireless protocol). The stereo has all of the smarts, and the multiple playback devices, and without it the speakers don't work. Maybe it even acts as a DHCP server for them. If that requires no human intervention, why isn't that zeroconf ? Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-zeroconf@merit.edu Wed Aug 16 12:04:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28885 for ; Wed, 16 Aug 2000 12:04:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCDDF5DDA0; Wed, 16 Aug 2000 12:04:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ADB665DDEC; Wed, 16 Aug 2000 12:04:35 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 65B8B5DDA0 for ; Wed, 16 Aug 2000 12:04:33 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id JAA07532; Wed, 16 Aug 2000 09:04:40 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Aug 2000 09:04:14 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE6D@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Thomas Narten'" , Stuart Cheshire Cc: zeroconf@merit.edu Subject: RE: IPv4 Scoped Address Architecture Date: Wed, 16 Aug 2000 09:04:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Hi, But isn't multi-homed actually quite likely in SOHO environments where ZC would be useful? A given host (e.g., a laptop) might easily have both a IEEE 802.11 (Wireless Ethernet) and an IRDA (infra-red) interface. This presumption that all of the devices on a ZC-based small network will be on the SAME link using only ONE interface technology doesn't seem very safe for postulating requirements. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Thomas Narten [mailto:narten@raleigh.ibm.com] Sent: Wednesday, August 16, 2000 3:37 AM To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IPv4 Scoped Address Architecture > As long as the scope is just one of two cases -- either "link-local" or > "everything else" -- he said it should not be too hard. It also helps if a host has only one interface, i.e., is NOT multihomed. For multihomed hosts, you run into the problem that when sending to a particular given link-local address, you don't know which interface to send the packet out on. Thomas From owner-zeroconf@merit.edu Wed Aug 16 12:18:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29308 for ; Wed, 16 Aug 2000 12:18:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35B555DDDE; Wed, 16 Aug 2000 12:18:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 244E05DDC8; Wed, 16 Aug 2000 12:18:09 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by segue.merit.edu (Postfix) with ESMTP id AF7855DD8C for ; Wed, 16 Aug 2000 12:18:07 -0400 (EDT) Received: from mosquito.extremenetworks.com ([10.0.8.82]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id QVZ8S8Y7; Wed, 16 Aug 2000 09:17:49 -0700 Message-Id: <4.3.2.7.2.20000816121100.00abc860@sol.extremenetworks.com> X-Sender: rja@sol.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 16 Aug 2000 12:13:48 -0400 To: "McDonald, Ira" From: RJ Atkinson Subject: RE: IPv4 Scoped Address Architecture Cc: zeroconf@merit.edu In-Reply-To: <1115A7CFAC25D311BC4000508B2CA5375ECE6D@mailsrvnt02.enet.sh arplabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:04 16/08/00, McDonald, Ira wrote: >This presumption that all of the devices on a >ZC-based small network will be on the SAME link >using only ONE interface technology doesn't seem >very safe for postulating requirements. Seems quite reasonable to me. An anecdotal description of what I think ZeroConf should achieve is this: Make IP-based networks as easy to install/use as the traditional AppleTalk/EtherTalk networks have long been with the Apple Macintosh systems. So I'd rule out any uncommon h/w or s/w configuration. Since the vast majority of desktop and laptop systems are single interface, that seems to be a quite reasonable scope limit for this WG. Ran rja@inet.org From owner-zeroconf@merit.edu Wed Aug 16 12:48:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29937 for ; Wed, 16 Aug 2000 12:48:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACD545DDBF; Wed, 16 Aug 2000 12:48:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 62CDA5DDDF; Wed, 16 Aug 2000 12:48:30 -0400 (EDT) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by segue.merit.edu (Postfix) with ESMTP id 1EB715DDBF for ; Wed, 16 Aug 2000 12:48:28 -0400 (EDT) Received: from agranat.com (alice.agranat.com [192.104.71.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id MAA17555 for ; Wed, 16 Aug 2000 12:48:27 -0400 Received: (from worley@localhost) by agranat.com (8.8.5/8.8.5) id MAA13607; Wed, 16 Aug 2000 12:48:26 -0400 Date: Wed, 16 Aug 2000 12:48:26 -0400 Message-Id: <200008161648.MAA13607@agranat.com> X-Authentication-Warning: alice.agranat.com: worley set sender to worley@alice.agranat.com using -f From: Dale Worley To: zeroconf@merit.edu In-reply-to: <1115A7CFAC25D311BC4000508B2CA5375ECE6D@mailsrvnt02.enet.sharplabs.com> (imcdonald@sharplabs.com) Subject: Multiple interfaces and zero-conf References: <1115A7CFAC25D311BC4000508B2CA5375ECE6D@mailsrvnt02.enet.sharplabs.com> Sender: owner-zeroconf@merit.edu Precedence: bulk From: "McDonald, Ira" But isn't multi-homed actually quite likely in SOHO environments where ZC would be useful? A given host (e.g., a laptop) might easily have both a IEEE 802.11 (Wireless Ethernet) and an IRDA (infra-red) interface. I can easily envision my company making a device for home/SOHO use that's a DSL modem, firewall, etc. gateway with multiple LAN interfaces (Ethernet, wireless Ethernet, IRDA, Bluetooth, etc.). Ideally, it would zero-conf on all the LAN interfaces and bridge them all together (transparently to the user), together with establishing routing and firewalling to/from the outside world. (The DSL modem interface would probably be configured by the service provider's provisioning system, so it isn't a zero-conf issue.) There could easily be a market for tens of millions of such devices, given the rate DSL is being rolled out. Dale -- Dale R. Worley Engineer Agranat Systems Embedded Web Technology http://www.agranat.com/ From owner-zeroconf@merit.edu Wed Aug 16 14:42:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01918 for ; Wed, 16 Aug 2000 14:42:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 258EE5DE22; Wed, 16 Aug 2000 14:41:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 15A815DE0A; Wed, 16 Aug 2000 14:41:53 -0400 (EDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by segue.merit.edu (Postfix) with ESMTP id 9C5105DDF6 for ; Wed, 16 Aug 2000 14:41:51 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id OAA25037 for ; Wed, 16 Aug 2000 14:41:48 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31444) id <01JT1HSMGLWG90XG8P@mail.xerox.com> for zeroconf@merit.edu; Wed, 16 Aug 2000 14:32:37 EST Received: from usaxeroxbh1.USA.XEROX.COM ([13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JT1HSFBF5091VRCD@mail.xerox.com> for zeroconf@merit.edu; Wed, 16 Aug 2000 14:32:23 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 14:32:23 -0400 Content-return: allowed Date: Wed, 16 Aug 2000 14:32:16 -0400 From: "Nicolae, Dan" Subject: zeroconf == linklocal ? To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A6303@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > This presumption that all of the devices on a > ZC-based small network will be on the SAME link > using only ONE interface technology doesn't seem > very safe for postulating requirements. > ... > > It also helps if a host has only one interface, i.e., is NOT > multihomed. For multihomed hosts, you run into the problem that when > sending to a particular given link-local address, you don't know which > interface to send the packet out on. > ... Multihoming also covers hosts with a single physical interface but multiple IP addresses. STD3 RFC1122 section 3.3.4. discusses flavors of Local Multihoming. [It is interesting to note that the concept of Logical Multihoming, where there is a single physical network (linklocal) but multiple logical networks, does not necessarily involve the presence of routers.] Provided that AutoIP may coexist with DHCP, multihoming considerations are de-facto influencing zeroconf requirements. ~~~ But I actually wanted to ask a different question: Is ZeroConf WG concerned at all with requirements that go beyond linklocal? (I should better say direct communication instead of linklocal: no routers.) Can requirements be split (and prioritized) in "linklocal" and "non-linklocal"? > > As long as the scope is just one of two cases -- either "link-local" or > "everything else" -- he said it should not be too hard. > Thanks, /dan From owner-zeroconf@merit.edu Thu Aug 17 16:26:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04095 for ; Thu, 17 Aug 2000 16:26:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAA6C5DDFD; Thu, 17 Aug 2000 16:26:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AA7C45DDFA; Thu, 17 Aug 2000 16:26:24 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 550915DDE9 for ; Thu, 17 Aug 2000 16:26:23 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA24696 for ; Thu, 17 Aug 2000 13:26:22 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 17 Aug 2000 13:26:22 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id NAA11908 for ; Thu, 17 Aug 2000 13:26:22 -0700 (PDT) Message-Id: <200008172026.NAA11908@scv1.apple.com> Subject: Re: comments on requirements draft 04 Date: Thu, 17 Aug 2000 13:28:32 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I didn't say that they were necessarily strangers. But I did. The people in my example *are* strangers, and if a proposed solution can't solve that problem then it hasn't solved the zeroconf problem. >Here is more or less what I had in mind - you buy a stereo. (The central >box.) It comes with (or you can buy additionally) smart speakers, which you >can plug in anywhere in the house, and they'll play from the stereo (maybe >using s wireless protocol). The stereo has all of the smarts, and the >multiple playback devices, and without it the speakers don't work. >Maybe it even acts as a DHCP server for them. >If that requires no human intervention, why isn't that zeroconf ? It is not "zeroconf" because "zeroconf" does not exist to be a marketing buzzword. If you want to sell a DHCP server, then call it a DHCP server, not something else. The ultimate purpose of the work that goes on in the IETF is to define new protocols, where new protocols are needed to facilitate development of interoperable products that do useful things. The scenario you describe can be done today, using DHCP. We don't need a new protocol (or a new name for an old protocol) to make that possible. DHCP may well be the best answer for the situation you describe. If we decide that a DHCP server is the right answer for all situations, then we don't need a "zeroconf" working group, because the DHCP protocol is already defined. However, a DHCP server doesn't solve the strangers-on-a-train problem, ergo we do need something new, and by the same logic that new thing is NOT a DHCP server. The new thing is for environments where there is no DHCP server. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Thu Aug 17 16:33:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04202 for ; Thu, 17 Aug 2000 16:33:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96B855DE00; Thu, 17 Aug 2000 16:32:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8293A5DE07; Thu, 17 Aug 2000 16:32:16 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 245D55DE00 for ; Thu, 17 Aug 2000 16:32:15 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id NAA25687 for ; Thu, 17 Aug 2000 13:32:14 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 17 Aug 2000 13:32:14 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id NAA12944 for ; Thu, 17 Aug 2000 13:32:13 -0700 (PDT) Message-Id: <200008172032.NAA12944@scv1.apple.com> Subject: RE: IPv4 Scoped Address Architecture Date: Thu, 17 Aug 2000 13:34:24 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >It also helps if a host has only one interface, i.e., is NOT >multihomed. For multihomed hosts, you run into the problem that >when sending to a particular given link-local address, you don't >know which interface to send the packet out on. I think this is an API issue, not a protocol issue. The problem is APIs that only allow you to specify the destination address for a packet or connection, instead of specifying a source interface and a destination address, or a source/destination address pair. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Thu Aug 17 17:08:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04672 for ; Thu, 17 Aug 2000 17:08:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B519F5DE02; Thu, 17 Aug 2000 17:08:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A1B165DE06; Thu, 17 Aug 2000 17:08:33 -0400 (EDT) Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by segue.merit.edu (Postfix) with ESMTP id 3CE4A5DE02 for ; Thu, 17 Aug 2000 17:08:32 -0400 (EDT) Received: from kaipara.live.com (sdsl-208-185-235-154.dsl.sjc.megapath.net [208.185.235.154]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id OAA29990 for ; Thu, 17 Aug 2000 14:07:31 -0700 (PDT) Message-Id: <4.3.1.1.20000817135459.00c452a0@localhost> X-Sender: rsf@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 17 Aug 2000 14:07:27 -0700 To: zeroconf@merit.edu From: Ross Finlayson Subject: How to overcome this WG's flailing In-Reply-To: <200008172026.NAA11908@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 01:28 PM 8/17/00, Stuart Cheshire wrote: > >I didn't say that they were necessarily strangers. > >But I did. The people in my example *are* strangers, and if a proposed >solution can't solve that problem then it hasn't solved the zeroconf >problem. This, in a nutshell, illustrates the problem that this WG seems to be having. We're flailing about, trying to define what "zeroconf" means, but without a firm basis for forming such a definition. Wouldn't a better approach be to first get consensus on a small set of examples/situations/scenarios that we must be able to support. (Stuart's "strangers on a train" scenario could be one of these.) These examples/situations/scenarios would be described in sufficient detail to ensure that we all understand exactly what they entail, and that we have consensus that they must be supportable. Then, and *only then*, we could define "zeroconf" as being "a *minimal* set of protocols that support these examples/situations/scenarios", and work towards defining what these protocols will be. In other words, we should first try to get consensus about *what* we want to support, and then get consensus on *how*. Ross. From owner-zeroconf@merit.edu Thu Aug 17 17:33:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05073 for ; Thu, 17 Aug 2000 17:33:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71CB95DE11; Thu, 17 Aug 2000 17:32:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 60F745DE0E; Thu, 17 Aug 2000 17:32:21 -0400 (EDT) Received: from wodc7-1.relay.mail.uu.net (wodc7-1.relay.mail.uu.net [199.171.54.114]) by segue.merit.edu (Postfix) with ESMTP id 1ADAF5DE06 for ; Thu, 17 Aug 2000 17:32:20 -0400 (EDT) Received: from 21rst-century.com by wodc7mr0.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.105.122.50]) id QQjcrm11290; Thu, 17 Aug 2000 21:32:18 GMT Message-ID: <399C598D.A953F87B@21rst-century.com> Date: Thu, 17 Aug 2000 17:30:53 -0400 From: Thomas Marshall Eubanks Reply-To: tme@21rst-century.com X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ross Finlayson Cc: zeroconf@merit.edu Subject: Re: How to overcome this WG's flailing References: <4.3.1.1.20000817135459.00c452a0@localhost> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ross Finlayson wrote: > At 01:28 PM 8/17/00, Stuart Cheshire wrote: > > >I didn't say that they were necessarily strangers. > > > >But I did. The people in my example *are* strangers, and if a proposed > >solution can't solve that problem then it hasn't solved the zeroconf > >problem. > > This, in a nutshell, illustrates the problem that this WG seems to be > having. We're flailing about, trying to define what "zeroconf" means, but > without a firm basis for forming such a definition. > > Wouldn't a better approach be to first get consensus on a small set of > examples/situations/scenarios that we must be able to support. (Stuart's > "strangers on a train" scenario could be one of these.) These > examples/situations/scenarios would be described in sufficient detail to > ensure that we all understand exactly what they entail, and that we have > consensus that they must be supportable. > > Then, and *only then*, we could define "zeroconf" as being "a *minimal* set > of protocols that support these examples/situations/scenarios", and work > towards defining what these protocols will be. > > In other words, we should first try to get consensus about *what* we want > to support, and then get consensus on *how*. > > Ross. OK, here is one : An Internet radio that plugs into (wirelesses into ?) a home network and is able to receive multicasts from (say) 232/8 by just turing it on. If you can't do that zero config, then you might as well close the group down. Here is another (more complicated) : An Internet radio and a home stereo that plug into a home network and are able to find and communicate with each other, so that (say) the radio is able to access storage on the stereo. I feel that this discussion gets too abstract sometimes... Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@on-the-i.com tme@multicasttech.com http://www.on-the-i.com http://www.buzzwaves.com From owner-zeroconf@merit.edu Thu Aug 17 17:44:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05197 for ; Thu, 17 Aug 2000 17:44:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 33FA45DE06; Thu, 17 Aug 2000 17:44:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20E725DE07; Thu, 17 Aug 2000 17:44:17 -0400 (EDT) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by segue.merit.edu (Postfix) with ESMTP id A7B7D5DE06 for ; Thu, 17 Aug 2000 17:44:15 -0400 (EDT) Received: from agranat.com (alice.agranat.com [192.104.71.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id RAA05248 for ; Thu, 17 Aug 2000 17:44:15 -0400 Received: (from worley@localhost) by agranat.com (8.8.5/8.8.5) id RAA31583; Thu, 17 Aug 2000 17:44:15 -0400 Date: Thu, 17 Aug 2000 17:44:15 -0400 Message-Id: <200008172144.RAA31583@agranat.com> X-Authentication-Warning: alice.agranat.com: worley set sender to worley@alice.agranat.com using -f From: Dale Worley To: zeroconf@merit.edu In-reply-to: <200008172032.NAA12944@scv1.apple.com> (message from Stuart Cheshire on Thu, 17 Aug 2000 13:34:24 -0700) Subject: Re: IPv4 Scoped Address Architecture References: <200008172032.NAA12944@scv1.apple.com> Sender: owner-zeroconf@merit.edu Precedence: bulk From: Stuart Cheshire >It also helps if a host has only one interface, i.e., is NOT >multihomed. For multihomed hosts, you run into the problem that >when sending to a particular given link-local address, you don't >know which interface to send the packet out on. The problem is APIs that only allow you to specify the destination address for a packet or connection, instead of specifying a source interface and a destination address, or a source/destination address pair. Conversely, it's a side-effect of the fact that link-local addresses are a newish feature of IP. Historically, routing has always been a problem, but there was always a "right" interface for any given destination. But this problem suggests caution if there is more than one network "in the vicinity" using link-local addresses. Ideally, no device should have interfaces onto two networks that use the same space of local addresses, unless the device is actively bridging them so that colliding address assignments cannot happen. Dale -- Dale R. Worley Engineer Agranat Systems Embedded Web Technology http://www.agranat.com/ From owner-zeroconf@merit.edu Thu Aug 17 18:19:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05487 for ; Thu, 17 Aug 2000 18:19:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2AACC5DDE9; Thu, 17 Aug 2000 18:18:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 16AF85DE07; Thu, 17 Aug 2000 18:18:54 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id BBB5C5DDE9 for ; Thu, 17 Aug 2000 18:18:52 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id PAA19432 for ; Thu, 17 Aug 2000 15:18:50 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 17 Aug 2000 15:18:50 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id PAA06104 for ; Thu, 17 Aug 2000 15:18:26 -0700 (PDT) Message-Id: <200008172218.PAA06104@scv3.apple.com> Subject: Re: How to overcome this WG's flailing Date: Thu, 17 Aug 2000 15:21:00 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >This, in a nutshell, illustrates the problem that this WG seems to be >having. We're flailing about, trying to define what "zeroconf" means, >but without a firm basis for forming such a definition. Thanks Ross. You are right about this. The key thing we need to establish is that "zeroconf" is not just a marketing buzzword. It doesn't mean, "Make my Cable Modem easier to use." Anything communicating over the global Internet is by definition not zeroconf. Zeroconf means still being able to perform IP communication when you're NOT connected to any external infrastructure. I agree that many things about IP and the Internet could be made easier, but this WG is not out to fix every single problem with IP. The charter of this WG is to make IP usable when there is no external infrastructure. The charter specifically limits zeroconf to internetworks with at most ONE router. The Internet, last time I checked, had more than one router. (And don't make the mistake of claiming that you can have a home internetwork with one router that's "connected" to the Internet. Once you connect two internetworks, they're not separate any more. That's like pouring a cup of coffee into the sea and claiming that you still have a cup of coffee. If you're connected to the Internet then you're part of it, and the aggregate internetwork as a whole has more than one router.) I will try to work out a clear statement of what I think the definitions of a zeroconf protocol and a zeroconf host should be. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Thu Aug 17 18:21:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05563 for ; Thu, 17 Aug 2000 18:21:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB8985DE09; Thu, 17 Aug 2000 18:21:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A5D25DE08; Thu, 17 Aug 2000 18:21:06 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 42BC15DE07 for ; Thu, 17 Aug 2000 18:21:05 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id PAA17111 for ; Thu, 17 Aug 2000 15:21:03 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 17 Aug 2000 15:21:03 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id PAA06777 for ; Thu, 17 Aug 2000 15:20:38 -0700 (PDT) Message-Id: <200008172220.PAA06777@scv3.apple.com> Subject: Re: comments on requirements draft 04 Date: Thu, 17 Aug 2000 15:23:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I think we should say that no pair of ZEROCONF-compliant hosts, when >properly connected together by a common physical link technology, should >be prevented from communication merely by lack of additional >infrastructure services. I've been thinking about this some more, and I think I'm convinced that stating the requirement this way is the best way to express what zeroconf is about. Trying to talk about servers, or lack thereof, or a priori configuration, or lack thereof, or numbers of hosts or size of network always seems to end up self-contradictory. (When every host is running a mini-mDNS server, then does that make them non-zeroconf because there are "servers" in the network?) What we're really trying to achieve is simply the ability for IP hosts to communicate. Presence of DHCP servers, routers, and DNS servers helps enable hosts to communicate with other hosts worldwide. Lack of DHCP servers, routers, and DNS servers should not render the hosts deaf and mute. They may have reduced IP communication capability, but they should not be reduced to no IP communication capability at all. With that in mind, I think we should say that: A zeroconf protocol is able to operate correctly in the absence of either user configuration or external infrastructure services (e.g. conventional DHCP or DNS servers). Correct operation means that a pair of zeroconf-compliant hosts using compatible link-layer interfaces, not physically separated beyond the reasonable operating range of those interfaces, are never prevented from communicating by lack of manual configuration or external infrastructure. Some explanations for the wording: 1. Note that this says, "*able* to operate correctly...." It does not say, "MUST NOT use user configuration", or, "MUST NOT use infrastructure services." If a user wants to chose ("configure") a name for their host, then they can (and they should be told when it is invalid for some reason). However, if they don't then the protcol should be able to make up a sensible name on its own. If a user wants to chose ("configure") an IP address for an interface, then they should be able to do that (and they should be told when it is invalid for some reason). However, if they don't then the protcol should be able to make up a sensible address on its own. 2. In my previous version of the text, I said, "properly connected together by a common physical link technology." I realized later that if you have to connect two Ethernet ports using a crossover cable, and you don't have a crossover cable, then you are prevented from communicating due to lack of that "infrastructure". If a vendor labels a product "zeroconf", but the user then has to go out and buy an Ethernet crossover cable to make it work, how is that qualitatively different to having to buy an Ethernet hub, or having to buy a little mini-router with a DHCP server in it? I think our definition of zeroconf can and should address this. If a vendor wants to label a product "zeroconf", then the box must contain *everything* required for communication with other link-compatible zeroconf devices. If the product doesn't have a bidirectional auto-sensing Ethernet port, then the box needs to include a crossover cable as well. If the product has some wireless technology that can't communicate peer-to-peer, then the box needs to include a wireless hub. If the hub's too expensive to include one with every unit, then you can't put "zeroconf" on the box. 3. Note also that I said, "using compatible link-layer interfaces." Zeroconf IP can't be more compatible than the underlying link-layer it is running over. For this reason, vendors who choose to label their products "zeroconf" will need to label their products as "zeroconf-over-something", as shown below: ---------- ---------- ---------- |Zeroconf| |Zeroconf| |Zeroconf| |--------| |--------| |--------| |Ethernet| |802.11DS| | IrDA | ---------- ---------- ---------- This gives customers a reasonable expectation that if they buy two "Zeroconf/802.11DS" devices, then they won't need to buy *anything* else to make them communicate. 4. "...not physically separated beyond the reasonable operating range..." Zeroconf IP does not guarantee that a Zeroconf device will be able to communicate with *every* other Zeroconf device in the world, including the ones currently on the far side of the planet. Communication beyond the range of the link-layer technology requires some kind of external infrastructure to forward those packets, and zeroconf does not address that case. ----------------------------------------------- Comments please. Ross is right that until we can agree on what zeroconf means, it is hard to have meaningful discussions about how to achieve it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Thu Aug 17 18:47:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05901 for ; Thu, 17 Aug 2000 18:47:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 828795DDF4; Thu, 17 Aug 2000 18:46:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 722EB5DDAD; Thu, 17 Aug 2000 18:46:52 -0400 (EDT) Received: from ananke.eastgw.xerox.com (ananke.xerox.com [208.140.33.24]) by segue.merit.edu (Postfix) with ESMTP id C768F5DE07 for ; Thu, 17 Aug 2000 18:46:50 -0400 (EDT) Received: from PMDF3.CINOPS.XEROX.COM (pmdf3.cinops.xerox.com [13.250.20.177]) by ananke.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id SAA29482 for ; Thu, 17 Aug 2000 18:46:49 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31443) id <01JT34Z2MN2895MNRS@mail.xerox.com> for zeroconf@merit.edu; Thu, 17 Aug 2000 18:46:43 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JT34Z2J4VQ95MNRI@mail.xerox.com> for zeroconf@merit.edu; Thu, 17 Aug 2000 18:46:42 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 18:46:42 -0400 Content-return: allowed Date: Thu, 17 Aug 2000 18:46:42 -0400 From: "Nicolae, Dan" Subject: RE: How to overcome this WG's flailing To: zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A630A@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > Then, and *only then*, we could define "zeroconf" as being "a > *minimal* set > of protocols that support these > examples/situations/scenarios", and work > towards defining what these protocols will be. > > In other words, we should first try to get consensus about > *what* we want > to support, and then get consensus on *how*. ... > > I feel that this discussion gets too abstract sometimes... > Right, everybody's intention is to come up with a definition that completely and clearly covers zeroconf from each possible perspective: the ultimate. Well, I doubt that's possible. We must lower the expectations. Although ignored so far, I am gonna make a final and shameless attempt to point you to the definition I proposed a while ago: *********************************************************** A protocol is selfconfig if its main functionality, possibly reduced or less efficient, is possible when no explicit administrative configuration is available. *********************************************************** I think it may be useful not necessarily as is, but as a different approach example. I'll spare you the pain to read the associated rationale I sent. It is archived at http://www.merit.edu/mail.archives/zeroconf/msg00722.html. The other thing I thought of was scoping/prioritizing to linklocal goals (http://www.merit.edu/mail.archives/zeroconf/msg00738.html). The AutoIP and mDNS specs do that anyway. Still waiting for comments, even destructive. Thanks, /dan From owner-zeroconf@merit.edu Thu Aug 17 19:52:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06485 for ; Thu, 17 Aug 2000 19:52:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 30C985DDF7; Thu, 17 Aug 2000 19:52:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 169D75DDAD; Thu, 17 Aug 2000 19:52:15 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id 126E05DD95 for ; Thu, 17 Aug 2000 19:52:14 -0400 (EDT) Received: from SERVER.PacBell.net ([63.199.7.253]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FZG00I3PLY2E9@mta5.snfc21.pbi.net> for ZeroConf@Merit.edu; Thu, 17 Aug 2000 16:15:39 -0700 (PDT) Date: Thu, 17 Aug 2000 16:15:52 -0700 From: Peter Johansson Subject: Re: comments on requirements draft 04 In-reply-to: <200008172220.PAA06777@scv3.apple.com> X-Sender: Celeborn@PacBell.net To: Zero Configuration Message-id: <4.3.2.7.2.20000817160510.00be7270@PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 03:23 PM 8/17/00, Stuart Cheshire wrote: >"A zeroconf protocol is able to operate correctly in the absence of either >user configuration or external infrastructure services (e.g. conventional >DHCP or DNS servers)." With all due respect to what is a cleaner, more elegant definition than many advanced thus far, I think it still misses the point made by Ross Finlayson. ANY definition, at the moment, would miss the point. It is hard enough to craft a succinct definition when one knows what is to be said. This working group does not yet know what it wishes to say. 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. If a third pile emerges, examples for which there are no clear consensus, its simple existence may help the working group. I have the impression that the various charter definitions put forth thus far are being pushed and pulled by various individuals wishes to include or exclude examples from ZeroConf. It's a lot easier to see what's under discussion if you stick to the immediate subject matter (the examples) and not their abstraction (the definition). I think Marshall Eubank's contribution of two examples is a step in the right direction. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Thu Aug 17 21:17:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07463 for ; Thu, 17 Aug 2000 21:17:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7FBD5DDAD; Thu, 17 Aug 2000 21:17:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A49865DE0A; Thu, 17 Aug 2000 21:17:49 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 3B14E5DDAD for ; Thu, 17 Aug 2000 21:17:48 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id SAA14402 for ; Thu, 17 Aug 2000 18:17:47 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 17 Aug 2000 18:17:47 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id SAA09650 for ; Thu, 17 Aug 2000 18:17:47 -0700 (PDT) Message-Id: <200008180117.SAA09650@scv1.apple.com> Subject: Re: comments on requirements draft 04 Date: Thu, 17 Aug 2000 18:19:58 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zero Configuration" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >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. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Thu Aug 17 21:33:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08161 for ; Thu, 17 Aug 2000 21:33:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C1FC5DD9E; Thu, 17 Aug 2000 21:32:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3835B5DE0D; Thu, 17 Aug 2000 21:32:22 -0400 (EDT) Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by segue.merit.edu (Postfix) with ESMTP id C4B9A5DD9E for ; Thu, 17 Aug 2000 21:32:20 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id SAA00320 for ; Thu, 17 Aug 2000 18:32:18 -0700 (PDT) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 18 Aug 2000 01:32:17 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 18:32:16 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F2B97@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: zeroconf@merit.edu Subject: RE: How to overcome this WG's flailing Date: Thu, 17 Aug 2000 18:32:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Ross, Only our arms are flailing. ;-) I think your suggestion would cause all of our limbs to flail. ;-) I think we should keep flailing along our current path a little longer. The idea of ZC to mean no "user" configuration was mostly an attempt to flesh out the problems with past definitions. I can certainly live with a definition of zc that does not only apply to "user" configuration if that definition is crisp and can be applied to real problems we are trying to solve. I think now, as group, we agree on a common set of problems with the version 3 and 4 definitions of zc and non-zc protocols. Here's an alternative idea to version 3 & 4. Stop trying to define what a zc and a non-zc protocol is and isn't (I think someone already suggested this but I couldn't see how to apply the idea before). Instead we should simply say that we are working on protocols with the following behavior: protocols may use configuration when it's available yet remain or become operational when configuration is not available. Configuration can be defined as user configuration, DHCP/DNS/MADCAP servers, configured routers, and many other things. It is very easy to apply this statement to link-local addressing->DHCP, mDNS->DNS, and ???->MADCAP; it neatly encompasses all the messy transitions. It also easily applies to the "strangers on a train" scenario. Stuart's definition: A zeroconf protocol is able to operate correctly in the absence of either user configuration or external infrastructure services (e.g. conventional DHCP or DNS servers). is also close to this idea if "either user configuration or external infrastructure services" is replaced with the word "configuration", then configuration is defined by example as above. The difference in the two statements is the "may use configuration when it's available" clause. -myron From owner-zeroconf@merit.edu Thu Aug 17 22:56:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10152 for ; Thu, 17 Aug 2000 22:56:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 374C05DDC1; Thu, 17 Aug 2000 22:56:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 258745DDE9; Thu, 17 Aug 2000 22:56:28 -0400 (EDT) Received: from lysithea.eastgw.xerox.com (lysithea.xerox.com [208.140.33.22]) by segue.merit.edu (Postfix) with ESMTP id 3965E5DDC1 for ; Thu, 17 Aug 2000 22:56:26 -0400 (EDT) Received: from PMDF4.CINOPS.XEROX.COM (pmdf4.cinops.xerox.com [13.250.20.178]) by lysithea.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id WAA21832 for ; Thu, 17 Aug 2000 22:56:24 -0400 (EDT) Received: from CONVERSION-DAEMON by mail.xerox.com (PMDF V5.2-32 #31444) id <01JT3DOCFZU8934RTB@mail.xerox.com> for zeroconf@merit.edu; Thu, 17 Aug 2000 22:56:09 EST Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mail.xerox.com (PMDF V5.2-32 #31443) with ESMTP id <01JT3DOCBAFO95MNRI@mail.xerox.com>; Thu, 17 Aug 2000 22:56:09 -0500 (EST) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2650.21) id ; Thu, 17 Aug 2000 22:56:08 -0400 Content-return: allowed Date: Thu, 17 Aug 2000 22:56:07 -0400 From: "Nicolae, Dan" Subject: RE: How to overcome this WG's flailing To: "'Hattig, Myron'" , zeroconf@merit.edu Message-id: <3654E69400ADD211A3A400805FA7CE24022A630E@USA0111MS2> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT > > Here's an alternative idea to version 3 & 4. Stop trying to > define what a zc > and a non-zc protocol is and isn't (I think someone already > suggested this > but I couldn't see how to apply the idea before). Instead we > should simply > say that we are working on protocols with the following > behavior: protocols > may use configuration when it's available yet remain or > become operational > when configuration is not available. > Right, you can't simplify and deal with just two cases: zeroconf and non-zeroconf. There are no two opposed (one is the negation of the other) protocols that MAY coexist. The *reality* is *a single protocol* that intelligently transitions between a minimum a maximum *functionality* based on how much configuration is available at a certain time. In between the maximum and the minimum there are discrete intermediate levels. The transitions are multiple and the (only) rule is to always make *the best* use of the available configuration to function on *the highest* functionality level. The minimum is the two host linked with crossover cable. The maximum is a fully administratively configured infrastructure. The protocol is intelligent. It is able to perform *learning*. Learning does not preclude a priori configuration (initialization). Neural nets are intelligent and still depend on initialization as a starting point. Even the ultimate *real* intelligent machines, the humans, are born with hard-coded initialization (genetic code and a set of instincts). User configuration is not an argument either, as is not the existence of extra boxes (servers, agents, routers), nor the burn-in defaults. Regardless of where the configuration comes from, the protocol finds it and uses it with a maximum efficiency. Goal: the user intelligence is compensated and transmuted in protocol's intelligence. This is the ultimate zeroconf definition. Because zeroconf is an utopia and we deal with the real world, settle for a selfconfig definition because that's all we're gonna get. Zeroconf is untouchable unless you're God. /dan P.S. With the risk of becoming a persona-non-grata, I am still curious if the latest discussions are not, at least roughly, touched in the proposal at http://www.merit.edu/mail.archives/zeroconf/msg00722.html From owner-zeroconf@merit.edu Sat Aug 19 06:39:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29644 for ; Sat, 19 Aug 2000 06:39:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B472B5DD91; Sat, 19 Aug 2000 06:38:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E7E85DD9A; Sat, 19 Aug 2000 06:38:59 -0400 (EDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by segue.merit.edu (Postfix) with SMTP id 15B655DD91 for ; Sat, 19 Aug 2000 06:38:56 -0400 (EDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id KA20546; Sat, 19 Aug 2000 20:38:52 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: zeroconf@merit.edu Subject: Re: How to overcome this WG's flailing In-Reply-To: Your message of "Thu, 17 Aug 2000 15:21:00 MST." <200008172218.PAA06104@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Aug 2000 20:38:52 +1000 Message-Id: <21431.966681532@mundamutti.cs.mu.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 17 Aug 2000 15:21:00 -0700 From: Stuart Cheshire Message-ID: <200008172218.PAA06104@scv3.apple.com> | The charter of this WG is | to make IP usable when there is no external infrastructure. The charter | specifically limits zeroconf to internetworks with at most ONE router. | The Internet, last time I checked, had more than one router. If that is to be the limit of what this WG is to achieve (as opposed to just being a part of the result), then you might as well close it down now and all go away. In the not too distant future (quite possibly before this WG has decided on what it is supposed to be achieving at the rate it is going) the internet, and access to it, is likely to be more or less ubiquitous. The "strangers on the train" won't just be talking to each other, the train will be providing internet access. It has to for the whole thing to be worthwhile. It might be reasonable for members of this group to happening to be travelling by the same train (or plane) and want to be able to communicate with each other - though only one train/plane in a hundred is likely to have such a group aboard. More likely, on an average train/plane you may find a few people willing to join some multi-user game, and so be content to be connected to each other, and no-one else. But all the other travellers are going to want to access the stock prices, news reports, their e-mail (messages), internet radio, ... For that, they're going to have to connect themselves to the internet, and the tains and planes, will start providing that connectivity sometime not too far away. Similarly houses without internet connectivity will become about as common as houses without phones. So, if you're planning to restrict yourselves to the fringes, and not solve any useful problems, I see no point in this WG existing. It needs to be able to handle zeroconf hosts connecting to a (probably configured by someone else) network, as well as the less likely case of an ad-hoc network forming that is connected to nowhere. kre ps: if appletalk is the model, then the "zero" in zeroconf needs to be treated quite liberally - a truly zero configured appletalk network is useful for almost nothing at all (sure, it exists, but without someone configuring some services on it, there's not a lot you're able to do). From owner-zeroconf@merit.edu Sat Aug 19 09:26:49 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00938 for ; Sat, 19 Aug 2000 09:26:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01D715DDAC; Sat, 19 Aug 2000 09:26:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DBE8B5DDA1; Sat, 19 Aug 2000 09:26:39 -0400 (EDT) Received: from sol.extremenetworks.com (sol.extremenetworks.com [216.52.8.2]) by segue.merit.edu (Postfix) with ESMTP id AB4A85DD9A for ; Sat, 19 Aug 2000 09:26:38 -0400 (EDT) Received: from mosquito.extremenetworks.com ([10.0.8.137]) by sol.extremenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id RDSMK94R; Sat, 19 Aug 2000 06:26:17 -0700 Message-Id: <4.3.2.7.2.20000819091706.00ae6100@sol.extremenetworks.com> X-Sender: rja@sol.extremenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 19 Aug 2000 09:22:10 -0400 To: Robert Elz From: RJ Atkinson Subject: Re: How to overcome this WG's flailing Cc: zeroconf@merit.edu In-Reply-To: <21431.966681532@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 06:38 19/08/00, Robert Elz wrote: >If that is to be the limit of what this WG is to achieve (as opposed to >just being a part of the result), then you might as well close it down now >and all go away. Disagree. >The "strangers on the train" won't just be talking to each other, the train >will be providing internet access. It has to for the whole thing to be >worthwhile. It might be reasonable for members of this group to happening >to be travelling by the same train (or plane) and want to be able to >communicate with each other - though only one train/plane in a hundred >is likely to have such a group aboard. More likely, on an average train/plane >you may find a few people willing to join some multi-user game, and so be >content to be connected to each other, and no-one else. But all the other >travellers are going to want to access the stock prices, news reports, >their e-mail (messages), internet radio, ... ...and existing methods (e.g. DHCP, Router Discovery, Service Location) already address that scenario. If there are unresolved issues, then that would be fine work, but possibly in a different WG. >So, if you're planning to restrict yourselves to the fringes, and not solve >any useful problems, I see no point in this WG existing. It needs to be >able to handle zeroconf hosts connecting to a (probably configured by someone else) network, as well as the less likely case of an ad-hoc >network forming that is connected to nowhere. Disagree. Other techniques (e.g. DHCP, Router Discovery, Service Location) work fine for a network where someone has done some configuration. To the extent folks think there are open issues with the scenarios that kre has outlined, maybe there needs to be a separate WG to look into those issues. Ran rja@inet.org From owner-zeroconf@merit.edu Sat Aug 19 10:22:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01347 for ; Sat, 19 Aug 2000 10:22:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5D035DD97; Sat, 19 Aug 2000 10:22:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B4FC45DD96; Sat, 19 Aug 2000 10:22:34 -0400 (EDT) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 727E95DD8F for ; Sat, 19 Aug 2000 10:22:33 -0400 (EDT) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id HAA28794; Sat, 19 Aug 2000 07:19:52 -0700 (PDT) Received: from e1kj2.internaut.com by internaut.com (NX5.67e/NeXT-3.0) id AA00876; Sat, 19 Aug 00 05:55:41 -0800 From: "Bernard Aboba" To: "Robert Elz" , Subject: RE: How to overcome flailing (and pailing) Date: Sat, 19 Aug 2000 06:11:47 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <21431.966681532@mundamutti.cs.mu.OZ.AU> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >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. You're right that re-inventing DHCP isn't necessary. However, I wouldn't conclude from that there is no work left to be done. Just because protocols exist that can be re-used (e.g. DHCP, spanning tree) does not mean that a profile exists on how to use those protocols in a way that achieves our objectives. It is also sometimes useful to have a framework document that can explain how a number of disparate pieces work together coherently. I would suggest that it might be appropriate for ZEROCONF to work on that framework document. This might enable the various WGs handling elements of the problem to understand better how ther work inter-relates. In general, one of the reasons for having a working group is that it creates a community of people interested in solving a problem. To some extent the current approach risks segmenting the problem in a way that this energy cannot be fully harnessed. >So, if you're planning to restrict yourselves to the fringes, and not solve >any useful problems, I see no point in this WG existing. It needs to be >able to handle zeroconf hosts connecting to a (probably configured by someone >else) network, as well as the less likely case of an ad-hoc network forming >that is connected to nowhere. When listening to presentations about adhoc networks, I often find myself wondering whether the scenarios really make sense. 25 people in a conference room only wanting to talk to each other and never to connect to the Internet to read mail or browse the web? Nowadays when I'm in meetings, it seems like people spend most of their time reading email or web browsing, so much so that I sometimes wish they would stop. My sense of what motivates so much interest in ZEROCONF isn't so much the ability to reinvent the functionality of AppleTalk and NetBEUI (with all its warts) but rather the ability to achieve the ease of use of those protocols AND also gain all the advantages of Internet connectivity. In terms of the set of work that needs to be done to enable Internet-connected scenarios, here is what I think needs to be done: 1. I would suggest that the behavior of mini-DHCP/DNS proxies needs to be defined. That might be done elsewhere (like DHC WG or DNSEXT) but I think it needs to happen. 2. There is a need for work on security in adhoc and home networks. 3. There may be work needed with respect to adhoc networking and implementation of bridging protocols on hosts. From owner-zeroconf@merit.edu Sun Aug 20 22:48:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14159 for ; Sun, 20 Aug 2000 22:48:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3D7045DDCF; Sun, 20 Aug 2000 22:46:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C11F5DDCD; Sun, 20 Aug 2000 22:46:58 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id DE8D15DDC6 for ; Sun, 20 Aug 2000 22:46:56 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA21974 for ; Sun, 20 Aug 2000 19:46:56 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [217.1.10.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id TAA18628 for ; Sun, 20 Aug 2000 19:46:54 -0700 (MST)] Received: from motorola.com (swerve.arc.corp.mot.com [217.1.10.63]) by homer.arc.corp.mot.com (8.10.2/8.10.2) with ESMTP id e7L2kmD04832; Mon, 21 Aug 2000 12:46:48 +1000 (EST) Message-ID: <39A09817.457F87A7@motorola.com> Date: Mon, 21 Aug 2000 12:46:47 +1000 From: Aidan Williams X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Richard Johnson Cc: zeroconf@merit.edu, Aidan Williams Subject: Re: comments on requirements draft 04 References: <4148FEAAD879D311AC5700A0C969E8904F2B5E@orsmsx35.jf.intel.com> <14736.38790.807404.604625@kitab.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Richard Johnson wrote: > I also wonder if we should add that the user should be given the > option of configuring a zeroconf address and joining a network before > actually doing so, unless the user has already specified in some way > that the host should automatically configure zeroconf addresses and > join all networks. I'm worried about having one's laptop simply > automatically joining all Wavelan networks in range, whether or not > the user really wants this. Of course, printers purchased for home > use would want to automatically join the network when plugged in. > It's a trade off. Maybe it's a security issue about which we should > be silent? > I believe that users need mechanisms which will allow them to simply and securely create federations of devices. There are several situations where this is important: - "drive by" joining of networks (as you describe), - wireless networks with overlapping coverage, - any shared network where you only want to exchange traffic with a subset of hosts on the network. In these scenarios, you can view hosts as "borrowing" the network medium.. Since there might be other people on that medium too, they need to be able to do it safely. The "standard" solution currently is to apply L2 encryption. The implication of doing this is that the the user is required to configure something (like a key) before zeroconf protocols can begin to be used. The techniques I have come across for doing this are cumbersome. At this stage, I think security in zeroconf networks needs to be done above layer-2. Comments welcome. It seems to me that whilst allowing the user to turn off zeroconf networking as a security measure is a good thing, it is too coarse grained for many situations. It is also something that must be configured before the user can get anywhere with zeroconf protocols. regards aidan ____ :wq! From owner-zeroconf@merit.edu Mon Aug 21 23:26:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14727 for ; Mon, 21 Aug 2000 23:26:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1FD75DD8F; Mon, 21 Aug 2000 23:26:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DE3475DDB7; Mon, 21 Aug 2000 23:26:01 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 9818E5DD8F for ; Mon, 21 Aug 2000 23:26:00 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id UAA13585 for ; Mon, 21 Aug 2000 20:25:54 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Mon, 21 Aug 2000 20:25:53 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id UAA21793 for ; Mon, 21 Aug 2000 20:25:52 -0700 (PDT) Message-Id: <200008220325.UAA21793@scv1.apple.com> Subject: ZEROCONF Minutes Date: Mon, 21 Aug 2000 20:28:08 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk The following minutes have been submitted to minutes@ietf.org: ------------------------------------------------------------ Minutes for ZEROCONF Meeting 1:00pm - 2:00pm, Tuesday, 1st August 2000 48th IETF Meeting, Pittsburgh, Pennsylvania, 30th July - 4th August 2000 Thanks to Steve Hanna for taking notes for these minutes. Agenda: Charter Discussion (30 minutes) Requirements Document Discussion (30 minutes) ------------------------------------------------------------ Charter Discussion ------------------ We have almost completed the primary item of our existing charter (developing a requirements document). This document identifies areas where new work is needed. Should we expand the Zeroconf charter to include the portions of this new work that are not already covered by other working groups? Erik Guttman listed the needed protocols, noting which ones are being addressed elsewhere and which are not: * Service Discovery SLPv2 & DNS SRV are both Proposed Standards. No need for new service discovery protocols. Any comments? Bill Woodcock and one other called out in agreement. * Interface Configuration IPv6 stateless addrconf is already a Draft Standard from IPNGWG. No new protocol work is needed here. IPv4 linklocal address assignment has two drafts but no WG. The DHC working group has stated that it has no interest in pursuing work on this. Should IPv4 linklocal address assignment become an official work item of Zeroconf? Side discussion: IPv4 linklocal address assignment bears on the question of transitions vs. peaceful coexistence. The current charter of Zeroconf assumes that Zeroconf protocols are harmful to large configured networks, and must automatically shut down on such networks. However, the true requirement that the charter should have stated is that Zeroconf protocols must do no harm on large configured networks. Whether that requires them to shut down depends on whether they cause harm to large configured networks if they do not. Given that no transition can be instantaneous, there will always be some period of coexistence, so it is desirable that Zeroconf protocols should not cause harm to large networks in this case. Consequently, if Zeroconf protocols can be created that do not cause harm to large networks, then there is no reason to require them to automatically shut down on such networks. Comment from the floor: Didn't we agree in Adelaide that there was broad consensus that IPv4 LL should coexist with configured addresses? Why are we still discussing this? Erik Guttman then asked anyone who disagreed to come to a microphone to present an opposing argument, and when no one was forthcoming, declared rough consensus on the issue of peaceful coexistence. Question from the floor: Should we update Host Requirements? Erik Guttman: Host Requirements was not written prescriptively, in advance; it was written descriptively, after we had gained considerable experience. We cannot even consider updating Host Requirements until after we have gained a similar level of operational experience with Zeroconf protocols. Return to original question: Should IPv4 linklocal address assignment become an official work item of Zeroconf? No one spoke out to oppose this. Comment from the floor: IPv4 LL draft should be a standard-track document, not Informational. No one spoke out to oppose this. * Name Resolution This is being considered outside Zeroconf, by IPv6 (hostinfo request/reply proposal) and DNSEXT (mDNS proposal). * Multicast Address Allocation Erik Guttman: Address Allocation Protocol, designed in MALLOC WG, is designed for large configured networks. However, it might be feasible to Zeroconf to write a profile document defining how AAP is used in Zeroconf networks. Dave Thaler has published a draft on these lines (draft-thaler-zeroconf-multicast-01.txt). Comment from the floor: AAP is a peer-to-peer protocol anyway. Erik Guttman: AAP does all we need and more. We just need to identify the "more" and remove it. * Security Assertion from Erik Guttman: All Zeroconf security requirements can be met by stating that a host needs to be able to determine whether packets it receives are from a trusted peer. All we need to do is say that there should be a way for packets to be authenticated. This protects claim-and-defend protocols against DOS attacks. This protects against rogue hosts masquerading as infrastructure services like DHCP servers. We've already agreed that securing ARP is out-of-scope. DNS, DHCP and SLP already have application-level authentication methods. Is that sufficient? Zeroconf does not claim to address confidentiality of user data transmitted over the wire. With configured or zeroconf networking, ensuring appropriate confidentiality protection remains the responsibility of higher-layer protocols. Open question is how to make all this application-level authentication easy to do. Perhaps we could consider a future "Securing the LAN" document explaining how to make security set-up easy without requiring 'sneakernet', but we should clearly and simply state that this work is NOT in the Zeroconf charter. Question from the floor: Will you identify another working group that should have responsibility for security? Erik Guttman: I have identified elements of it, namely, SLP security is the responsibility of the SLP WG. DNS security is the responsibility of the DNS WG. DHCP security is the responsibility of the DHCP WG. What I am proposing here is that we find those people who are interested, and take them off to consult with the security directorate and security advisors, and possibly charter a new working group, but we should explicitly state that we are not going to do that work here. Question from the floor. Isn't this the same as the work of the AAA working group? General Consensus: No. Dave Thaler: Requirements document should not solve the security problems, but should state security requirements that need to be addressed in any proposed protocol. Erik Guttman: Agreed. The requirement for Zeroconf networking is not that it solve all security problems. The requirement for Zeroconf networking is that it not make networking less secure than configured networks are today. Discussion from the floor: If light switches and light bulbs and other appliances start using networking, then their security requirements are the same regardless of whether they are using configured networking or zeroconf networking. Erik presented a new list of charter goals: 9/00 Submit requirements draft for Informational 12/00 Submit IPv4 Host Autoconfiguration draft for Proposed Standard 12/00 Submit Zeroconf AAP Profile draft for Proposed Standard 3/01 Submit Zeroconf Protocol Profile draft for Informational The Zeroconf Protocol Profile would list protocols needed for a zero configuration network, pointing at protocol specifications. Since this document would depend on all the protocol specs (including several that are in other working groups), it might have to wait at the IESG for those documents. Question from the floor: Will the profile have to wait for the "Securing the LAN" document? Answer: No. The requirement for Zeroconf networking is that it not make networking less secure than configured networks are today. The "Securing the LAN" document is a step beyond that. Dave Thaler says authors of zeroconf protocol drafts need guidelines for writing their Security Considerations sections. Erik says that will go in the Requirements draft. Stuart Cheshire: In addition, some parts of the charter need some minor rewording. For example, host configuration should be called interface configuration, since "host configuration" is already overloaded with other meanings, such as configuring the address of a DNS server, which may not apply in the Zeroconf case. These minor changes will be discussed on the mailing list. The group generally agreed to the list of work items above. ------------------------------------------------------------ Review of Draft 04 ------------------ Erik listed several open issues pertaining to the requirements document: * "MUST Transition" requirement Erik Guttman: Current draft says "MUST transition to configured operation in the presence of a DHCP server" when a DHCP server is detected. An alternative, which we've heard support for here, is to allow peaceful coexistence, where a host maintains its self-configured link-local address, and any active TCP connections using it, in addition to obtaining an additional address from the DHCP server. Note that if we allow two IPv4 addresses like this, then we've created a scoped address architecture like IPv6. Bill Woodcock: Lets decide this now. Erik Guttman asked for people to hum in support of "MAY retain zeroconfigured operation", and then in support of "MUST transition". Broad support for being able to retain zeroconfigured operation; one person (Bill Manning) supported "MUST transition". Unfortunately, some people were not clear about what was meant by "MAY retain" and "MUST transition": Comment from the floor: When a small network becomes connected to a larger network, do we allow a hybrid state? Stuart Cheshire: The agreement we thought we just reached is that devices should be allowed to implement the hybrid state. We're not mandating that devices MUST support a hybrid state and we're not mandating that devices MUST NOT support a hybrid state. We're saying that implementers are free to implement the hybrid state if they want to. Comment from the floor: I supported "ability to retain zeroconfigured operation" because I thought it meant that devices must stay in zeroconf mode and MUST NOT support a hybrid state where they also get an address from the DHCP server as well. Erik Guttman: So, based on what was just said, you would have hummed into the silence then? Answer: Yes. Thomas Narten: The question is whether zeroconf and non-zeroconf protocols can exist in the same network. Erik Guttman: The current spec says you MUST detect the presence of a DHCP server, and you MUST transition, and you have no choice. This allowed us to simplify a lot of issues by saying that a host is either zeroconf, or not zeroconf, and never both. However, many strong arguments have been made showing that this simple model is inadequate. Bill Simpson: There are many useful potential applications of IP, such as home automation systems, and I don't want us to say that you're not allowed to make an IP-speaking light bulbs unless it also includes a DHCP client. Comment from the floor: Saying that zeroconf protocols MUST NOT coexist with configured protocols simplifies the protocols. Erik Guttman: It's not that simple. When a DHCP server comes up, there is necessarily some period of time before a zeroconf host detects the DHCP server, so there is always some period of overlap, so the protocols will have to accommodate that case anyway. Even if we require a transition, we still have to consider the times when the transition has not fully occurred. All we're doing by saying "may coexist" is that we're taking off the duration requirement on the transition, and allowing that period of overlap to last indefinitely. It just has to be safe. Bill Woodcock: Remember that Zeroconf devices can't use lack of transition as a substitute for security. Even for a device that doesn't transition to configured operation, designers need to be aware that other hosts on the same network may transition and may be accessible to hosts outside the local network. Bill Manning: Saying that devices MUST transition to configured operation is a smaller set of work. Comment from the floor: This WG shouldn't be working on IPv4 problems at all when IPv6 has already solved all these problems. Stuart Cheshire: The primary work of this WG is not IPv4 address assignment. The primary work of this WG is to come to agreement on the requirements for zeroconf networking. The question in front of us right now is whether our requirements document should state that you MUST give up auto-configured operation when configuration information comes into existence on the network. In the context of IPv6 that's saying that you're not allowed to use IPv6 link-local addresses if you're seeing IPv6 router advertisements on the network. The question in front of us right now is whether we think that is a sensible requirement. Erik Guttman again asked for people to hum in support of allowing hosts to continue using zeroconf protocols even in the presence of configured alternatives, or not. Again, the outcome was strongly on the side of allowing hosts to choose. Erik declared rough consensus on this point and asked anyone who still disagreed to present arguments on the mailing list. * "Periodic actions" Requirement Erik Guttman: Several sections of draft-04 include text that says zeroconf protocols MUST require hosts to perform periodic actions. The reason why it states that, is that we have a requirement in many cases to detect state changes, and it so happens that some of the mechanisms that exist today use periodic messages to achieve that state change detection in a timely way. It turns out that what we really want to do is to detect those state changes in a timely way. We have no desire to send out periodic messages for their own sake. Unnecessary periodic messages have been the death of many protocols and they are certainly not a requirement, or even a desirable feature, of a protocol. * Host Name Resolution Erik Guttman: Right now in the document we talk about Domain Name Resolution. We propose that we change this to Host Name Resolution. One reason for this is that the IPv6 hostinfo protocol requests names that are the names of hosts, but not necessarily Domain Names in the Domain Name System. Can we simplify the requirements document by talking about Host Names instead of Domain Names? Stuart Cheshire: The requirements document should focus on the requirements, not the artefacts of the implementation, and the requirement is for users to be able to access hosts by name. Twenty years ago, this was achieved by having a big "/etc/hosts" file. When that became unmanageable the Domain Name System took over, but that's just one way of implementing name resolution. The requirement we want for zeroconf is looking up host names. Because we made the mistake of assuming that we necessarily achieve this using DNS, the current requirements draft is cluttered up with language about domains and subdomains and delegation, which are implementation details of a particular name system, not zeroconf requirements in their own right. The right solution for zeroconf networking may very well turn out to be some variant of DNS running over IP multicast, but the requirements document should not mandate that. The requirement is the ability to access hosts by name. * Interface Configuration Erik Guttman: There is text in the current requirements document that describes the use of netmasks and default routers as pieces of required host configuration. There is a suggestion that the real requirement being expressed is routing table configuration, and describing it as such would be a more general and more correct way of describing how IP hosts actually operate. Also, a default route is *not* required for a zeroconf host to communicate with a peer zeroconf host. * Configuration Servers (DHCP) Erik Guttman: If you deploy a configuration server on your network, and that configuration server then goes and adds configuration to your hosts, then you're no longer in zeroconf any more. If I turn on a DHCP server, then the hosts that use configuration information from that DHCP server are configured. They're not using a zero configuration protocol. Now it could be that that DHCP server is itself automatically configured, but that's a totally different thing. Right now the requirements document is ambiguous about this. At one point it even states that DHCP may be a zero configuration protocol. Erik asked for comments. No disagreements were voiced. * Security Erik Guttman: Proposal for discussion on the mailing list: Zeroconf security requirements can all be met by the single requirement that hosts should be able to verify that messages they receive are from trusted peers. * Final closing comment from the floor: The requirements document should indicate what the assumptions are for zero configuration networking. Is a MAC address required, for example? Erik agreed that this was a good point. ------------------------------------------------------------ Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-zeroconf@merit.edu Fri Aug 25 15:51:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28085 for ; Fri, 25 Aug 2000 15:51:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 02F9E5DE25; Fri, 25 Aug 2000 15:49:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E29085DE63; Fri, 25 Aug 2000 15:49:44 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 3A1A65DE25 for ; Fri, 25 Aug 2000 15:49:43 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id MAA06781; Fri, 25 Aug 2000 12:49:44 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Fri, 25 Aug 2000 12:49:31 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE86@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'zeroconf@merit.edu'" Cc: "'akinlar@research.panasonic.com'" , "McDonald, Ira" Subject: Use EUI-64 in ZRIP? Date: Fri, 25 Aug 2000 12:49:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Copies: Cuneyt Akinlar Ira McDonald Hi, Friday (25 August 2000) A comment on ZRIP (15 August). On page 5, you suggest creating a UID by contatenating an Ethernet MAC address (6 octets) with two octets of 0's. The IPv6 Addressing Architecture (RFC 2373, July 1998) requires the use of the normal form EUI-64 for generating IPv6 addresses for interfaces with 48-bit IEEE MAC hardware addresses. I would suggest following that lead in your spec. The EUI-64 discussion is in Appendix A 'Creating EUI-64 based Interface Identifiers' of RFC 2373. The normative IEEE reference is: [EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. Good spec - it seems a straightforward extension of RIPv2 for Zeroconf. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc From owner-zeroconf@merit.edu Fri Aug 25 16:19:46 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28800 for ; Fri, 25 Aug 2000 16:19:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62E1B5DDB5; Fri, 25 Aug 2000 16:19:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4CCCE5DDA6; Fri, 25 Aug 2000 16:19:34 -0400 (EDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id 34CFE5DD9A for ; Fri, 25 Aug 2000 16:19:33 -0400 (EDT) Received: from SERVER.PacBell.net ([63.199.7.253]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0FZV00IW864P2X@mta6.snfc21.pbi.net> for ZeroConf@Merit.edu; Fri, 25 Aug 2000 12:58:01 -0700 (PDT) Date: Fri, 25 Aug 2000 12:53:27 -0700 From: Peter Johansson Subject: Re: Use EUI-64 in ZRIP? X-Sender: Celeborn@PacBell.net To: Zero Configuration Message-id: <4.3.2.7.2.20000825125233.00beeed0@PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:49 PM 8/25/00, McDonald, Ira wrote: >[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) >Registration Authority", >http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. Could you provide a working URL, please? Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Sat Aug 26 10:38:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22179 for ; Sat, 26 Aug 2000 10:38:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85C895DDC6; Sat, 26 Aug 2000 10:38:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6900C5DDC5; Sat, 26 Aug 2000 10:38:19 -0400 (EDT) Received: from ns4.sony.co.jp (ns4.Sony.CO.JP [202.238.80.4]) by segue.merit.edu (Postfix) with ESMTP id 57D455DDB1 for ; Sat, 26 Aug 2000 10:38:18 -0400 (EDT) Received: from mail2.sony.co.jp (gatekeeper7.Sony.CO.JP [202.238.80.21]) by ns4.sony.co.jp (R8) with ESMTP id XAA93919; Sat, 26 Aug 2000 23:38:17 +0900 (JST) From: fujisawa@sm.sony.co.jp Received: from mail2.sony.co.jp (localhost [127.0.0.1]) by mail2.sony.co.jp (R8) with ESMTP id XAA02199; Sat, 26 Aug 2000 23:43:01 +0900 (JST) Received: from smail2.sm.sony.co.jp (smail2.sm.sony.co.jp [43.16.1.128]) by mail2.sony.co.jp (R8) with ESMTP id XAA02195; Sat, 26 Aug 2000 23:43:01 +0900 (JST) Received: from rdmail.sm.sony.co.jp (root@xserver.sm.sony.co.jp [43.16.63.219]) by smail2.sm.sony.co.jp (8.8.8/3.6W) with ESMTP id XAA15936; Sat, 26 Aug 2000 23:38:16 +0900 (JST) Received: from fujiken.sm.sony.co.jp (fujiken.sm.sony.co.jp [43.16.63.177]) by rdmail.sm.sony.co.jp (8.8.8/3.6W-09/08/98) with ESMTP id XAA08401; Sat, 26 Aug 2000 23:36:28 +0900 (JST) Received: from localhost by fujiken.sm.sony.co.jp (8.8.8/6.4J.6/K) id XAA24880; Sat, 26 Aug 2000 23:40:00 +0900 (JST) Message-Id: <200008261440.XAA24880@fujiken.sm.sony.co.jp> To: Peter Johansson Cc: Zero Configuration Subject: Re: Use EUI-64 in ZRIP? In-reply-to: Your message of Fri, 25 Aug 2000 12:53:27 -0700. <4.3.2.7.2.20000825125233.00beeed0@PacBell.net> Date: Sat, 26 Aug 2000 23:40:00 +0900 Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Peter, >>[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) >>Registration Authority", >>http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. > >Could you provide a working URL, please? http://standards.ieee.org/regauth/oui/tutorials/EUI64.html Regards, Kenji Fujisawa From owner-zeroconf@merit.edu Mon Aug 28 12:24:05 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14703 for ; Mon, 28 Aug 2000 12:24:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C69A35DDC1; Mon, 28 Aug 2000 12:23:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AC4915DDCB; Mon, 28 Aug 2000 12:23:47 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7D3655DDC1 for ; Mon, 28 Aug 2000 12:23:46 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08212; Mon, 28 Aug 2000 09:23:42 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id SAA10526; Mon, 28 Aug 2000 18:23:40 +0200 (MET DST) Date: Mon, 28 Aug 2000 18:33:08 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: zeroconf wg actions: mailing list decisions To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, cheshire@apple.com, narten@raleigh.ibm.com, Erik Nordmark Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following items were agreed to both on the mailing list and at the IETF 48 ZEROCONF WG meeting. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Expand the ZEROCONF WG charter with *** *** the following goals: *** *** *** *** - Submit Autoconf IPv4 (to Prop. Std.) *** *** - Submit MC Addr Allocation Protocol *** *** (to Prop. Std.) *** *** *** *********************************************** *********************************************** Yes. There was agreement at WG meeting - no counter argument on list. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** New list of ZEROCONF WG milestones: *** *** *** *** 09/00 Submit Zeroconf Reqts to IESG *** *** (to Informational RFC) *** *** 12/00 Submit Autoconf IPv4 *** *** (to Proposed Standard RFC) *** *** 12/00 Submit MC Addr Allocation *** *** Protocol *** *** (to Proposed Standard RFC) *** *** 03/01 Submit Zeroconf Requirements *** *** (to Informational RFC) *** *** *** *********************************************** *********************************************** Yes. There was agreement at WG meeting - no counter argument on list. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Hosts MAY transition to configured *** *** operation. *** *** *** *** This change will require a new set *** *** of requirements to make sure that *** *** coexistence of zeroconf and non- *** *** zeroconf configuration will neither *** *** interfere with existing IP networks *** *** nor lead to difficulties in the *** *** implementation and interoperability *** *** of IP hosts. *** *** *** *********************************************** *********************************************** Yes. There was agreement at WG meeting - no counter argument on list. *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Change language in the reqts draft *** *** requiring periodic messages to a *** *** requirement to detect and correct *** *** conflicts and state changes in a *** *** timely way. *** *** *** *********************************************** *********************************************** Yes. There was agreement at WG meeting - and after some discussion, agreement on the mailing list. The definition in draft 03 was: A zeroconf protocol requires no user configuration and does not rely on information received from a centralized server. A non-zeroconf protocol requires user configuration or relies on information received from a centralized server. The definition in draft 04 is: A zeroconf protocol requires no user configuration. A non-zeroconf protocol requires user configuration. The definition I propose is: 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.) *********************************************** *********************************************** *** For WG mailing list approval *** *** *** *** Decide on which formulation of the *** *** definition of a zeroconf protocol. *** *** *** *** Choose version 03, 04 or Erik's. *** *** *** *********************************************** *********************************************** The result of much discussion arrived at a consensus very close to 03: A zeroconf protocol is able to operate correctly in the absence of either user configuration or external infrastructure services (e.g. conventional DHCP or DNS servers). It is noted that we need to add text to the document stating that configuration can certainly be used (MAC addresses, IDs, certificates, etc.) if they exist. Zeroconf protocols MUST be able to operate without these IDs, however. ------------------------------------------------------------------------ Please let me know if anyone disagrees with my reading of the mailing list discussion. Erik From owner-zeroconf@merit.edu Mon Aug 28 12:24:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14715 for ; Mon, 28 Aug 2000 12:24:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F5965DDCB; Mon, 28 Aug 2000 12:24:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2364D5DDD9; Mon, 28 Aug 2000 12:24:04 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D3C6C5DDCB for ; Mon, 28 Aug 2000 12:24:01 -0400 (EDT) Received: from efra05-home.Germany.Sun.COM ([129.157.43.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08300; Mon, 28 Aug 2000 09:24:00 -0700 (PDT) Received: from vayne (muc-isdn-8 [129.157.164.108]) by efra05-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v1.9) with SMTP id SAA10548; Mon, 28 Aug 2000 18:23:58 +0200 (MET DST) Date: Mon, 28 Aug 2000 18:25:20 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: new charter document To: zeroconf@merit.edu Cc: erik.guttman@germany.sun.com, cheshire@apple.com Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-LA_F2155733230R-1A-967480406=:627NCE.IlHAFeR" Sender: owner-zeroconf@merit.edu Precedence: bulk ---LA_F2155733230R-1A-967480406=:627NCE.IlHAFeR Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Please find attached a new charter document. This has been discussed at the IETF WG and on the mailing list. Only one change was requested on the list based on the trial text, and this has been incorporated. Please look it over before I submit it to the IESG for approval. Erik ---LA_F2155733230R-1A-967480406=:627NCE.IlHAFeR Content-Type: TEXT/plain; name="zeroconf-charter-00828.txt"; charset=us-ascii Content-Description: default Zero Configuration Working Group (zeroconf) Last Modified 28 Aug 00 Chairs Erik Guttman Stuart Cheshire Area Directors Thomas Narten Erik Nordmark Area Advisor Thomas Narten Mailing Lists General Discussion: zeroconf@merit.edu To Subscribe: subscribe zeroconf your_email_address Archive: http://www.merit.edu/mail.archives/zeroconf/ Description of Working Group: The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train. ZEROCONF requirements will make networking as easy as possible, but no easier. In some cases other considerations may dominate ease of use. For example, network security requires some configuration which may not be as easy as the unacceptable alternative of 'no security.' Networks where ZEROCONF protocols apply can include (but are not limited to) environments where no DHCP, MADCAP or DNS servers are present. This working group will address both IPv4 and IPv6. Many functions which are not of fundamental importance to host and application configuration are outside the scope of the working group. This is not because there are no other problems to solve for networking in an environment without preexisting configuration. This working group will focus on an achievable subset of these problems. The ZEROCONF WG will precisely define the requirements for each of the following functions: * Interface Configuration (IP address, network prefix, gateway router) * Name-to-Address Translation * Service Discovery * Automatic allocation of Multicast Addresses * Sufficient security features to prevent networks from being any less secure than networks which do not use ZEROCONF protocols The working group will define the requirements to provide these functions on two distinct network topologies: 1. A single network segment, where all hosts are reachable by link-layer broadcast or multicast messages. 2. A set of network segments, (on different IP subnetworks) interconnected by a single router. Automatic configuration of an arbitrary topology of routers and subnets is out of the scope of the ZEROCONF WG charter. The working group will also define how such a network may automatically transition from 'configured' to 'unconfigured' behavior, as well as from 'unconfigured' to 'configured'. That is, the same hosts must be able to function on networks with no configuration as well as be capable of direct IP connectivity to the global Internet, including DNS entries supplied through standard DNS services. It is also possible that both modes (ZEROCONF and administered) may coexist on the same network; the modes may not be exclusive of each other. When ZEROCONF networks or hosts which are configured using ZEROCONF protocols are connected to the big 'I' internet, they should not automatically become vulnerable to new security threats. This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. The second, which follows the first, will detail a 'profile' specifying which standards specifically satisfy ZEROCONF requirements. The WG will also produce protocol specifications for Automatic Address Configuration for IPv4 and a Multicast Address Allocation Protocol for IPv4 and IPv6. Goals and Milestones: Sep 00 Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. Dec 00 Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. Dec 00 Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC. Mar 01 Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking. ---LA_F2155733230R-1A-967480406=:627NCE.IlHAFeR-- From owner-zeroconf@merit.edu Mon Aug 28 12:47:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15399 for ; Mon, 28 Aug 2000 12:47:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 434A25DDC1; Mon, 28 Aug 2000 12:46:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2D3A55DDDC; Mon, 28 Aug 2000 12:46:37 -0400 (EDT) Received: from slafw.enet.sharplabs.com (gatekeeper.sharplabs.com [216.65.151.101]) by segue.merit.edu (Postfix) with ESMTP id 6DB505DDC1 for ; Mon, 28 Aug 2000 12:46:35 -0400 (EDT) Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02 [172.29.225.253]) by slafw.enet.sharplabs.com (8.9.2/8.9.2) with ESMTP id JAA20100; Mon, 28 Aug 2000 09:46:37 -0700 (PDT) Received: by admsrvnt02 with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Aug 2000 09:46:29 -0700 Message-ID: <1115A7CFAC25D311BC4000508B2CA5375ECE8E@mailsrvnt02.enet.sharplabs.com> From: "McDonald, Ira" To: "'Peter Johansson'" , Zero Configuration Subject: RE: Use EUI-64 in ZRIP? Date: Mon, 28 Aug 2000 09:46:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Peter, http://standards.ieee.org/regauth/oui/tutorials/EUI64.html Sorry - the original URL was copied verbatim from the references in RFC 2373 (IPv6 Addressing Architecture). I just searched the IEEE site and found the above (valid) URL. Cheers, - Ira McDonald, consulting architect at Xerox and Sharp High North Inc -----Original Message----- From: Peter Johansson [mailto:PJohansson@ACM.org] Sent: Friday, August 25, 2000 12:53 PM To: Zero Configuration Subject: Re: Use EUI-64 in ZRIP? At 12:49 PM 8/25/00, McDonald, Ira wrote: >[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) >Registration Authority", >http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997. Could you provide a working URL, please? Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org