From owner-zeroconf@merit.edu Sat May 1 16:59:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24616 for ; Sat, 1 May 2004 16:59:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F237E91228; Sat, 1 May 2004 16:59:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDD7D91229; Sat, 1 May 2004 16:59:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA2B291228 for ; Sat, 1 May 2004 16:58:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B649B58EFA; Sat, 1 May 2004 16:58:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by segue.merit.edu (Postfix) with ESMTP id 3BF6F58EF2 for ; Sat, 1 May 2004 16:58:59 -0400 (EDT) Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i41Kvmam016423 for ; Sat, 1 May 2004 16:57:48 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i41Kvkam016377 for ; Sat, 1 May 2004 16:57:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Subject: Out of Office AutoReply: Re: Your music MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42FBF.1D9FD943" Date: Sat, 1 May 2004 23:58:55 +0300 Message-ID: Thread-Topic: Re: Your music Thread-Index: AcQvvx2WypGi5lkQRB+JWHO8e0/ykAAAAAJL From: "Romascanu, Dan (Dan)" To: Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C42FBF.1D9FD943 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am out of office on vacation between 4/23 and 4/30. I will do my best = to answer your e-mail as soon as possible after my return to the office. = For urgent issues I can be reached at +972-55-581118.=20 Regards, Dan ------_=_NextPart_001_01C42FBF.1D9FD943 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: <Possible SPAM> Re: Your = music

I am out of office on vacation between 4/23 and 4/30. = I will do my best to answer your e-mail as soon as possible after my = return to the office. For urgent issues I can be reached at = +972-55-581118.

Regards,

Dan

------_=_NextPart_001_01C42FBF.1D9FD943-- From owner-zeroconf@merit.edu Tue May 4 18:36:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04673 for ; Tue, 4 May 2004 18:36:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D4B1C91203; Tue, 4 May 2004 18:36:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4614912B4; Tue, 4 May 2004 18:36:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C508191203 for ; Tue, 4 May 2004 18:36:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8463458DED; Tue, 4 May 2004 18:36:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 04F3758DA5 for ; Tue, 4 May 2004 18:36:19 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i44MaG4U012946 for ; Tue, 4 May 2004 16:36:17 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44MaEx7010288 for ; Wed, 5 May 2004 00:36:15 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 00:35:59 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: IPR notice regarding draft-ietf-zeroconf-IPv4-linklocal Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk The IETF has been notified that Apple has IPR related to draft-ietf-zeroconf-linklocal-ipv4-13.txt. The referenced note also includes licensing terms, consistent with the obligations under RFC 3668. Implications for the WG: The WG needs to be take this IPR (and the provided licensing terms) into consideration and decide how or whether this new IPR issue in anyway changes the WG's previous decision to request that the IESG publish the zeroconf document as PS. Note: the IESG's earlier concerns with this document have been resolved. According to the IESG the main remaining hurdle to having this document approved/published is the IPR issue that just came up. http://www.ietf.cnri.reston.va.us/ietf/IPR/apple-ipr-draft-ietf-zeroconf-ipv4-l\ inklocal.txt Erik Guttman & Thomas Narten From owner-zeroconf@merit.edu Tue May 4 18:41:25 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04967 for ; Tue, 4 May 2004 18:41:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1B53912B4; Tue, 4 May 2004 18:41:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD088912B5; Tue, 4 May 2004 18:41:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B96F3912B4 for ; Tue, 4 May 2004 18:41:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CD7E58E88; Tue, 4 May 2004 18:41:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 27A9458E59 for ; Tue, 4 May 2004 18:41:12 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44MfA6b003478 for ; Tue, 4 May 2004 15:41:11 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44Mf7x7010418 for ; Wed, 5 May 2004 00:41:09 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 00:40:53 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG status - last minute issues to consider Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk WG status: We have only one item on our charter, the IPv4 LL autoconfiguration specification. This document has passed WG and IETF last call and satisfied all remaining IESG objections. I have received a set of change requests from Stuart Cheshire. I am opening a new set of issues to discuss them. I summarize them below. It is of course our continuing desire to publish a high quality document. At the same time, I must resist any attempt to reopen issues which have been resolved at this time. I make my recommendations as to what to do which each issue, but I leave it to you to judge. We will need a strong consensus to adopt *any* changes at this point. Special mention must be made of issue LL67 . Stuart has found a flaw in the protocol as specified which would seriously limit the interoperability of hosts. I strongly encourage the WG to pay special attention to this item and to support the change, even if we have to go through further review. I believe we overlooked this problem and it is entirely consistent with the rest of the document to make the change. Another issue we need to consider closely is LL61. Is it really necessary to add an initial wait interval as per LL31? Thank you in advance for your engagement over the next week in discussing the issues I put before you. Issue Type Title Recommend ----- ---- -------------------------------------------------- --------- LL52 t Text surrounding RFC 2119 clause is poor Reject LL53 e Forward references requested Reject LL54 e Consistent terminology for out of scope Accept ** LL55 e 'Prevent' is too strong Reject LL56 * t Contradictory text? Reject LL57 e Straightforward editorial fixes Accept ** LL58 t Duplicate inconsistent routable address Accept ** definition LL59 e Wireless comment not needed Reject LL60 e Forward reference style Reject LL61 t Remove random wait Accept LL62 * t Do not space probes randomly Reject LL63 * e Text should be more explicit Reject LL64 e Simplify some text Accept ** LL65 * t need a requirement for multihomed hosts Reject LL66 t Additional statistical example Reject LL67 t Fix clause which forbids routable to LL commun- Accept ication LL68 * e Stress constants are not user configurable Reject LL69 e Move constants to beginning of doc Reject LL70 t DNAv4 normative or informative? Reject * TEXT NEEDED ** These fixes are already present in the candidate draft 15 (next draft) - which is available to assist your review at: http://www.drizzle.org/~aboba/ZEROCONF/draft-ietf-zeroconf-ipv4-linklocal-15.txt From owner-zeroconf@merit.edu Tue May 4 19:00:26 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05819 for ; Tue, 4 May 2004 19:00:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C38C912BA; Tue, 4 May 2004 19:00:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D5B8912BB; Tue, 4 May 2004 19:00:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AAE1E912BA for ; Tue, 4 May 2004 19:00:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6343B58C16; Tue, 4 May 2004 19:00:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 60B3458EFE for ; Tue, 4 May 2004 19:00:06 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i44N044U023713 for ; Tue, 4 May 2004 17:00:04 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N00x7010931 for ; Wed, 5 May 2004 01:00:02 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 00:59:46 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL56] Contradictory text? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL56] Description of Issue: Contradictory text? Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: S Section: 1.4, 1.8 Rationale/Explanation: Lengthy Description: [Stuart] > IPv4 addresses ... > ... which can only be resolved on the local link ... > ... SHOULD only be sent when a Link-Local address > is used as the source address. Sent how? In the header? In the payload? Doesn't this contradict the text later in the document that says: > There will be cases when devices with a configured Link-Local address > will need to communicate with a device with a routable address > configured on the same physical link, and vice versa. The rules in > Section 2.6 allow this communication. This says that link-local addresses *can* be used when the source address is *not* link-local. [Erik] The IPv4 address would be sent in the LLMNR (DNS) payload. I though that was obvious due the the context in the paragraph. The first paragraph refers to text in section 1.4.b which discuss limitations of the use of IPv4 LL when used with LLMNR. The second paragraph is in section 1.8 which discusses general communication between two hosts. In the latter case, the text is definitely appropriate. I believe there is no contradiction. 1.4.b does not hinder the use of LLMNR or IPv4 LL configuration except in one case: A host implementor is admonished (using SHOULD) to only hand out a LL address using LLMNR when the host has a LL configuration and only from an interface which in fact has been configured with an LL adddress. [Stuart] I disagee. As stated, a device with a routable address, and a link-local-scope name of some kind, is prohibited from answering queries for that name, because the name can only be resolved on the local link, but the device doesn't have a Link-Local address to use as the source IP address. [Erik] The full quote is: IPv4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded, they SHOULD only be sent when a Link-Local address is used as the source address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply. There is no prohibition. There is only a 'SHOULD' implying that this is not a great idea. The issue of 'leaving the context ni which they apply' is not very serious *today* since LLMNR has only LL scope. In the future, LLMNR might be admin scope MNR. In this case, we will need the SHOULD above - so that link-local scope identifiers (addresses and names) are properly contained. Requested Change: TEXT NEEDED From owner-zeroconf@merit.edu Tue May 4 19:00:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05883 for ; Tue, 4 May 2004 19:00:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F40F4912BC; Tue, 4 May 2004 19:00:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD3E1912BD; Tue, 4 May 2004 19:00:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF2CE912BC for ; Tue, 4 May 2004 19:00:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B893D589C7; Tue, 4 May 2004 19:00:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 478CE58CB3 for ; Tue, 4 May 2004 19:00:28 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44N0M6b012272 for ; Tue, 4 May 2004 16:00:23 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N0Kx7011407 for ; Wed, 5 May 2004 01:00:21 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:00:06 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL53] Forward references requested Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL53] Description of Issue: Forward references requested Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.3 Rationale/Explanation: Lengthy Description: [Stuart] > Link-layer technologies that support ARP but operate at rates below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters described in Sections 2.2, 2.3 > and 2.4: > > (a) the number of, and interval between, ARP probes, > (b) the number of, and interval between, ARP announcements, > (c) the maximum rate at which address claiming may be attempted, and > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address. Aren't these all now parametrized in Section 9? [Erik] Yes, they are parameterized there. However, the text here describes what we are doing and why. [Stuart] Does "the number of, and interval between, ARP probes" refer to PROBE_MIN, PROBE_MAX, PROBE_N, or NUM_PROBES? Why not just make it clear? [Erik] Which of the following versions do you prefer? See http://www.drizzle.org/~aboba/ZEROCONF/draft-ietf-zeroconf-ipv4-linklocal-15.txt in order to make sense of the 'Section references' A Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters described in Sections 2.2.1, 2.4 and 2.5: (a) the number of, and interval between, ARP probes, (b) the number of, and interval between, ARP announcements, (c) the maximum rate at which address claiming may be attempted, and (d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address. B Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters. (a) the number of, and interval between, ARP probes See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 (b) the number of, and interval between, ARP announcements, See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 (c) the maximum rate at which address claiming may be attempted See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section 2.2.1 (d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address See WATCH_WAIT defined in section 2.5 Personally I slightly prefer A. If you have an alternative proposal, please send text. Requested Change: Sec. 3.1 from Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters described in Sections 2.2, 2.3 and 2.4: (a) the number of, and interval between, ARP probes, (b) the number of, and interval between, ARP announcements, (c) the maximum rate at which address claiming may be attempted, and (d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address. to Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters. (a) the number of, and interval between, ARP probes See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 (b) the number of, and interval between, ARP announcements, See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 (c) the maximum rate at which address claiming may be attempted See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section 2.2.1 (d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address See WATCH_WAIT defined in section 2.5 From owner-zeroconf@merit.edu Tue May 4 19:01:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05936 for ; Tue, 4 May 2004 19:01:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39636912BD; Tue, 4 May 2004 19:00:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7620E912BE; Tue, 4 May 2004 19:00:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 544DF912BD for ; Tue, 4 May 2004 19:00:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C7B558C80; Tue, 4 May 2004 19:00:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id DEA8A58D6A for ; Tue, 4 May 2004 19:00:35 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44N0Y6b012408 for ; Tue, 4 May 2004 16:00:34 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N0Ux7011410 for ; Wed, 5 May 2004 01:00:32 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:00:16 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL52] Text surrounding RFC 2119 clause is poor Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL52] Description of Issue: Text surrounding RFC 2119 clause is poor Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.1 Rationale/Explanation: Lengthy Description: > In this document, several words are used to signify the requirements > of the specification. These words are often capitalized. [Stuart] *Often* capitalized? What does that mean? What does it mean if MUST is capitalized? What does it mean if it is not capitalized? [Erik] This is the standard text which goes out with literally every RFC. [Stuart] I disagee. The draft-07 version *was* the standard text. This is not. Just reading it, it makes no sense. It's the wrong paragraph extracted from RFC 2119, out of context, such that it has no sensible meaning. [Erik] RFC 2119 includes the text in the abstract. A quick skim of a dozen standards track RFCs show that they do not include the text you are objecting to, only the legalistic reference to the reserved upper case words. Requested Change: Omit the unnecessary text before "The key words ..." Was: 1.1. Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Becomes: 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", i "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. From owner-zeroconf@merit.edu Tue May 4 19:01:37 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05954 for ; Tue, 4 May 2004 19:01:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1EA77912BE; Tue, 4 May 2004 19:00:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE1DC912BF; Tue, 4 May 2004 19:00:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2FFD1912BE for ; Tue, 4 May 2004 19:00:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 19B4C58C7D; Tue, 4 May 2004 19:00:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 836BB58B7C for ; Tue, 4 May 2004 19:00:47 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i44N0j4U024029 for ; Tue, 4 May 2004 17:00:46 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N0hx7011427 for ; Wed, 5 May 2004 01:00:44 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:00:29 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL54] Consistent terminology for out of scope Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL54] Description of Issue: Consistent terminology for out of scope Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.3, 2.2.1 Rationale/Explanation: Lengthy Description: Page 5 says: > Link-layer technologies that do not support ARP may be able to use > other techniques for determining whether a particular IP address is > currently in use. However, the application of claim-and-defend > mechanisms to such networks is outside the scope of this document. Page 10/11 say: > On a link-layer such as IEEE 802 that supports ARP, conflict > detection is done using ARP probes. On link-layer technologies that > do not support ARP other techniques may be available for determining > whether a particular IPv4 address is currently in use. However, the > application of claim-and-defend mechanisms to such networks is left > to a future document. Lets be consistent. Can we pick one phrase? Either "outside the scope of this document" or "left to a future document". Requested Change: Use consistent terminology: 'out of scope' in each case. From owner-zeroconf@merit.edu Tue May 4 19:01:52 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05975 for ; Tue, 4 May 2004 19:01:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0668912BF; Tue, 4 May 2004 19:01:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A062F912BB; Tue, 4 May 2004 19:01:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 114FC912BF for ; Tue, 4 May 2004 19:01:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E828658C80; Tue, 4 May 2004 19:01:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 6CB3158A53 for ; Tue, 4 May 2004 19:01:06 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i44N14ms003021 for ; Tue, 4 May 2004 16:01:05 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N12x7011490 for ; Wed, 5 May 2004 01:01:03 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:00:48 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL55] Description of Issue: 'Prevent' is too strong Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.4 Rationale/Explanation: Lengthy Description: [Stuart] > In order to prevent use of IPv4 Link-Local addresses in off-link > communication, the following cautionary measures are advised: "prevent" is a bit strong. How about: > In order to reduce the risk of accidental use of IPv4 Link-Local > addresses in off-link communication, the following cautionary > measures are advised: [Erik] We seek the unequivocal prevention of IPv4 LL addressses use off-link not to reduction of the risk of their accidental use off-link. [Stuart] You seek unequivocal prevention, but the cautionary measures you advise don't deliver that. Therefore, stating that the advised cautionary measures "prevent use of IPv4 Link-Local addresses in off-link communication" is demonstrably false. They reduce the risk, but they don't prevent it. Either we need stronger measures, or a weaker statement. Something needs to be fixed. The IP address of my printer is 169.254.207.63. There, I just used a Link-Local address in off-link communication. Can you propose a software measure that would have unequivocally prevented me from doing that? No. The general containment problem is known to be unsolvable. There's no reason to have this kind of mistake in the document. [Erik] The problem is the word 'prevent' for you means 'absolutely prevent' where others have not found this to be the case. Merriam Webster a) to deprive of power or hoep of acting or succeeding b) to keep from happening or existing c) to hold or keep back: HINDER, STOP 'in order to prevent... the following cautionary measures are advised' means 'We advise measures to avoid ...' not 'here is something you can do to absolutely make it impossible for ... to ever occur.' I find your suggested wording unacceptable because we are not seeking to reduce the likelihood of off-link use. This implies that in some sense off-link use is OK. Requested Change: In 1.4 change > In order to prevent use of IPv4 Link-Local addresses in off-link > communication, the following cautionary measures are advised: to > In order to reduce the risk of accidental use of IPv4 Link-Local > addresses in off-link communication, the following cautionary > measures are advised: From owner-zeroconf@merit.edu Tue May 4 19:02:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06054 for ; Tue, 4 May 2004 19:02:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A67C7912BB; Tue, 4 May 2004 19:02:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75CF2912C0; Tue, 4 May 2004 19:02:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5BE3B912BB for ; Tue, 4 May 2004 19:02:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FA1C58D51; Tue, 4 May 2004 19:02:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id C855E58C80 for ; Tue, 4 May 2004 19:02:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i44N18sT011088 for ; Tue, 4 May 2004 17:01:08 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N2Kx7014417 for ; Wed, 5 May 2004 01:02:22 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:02:06 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL57] Description of Issue: Straightforward editorial fixes Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.9 Rationale/Explanation: Lengthy Description: Requested Change: --- >1.9. When to configure a IPv4 Link-Local address Search and replace "a IP" with "an IP" --- [Stuart] >2.4. Announcing an Address > > The host MUST then announce its claimed address by broadcasting > PROBE_N ARP announcements, spaced PROBE_MAX seconds apart. Change to: > ANNOUNCE_N ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart Add to section 9: ANNOUNCE_N 2 ANNOUNCE_INTERVAL 2 seconds --- Section 2.5 > (b) If a host currently has active TCP connections or other reasons > to prefer to keep the same IPv4 address, and it has not seen any > other conflicting ARP packets recently (for IEEE 802, within the last > ten seconds) then it MAY elect to attempt to defend its address becomes If a host currently has active TCP connections or other reasons to prefer to keep the same IPv4 address, and it has not seen any other conflicting ARP packets recently (for IEEE 802, within the last | WATCH_WAIT seconds) then it MAY elect to attempt to defend its address, by recording the time that the conflicting ARP packet was received, and then broadcasting one single ARP announcement, giving its own IP and hardware addresses as the sender addresses of the ARP. Having done this, the host can then continue to use the address normally without any further special action. However, if this is not the first conflicting ARP packet the host has seen, and the time recorded for the previous conflicting ARP packet is recent (within WATCH_WAIT seconds for IEEE 802) then the host MUST immediately cease using this address and configure a new IPv4 Link-Local address as described above. This is necessary to ensure that two hosts do not get stuck in an endless loop with both hosts trying to defend the same address. --- 2.6.2 > Whichever interface is used, if the destination address is in the > 169.254/16 prefix (excluding the address 169.254.255, which is the > broadcast address for the Link-Local prefix), then the sender MUST 169.254.244 becomes 169.254.255.255 --- 3.1 > > This answer is usually answered by referring to a routing table, > > which expresses which interface (with which address) to send, and how becomes This question is usually answered by referring to a routing table, which expresses on which interface (with which address) to send, and how --- from: > >3.4. Unintentional Autoimmunity to: > >3.4. Unintentional Autoimmune Response --- 6.1 From: IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, client TCP connections will fail, to: IPv4 Link-Local addresses used by an application may change over time. Some application software encountering an address change will fail. For example, existing client TCP connections will be aborted, --- 6.2 From: > If the FTP client transmits its passive IPv4 to: > If the FTP client transmits its stale out-of-date passive IPv4 --- From owner-zeroconf@merit.edu Tue May 4 19:04:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06157 for ; Tue, 4 May 2004 19:04:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9776912C0; Tue, 4 May 2004 19:04:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8CAD912C1; Tue, 4 May 2004 19:03:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF84B912C0 for ; Tue, 4 May 2004 19:03:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94BF358DED; Tue, 4 May 2004 19:03:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 5187D58DDF for ; Tue, 4 May 2004 19:03:55 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i44N3rms004259 for ; Tue, 4 May 2004 16:03:54 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N3px7017892 for ; Wed, 5 May 2004 01:03:52 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:03:37 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL58] Duplicate inconsistent routable address definition Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL58] Description of Issue: Duplicate inconsistent routable address definition Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: 1 Section: 1.2, 1.9 Rationale/Explanation: Lengthy Description: > A routable address is any address that is: > > * a unicast address (see Section 1.2) > * not a loopback address > * not contained within the 169.254/16 prefix reserved for IPv4 Link- > Local addresses This duplicates (but not entirely agrees with) Section 1.2. Requested Change: From 1.9. When to configure a Link-Local IPv4 address Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a valid routable address and a Link-Local IPv4 address configured on the same interface. A routable address is any address that is: * a unicast address (see Section 1.2) * not a loopback address * not contained within the 169.254/16 prefix reserved for Link-Local IPv4 addresses To 1.9. When to configure an IPv4 Link-Local address Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a valid routable address and an IPv4 Link-Local address configured on the same interface. From owner-zeroconf@merit.edu Tue May 4 19:05:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06220 for ; Tue, 4 May 2004 19:05:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71461912C1; Tue, 4 May 2004 19:05:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4063E912C2; Tue, 4 May 2004 19:05:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B67F912C1 for ; Tue, 4 May 2004 19:05:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63B0358DC4; Tue, 4 May 2004 19:05:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id E3F2158C7D for ; Tue, 4 May 2004 19:05:05 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44N506b014471 for ; Tue, 4 May 2004 16:05:01 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N4wx7023124 for ; Wed, 5 May 2004 01:04:59 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:04:43 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL59] Wireless comment not needed Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL59] Description of Issue: Wireless comment not needed Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 2 Section: 2.2 Rationale/Explanation: Lengthy Description: [Stuart] > (This example does > not imply that IPv4 Link-Local configuration is inapplicable > to wireless interfaces). Is this sentence necessary? [Erik] Yes, it is needed. This response comes from an IESG comment which would have been a 'discuss' comment and slowed down the progress of the document. Further, this changed text was approved in the WG last call process last month. [Stuart] Just for my own benefit, could you please explain what that sentence is talking about? Why single out wireless? What about powerline? Infrared? HPNA? IP-over-USB? [Erik] This sentence addresses the concern of an IESG member. The proper time to engage them is during the interval in which they are reviewing the document. The sentence is harmless, though not very useful. Including it was necessary to get the document approved. Requested Change: Omit > (This example does > not imply that IPv4 Link-Local configuration is inapplicable > to wireless interfaces). From owner-zeroconf@merit.edu Tue May 4 19:06:19 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06277 for ; Tue, 4 May 2004 19:06:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02F82912C2; Tue, 4 May 2004 19:06:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2275912C3; Tue, 4 May 2004 19:06:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D724E912C2 for ; Tue, 4 May 2004 19:06:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C5A6958E62; Tue, 4 May 2004 19:06:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 4688F58C7D for ; Tue, 4 May 2004 19:06:03 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i44N614U026372 for ; Tue, 4 May 2004 17:06:02 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N5xx7029423 for ; Wed, 5 May 2004 01:06:00 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:05:44 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL60] Forward reference style Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL60] Description of Issue: Forward reference style Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 1.2 Rationale/Explanation: Lengthy Description: [Stuart] > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range PROBE_MIN to PROBE_MAX > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. PROBE_MIN and PROBE_MAX suddenly appear, without mention. Can we give their values FIRST, so the reader has a clue what we're talking about. [Erik] This is standard practice in all RFCs that include constants. We could add text to section 1.2 if you think that this is confusing to implementors. Personally I feel this goes without saying and adding it would only be a matter of (questionable) style. [Stuart] I disagee. What is the harm in helping the reader understand the document better? How can unexplained forward references be good style? Requested Change: Add to section 1.2 Constants are introduced in all capital letters. Their values are given in Section 9. From owner-zeroconf@merit.edu Tue May 4 19:07:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06335 for ; Tue, 4 May 2004 19:07:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC758912C3; Tue, 4 May 2004 19:07:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBA35912C4; Tue, 4 May 2004 19:07:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC86C912C3 for ; Tue, 4 May 2004 19:07:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8BFBB58EF7; Tue, 4 May 2004 19:07:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 56DCB58EE4 for ; Tue, 4 May 2004 19:07:32 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i44N6EsT013187 for ; Tue, 4 May 2004 17:06:15 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44N7Sx7003618 for ; Wed, 5 May 2004 01:07:29 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:07:14 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL61] Description of Issue: Remove initial wait Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: LL12 Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: S Section: 2.2.1 Rationale/Explanation: Lengthy Description: [Stuart] > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range PROBE_MIN to PROBE_MAX > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. Why "wait for a random time interval selected uniformly in the range PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial one-second delay? It just slows things down. [Erik] This delay was intended to stop a set of hosts from beginning at the same time in a 'LAN power up' situation. This text has passed all reviews and numerous WG issues to revise and hone it. [Stuart] I was not asking about the [0,1] random interval. That's been there since draft-05. I was asking about why it is now 1 + [0,1]. What's the extra fixed one-second delay for? What is achieved by making the process uniformly take a second longer than it should? [Erik] Hmm. Reviewing all records, I can't see how this entered the doc. I don't have time for archeology to find out when it entered. I don't see why waiting an extra second helps, except to wait for network infrastructure to come up (see ll12). Requested Change: Text was: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range PROBE_MIN to PROBE_MAX seconds, and should then send NUM_PROBES probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. Text becomes: When ready to begin probing, the host should send NUM_PROBES probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. From owner-zeroconf@merit.edu Tue May 4 19:12:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06581 for ; Tue, 4 May 2004 19:12:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF5CE912C4; Tue, 4 May 2004 19:12:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC920912C5; Tue, 4 May 2004 19:12:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C181E912C4 for ; Tue, 4 May 2004 19:12:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A736558F44; Tue, 4 May 2004 19:12:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 52EE658F11 for ; Tue, 4 May 2004 19:12:13 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44NCB6b017697; Tue, 4 May 2004 16:12:12 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NC8x7020281; Wed, 5 May 2004 01:12:09 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:11:53 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Cc: huitema@windows.microsoft.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL62] Description of Issue: Do not space probes randomly Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: LL31 Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: s Section: 2.2.1 Rationale/Explanation: Lengthy Description: [Stuart] > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range PROBE_MIN to PROBE_MAX > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. Why space probes randomly? I have still not seen any credible justification for this, neither credible theoretical analysis, nor experimental data. This text was introduced because of a misunderstanding of something Christian Huitema said a year ago, and it's been in the document ever since. An initial random delay is justified. Further randomness is just voodoo. [Erik] This was debated frequently in the WG over the past year and in each case the delay was kept in the document. If you really believe that the current text is not reasonable, please contact Christian and see if he agrees with you. As I recall, the WG agreed with Christian, who supported this text and we ended with rough consensus, with you in a dissenting position. See LL31. [Stuart] I disagee. I asked frequently for credible debate, but never got any, and the *misplaced randomness* was kept in the document. (My objection here is not the delay, or even the randomness; it's the pointless inappropriate misplaced randomness.) I did ask Christian Huitema repeatedly, in public and in private, if he was willing to defend this statement that had been attributed to him, but he never responded to any of the requests. [Erik] Requested Change: TEXT NEEDED From owner-zeroconf@merit.edu Tue May 4 19:17:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06878 for ; Tue, 4 May 2004 19:17:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A721591203; Tue, 4 May 2004 19:17:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74C15912B4; Tue, 4 May 2004 19:17:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D49191203 for ; Tue, 4 May 2004 19:17:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 783E958C1B; Tue, 4 May 2004 19:17:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id E924758C7B for ; Tue, 4 May 2004 19:17:18 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i44NHHms010104 for ; Tue, 4 May 2004 16:17:18 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NHFx7022395 for ; Wed, 5 May 2004 01:17:16 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:17:00 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL63] Description of Issue: Text should be more specific Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: LL40 Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 2.11 Rationale/Explanation: Lengthy Description: [Stuart] > Several early implementations of IPv4 Link-Local have modified the > DHCP state machine in an attempt to make IPv4 Link-Local more > reliable, and the field experience we have gained from this has > shown that it does not work - reliability of DHCP service is > significantly reduced. Is this referring to some Windows bug? It's too vague. We should either make it concrete enough that the reader understands the specific example that's being given, or delete it. [Erik] This text was very difficult to craft and resulted in 3 successive WG last call discussions. Revision of this text, or worse, its removal, would cause the document to become unacceptable to the DHC WG. See LL40 especially. [Stuart] Okay, I'll be more blunt: This statement is false. It is an outright lie. Why put known falsehood in the document? If I'm wrong, then please state which "early implementations of IPv4 Link-Local have modified the DHCP state machine in an attempt to make IPv4 Link-Local more reliable" and then I'll be happy with the text. [Erik] You don't like the word 'several' in the cited section, is that the issue? I have no objects changing the word 'several' to 'at least one' Requested Change: TEXT NEEDED From owner-zeroconf@merit.edu Tue May 4 19:18:47 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06924 for ; Tue, 4 May 2004 19:18:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EFE48912B4; Tue, 4 May 2004 19:18:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB416912C5; Tue, 4 May 2004 19:18:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D40D4912B4 for ; Tue, 4 May 2004 19:18:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF8F058C6A; Tue, 4 May 2004 19:18:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 4CFE258E00 for ; Tue, 4 May 2004 19:18:38 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44NIa6b020662 for ; Tue, 4 May 2004 16:18:37 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NIXx7022492 for ; Wed, 5 May 2004 01:18:35 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:18:19 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL64] Simplify some text Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL64] Description of Issue: Simplify some text Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 2 Section: 3.1 Rationale/Explanation: Lengthy Description: > The application knows > the source address of the sender to whom the application will reply. > > The first scoped address problem is source address selection. ... It's confusing. People will think: If the application knows the source address, how can there be a source address selection problem? How about: > The application knows > the address of the sender to whom the application will reply. > > The first scoped address problem is source address selection. ... Requested Change: Change > The application knows > the source address of the sender to whom the application will reply. > > The first scoped address problem is source address selection. ... to: The application knows the address of the sender to whom the application will reply. The first scoped address problem is source address selection. From owner-zeroconf@merit.edu Tue May 4 19:20:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07015 for ; Tue, 4 May 2004 19:20:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D38E91205; Tue, 4 May 2004 19:20:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36D82912C5; Tue, 4 May 2004 19:20:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 431BB91205 for ; Tue, 4 May 2004 19:20:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3028558EA7; Tue, 4 May 2004 19:20:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id E07CA58CBC for ; Tue, 4 May 2004 19:20:07 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44NK66b021262 for ; Tue, 4 May 2004 16:20:06 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NK3x7022599 for ; Wed, 5 May 2004 01:20:05 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:19:49 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL65] Need a requirement for multihomed hosts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL65] Description of Issue: Need a requirement for multihomed hosts Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: LL15, LL32 Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: 1 Section: 3.4 Rationale/Explanation: Lengthy Description: [Stuart] > If a host has two interfaces on the same network The host may not *know* they are bridged onto the same link. This is the real problem that can fool you. I'd prefer a stronger requirement: If a host has more than one interface (on the same network or not) then it MUST NOT attempt to confgure the same LL address on more than one interface. [Erik] This is a pretty good technical suggestion, but its about 2 years late. We have been over this ground many times. The ultimate journey was issue LL15. Since then we have revised the text and moved it around some - it no longer reads 'distinct for each interface', now its 'run the algorithm independently for each interface.' Note that this advice at the end of the first paragraph in section 3.4 would allow the algorithm to detect the conflict and resolve it, albeit less efficiently than if the host had never created the problem in the first place. In issue LL32 we decided we would not attempt to solve problems arising from use of IPv4 LL when used on more than one interface at a time. For this reason, it is inappropriate to include any MUST NOT language in section 3. [Stuart] From my implementation experience, I can tell you that any implementation that tries to configure the same address on more than one interface will run into problems. Requested Change: TEXT NEEDED From owner-zeroconf@merit.edu Tue May 4 19:21:17 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07049 for ; Tue, 4 May 2004 19:21:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07543912C5; Tue, 4 May 2004 19:21:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6967912C6; Tue, 4 May 2004 19:21:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5725912C5 for ; Tue, 4 May 2004 19:21:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C19FE58EDE; Tue, 4 May 2004 19:21:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 7D3DC58EB2 for ; Tue, 4 May 2004 19:21:08 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i44NL6ms011763 for ; Tue, 4 May 2004 16:21:07 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NL4x7022646 for ; Wed, 5 May 2004 01:21:05 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:20:50 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL66] Additional statistical example Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL66] Description of Issue: Additional statistical example Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: 1 Section: 1.3 Rationale/Explanation: Lengthy Description: > When these address conflicts are detected, the subsequent forced > reconfiguration may be disruptive, causing TCP connections to be > broken. However, it is expected that such disruptions will be rare. > It should be relatively uncommon for networks to be joined while > hosts on those networks are active. Also, 65024 addresses are > available for IPv4 Link-Local use, so even when two small networks > are joined, the chance of collision for any given host is fairly > small. A specific example with numbers: If two 100-host networks are joined, there's still a better than 75% chance that not a single host on either network will have to select a new address. [Erik] There has been no demand in successive reviews for further example. [Stuart] I calculated specific numbers to substantiate the previously vague assertion. I believe concrete facts are more informative than vagueness. [Erik] Thanks for the numbers. My point is that we need to publish this document with as few changes as possible. This is not an editorial change. In my opinion 'fact' assertions generate a lot of debate. Requested Change: Add to section 1.3 This specification is intended for use with small ad-hoc networks - a single link containing only a few hosts. Although 65024 IPv4 Link- Local addresses are available in principle, attempting to use all those addresses on a single link would result a high probability of an address conflict, requiring a host to take an inordinate amount of time to find an available address. becomes This specification is intended for use with small ad-hoc networks - a single link containing only a few hosts. Although 65024 IPv4 Link- Local addresses are available in principle, attempting to use all those addresses on a single link would result a high probability of an address conflict, requiring a host to take an inordinate amount of time to find an available address. If two 100-host networks are joined, there's still a better than 75% chance that not a single host on either network will have to select a new address. From owner-zeroconf@merit.edu Tue May 4 19:22:41 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07100 for ; Tue, 4 May 2004 19:22:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C2ED912C6; Tue, 4 May 2004 19:22:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB782912C8; Tue, 4 May 2004 19:22:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC544912C6 for ; Tue, 4 May 2004 19:22:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C250C58ED5; Tue, 4 May 2004 19:22:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 3F62D58E63 for ; Tue, 4 May 2004 19:22:32 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44NMU6b022333 for ; Tue, 4 May 2004 16:22:31 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NMSx7022715 for ; Wed, 5 May 2004 01:22:29 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:22:07 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL67] Fix clause which forbids routable to LL communication Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL67] Description of Issue: Fix clause which forbids routable to LL communication Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: S Section: 6.2 Rationale/Explanation: Lengthy Description: [Stuart] > IPv4 Link-Local addresses MUST NOT be forwarded via an application > protocol (for example in a URL), to a destination which is not Link- > Local, on the same link. This is discussed further in Section 2.9 > and 3. How about: > IPv4 Link-Local addresses MUST NOT be forwarded via an application > protocol (for example in a URL), to a destination which is not > on the same link. This is discussed further in Section 2.9 and 3. [Erik] Your sentence means something entirely different than what is in the document. In your text host A with LL address a could send 'a' in an application protocol to host B with a routable address. In the current document, this would not be allowed. We want proper interaction between hosts A and B with as few restrictions as possible without disruptive consequences. That is the fine line we've had to walk for the past 5 years. I personally prefer your wording (and its meaning) to what the document currently says. To open this up would require us to go back to discussion, last calls, etc. however. [Stuart] As written, other places in the draft allow routable-to-LL communication, but this "MUST NOT" prohibits that. A routable device can't send packets to an LL device unless it knows the LL device's LL address, but how can a routable device learn the LL device's LL address, if sending an LL address to a non-LL destination address is prohibited? [Erik] This is clearly a technical revision we need to consider. I agree that we should make this change. Requested Change: Section 6.2, From: > IPv4 Link-Local addresses MUST NOT be forwarded via an application > protocol (for example in a URL), to a destination which is not Link- > Local, on the same link. This is discussed further in Section 2.9 > and 3. To: > IPv4 Link-Local addresses MUST NOT be forwarded via an application > protocol (for example in a URL), to a destination which is not > on the same link. This is discussed further in Section 2.9 and 3. From owner-zeroconf@merit.edu Tue May 4 19:24:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07201 for ; Tue, 4 May 2004 19:24:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82B81912C8; Tue, 4 May 2004 19:23:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8D1D912CA; Tue, 4 May 2004 19:23:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3A66912C8 for ; Tue, 4 May 2004 19:23:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C87EA58EA9; Tue, 4 May 2004 19:23:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 8348258EFE for ; Tue, 4 May 2004 19:23:44 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i44NNg6b022769 for ; Tue, 4 May 2004 16:23:43 -0700 (PDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NNex7022772 for ; Wed, 5 May 2004 01:23:41 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:23:25 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [ll68] Description of Issue: Stress constants are not user configurable Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: s Section: all Rationale/Explanation: Lengthy Description: [Stuart] Also, we need to stress that these are MUST NOT be user-configurable options, or the users will just decide they can set them to zero to "make it go faster". [Erik] No user configurable options are mentioned in the text. I do not understand what you mean by 'set them to zero.' What settings are you referring to? [Stuart] When you use symbolic identifiers in place of concrete values it implies abstraction (Generalisation; ignoring or hiding details to capture some kind of commonality between different instances), which implies therefore that there are different instances with different values for those abstracted identifiers. If the intention is that different instances will have different values for these symbolic identifiers, then the draft should say so. If the intention is that different instances will have NOT different values for these symbolic identifiers, then the draft should say so. I'm just asking for clarification. [Erik] The reasons we are using constants are * The WG called for it, primarily * There has been an interest in specifying new sets of constants 'in the future' for specific link layers which might call for different timing * Use of constants instead of values in the text is considered absolutely necessary by many technical reviewers, for clarity and style consistent with other IETF published technical documentation. * Use of a constant term assures the assignment of the term will be in one authoritative place. This improves the overall consistency of the document and improves ease of reference. In this respect technical writing parallels acceptable program coding practice. Requested Change: TEXT NEEDED From owner-zeroconf@merit.edu Tue May 4 19:28:03 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07397 for ; Tue, 4 May 2004 19:28:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E3FD912CD; Tue, 4 May 2004 19:25:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43061912D0; Tue, 4 May 2004 19:25:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18AAD912CB for ; Tue, 4 May 2004 19:25:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0006E58F43; Tue, 4 May 2004 19:25:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id AFFA958F40 for ; Tue, 4 May 2004 19:25:12 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i44NPB4U004355 for ; Tue, 4 May 2004 17:25:11 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NP8x7022875 for ; Wed, 5 May 2004 01:25:09 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:24:53 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL69] Move constants to beginning of doc Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [LL69] Description of Issue: Move constants to beginning of doc Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: e Prio ['S' Must|1 should|2 may]: 1 Section: 9 Rationale/Explanation: Lengthy Description: [Stuart] >9. Constants > > The following timing constants are used in this protocol. > > PROBE_MIN 1 second > PROBE_MAX 2 seconds > PROBE_N 2 > NUM_PROBES 3 > MAX_COLLISIONS 10 > RATE_LIMIT_INTERVAL 60 seconds Can we list this *before* they are used in the text? Abstractions are great for experts, but not for people learning. Think about children. They learn specific examples first, and then from a collection of specific examples generalize to abstractions. Beginning with the abstract is not the way to inform the reader. [Erik] Listing constants early in the RFC is not common practice. Constants are not abstractions. [Stuart] Using a symbolic identifier in place of a concrete value is not abstraction? Since when? >abB7stracB7tion B B B PB B B Pronunciation KeyB B (b-strkshn, b-) >ignoring or hiding details > 1. Generalisation; ignoring or hiding details to capture some > kind of commonality between different instances. Examples are > abstract data types (the representation details are hidden), > abstract syntax (the details of the concrete syntax are > ignored), abstract interpretation (details are ignored to > analyse specific properties). > > 2. Parameterisation, making something a function > of something else. Examples are lambda abstractions (making > a term into a function of some variable), higher-order > functions (parameters are functions), bracket abstraction > (making a term into a function of a variable). Requested Change: Move Section 9 to the beginning of the document, say to terminology. From owner-zeroconf@merit.edu Tue May 4 19:28:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07454 for ; Tue, 4 May 2004 19:28:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0E39912D9; Tue, 4 May 2004 19:26:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0288912D8; Tue, 4 May 2004 19:26:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A442912D2 for ; Tue, 4 May 2004 19:26:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36BD958F38; Tue, 4 May 2004 19:26:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id E701C58F04 for ; Tue, 4 May 2004 19:26:32 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i44NPFsT021172 for ; Tue, 4 May 2004 17:25:16 -0600 (MDT) Received: from [80.139.178.51] (vpn-129-150-112-27.Holland.Sun.COM [129.150.112.27]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i44NQTx7022882 for ; Wed, 5 May 2004 01:26:30 +0200 (MEST) Mime-Version: 1.0 X-Sender: erikg@ms-ehdb03-01.germany.sun.com (Unverified) Message-Id: Date: Wed, 5 May 2004 01:26:14 +0200 To: zeroconf@merit.edu From: Erik Guttman Subject: WG ACTION: 2 weeks to discuss [LL70] DNAv4 normative or informative? Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Please post discussion of this issue to the mailing list over the next two weeks ending May 18, 2004. In order to accept this issued, we will need a strong WG consensus given that this is very late in the process. Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of current issues and their status. [ll70] Description of Issue: DNAv4 normative or informative? Submitter Name: Stuart Cheshire Submitter Email Address: cheshire@apple.com Date first submitted: 04 May 04 Reference: Comment Type ['t'ech|'e'dit]: t Prio ['S' Must|1 should|2 may]: S Section: References Rationale/Explanation: Lengthy Description: [Stuart] >[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", > draft-ietf-dhc-dna-ipv4-06.txt, Internet draft (work in > progress), March 2004. Is this normative or informative? If ICMP is normative, this should be too. Or neither should be. [Erik] Why do you say that? The only places we mention DNAv4 is in connection with DHCPv4. If the IESG is happy with the informative reference categorization, so am I. Adding this to the Normative reference section would delay publication of IPv4LL till DNAv4 is done. I do not believe DNAv4 will complete within a year. [Stuart] I disagee. For these reasons, a host SHOULD NOT have both a valid routable address and an IPv4 Link-Local address configured on the same interface. A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. To implement this "SHOULD NOT" requirement, an implementation has to also implement [DNAv4] to determine what's a "valid routable address". Hence, normative reference (or the "SHOULD NOT" prohibition could be removed or refined to not depend on DNAv4). [Erik] Hmmm. Do you realize you want to raise the bar for the publishing of this document beyond what the IESG has called for. This change of category may well result in tens of months delay of publication of this RFC. Can we change the 'is' verb in the second cited sentence to one that reads 'may be determined' and add some text from DNAv4 with an informative reference 'for further information'? That is the way specific citations to 'upcoming work' are usually handled in order to avoid creating document dependencies. Requested Change: Move DNAv4 from informative to normative. From owner-zeroconf@merit.edu Tue May 4 19:39:41 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08021 for ; Tue, 4 May 2004 19:39:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D6AFF912CB; Tue, 4 May 2004 19:39:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3CE4912CC; Tue, 4 May 2004 19:39:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A270E912CB for ; Tue, 4 May 2004 19:39:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 886B858F08; Tue, 4 May 2004 19:39:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by segue.merit.edu (Postfix) with ESMTP id 3539B58EC7 for ; Tue, 4 May 2004 19:39:31 -0400 (EDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 16:39:30 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 May 2004 16:39:14 -0700 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 May 2004 16:39:30 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 16:39:12 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 May 2004 16:37:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 May 2004 16:39:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Date: Tue, 4 May 2004 16:39:18 -0700 Message-ID: Thread-Topic: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Thread-Index: AcQyLKZ368zXdiZ/TTGvts/uq6wqqQAA91yg From: "Christian Huitema" To: "Erik Guttman" , X-OriginalArrivalTime: 04 May 2004 23:39:13.0661 (UTC) FILETIME=[01B482D0:01C43231] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > [LL61] > =20 > Description of Issue: Remove initial wait [skip] > Text becomes: >=20 > When ready to begin probing, the host should send NUM_PROBES probe > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. Uh, no. We want to achieve two things: avoid a meltdown in a power on/off scenario, and space the retransmissions sufficiently to avoid collisions. However you write it, that means "waiting [0, Probe_max - Probe_min] for the initial transmission, then NUM_PROBES probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart (where Probe_Min !=3D 0). -- Christian Huitema From owner-zeroconf@merit.edu Tue May 4 19:45:54 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08344 for ; Tue, 4 May 2004 19:45:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C0CC912CC; Tue, 4 May 2004 19:45:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8327F912BA; Tue, 4 May 2004 19:45:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5CDC5912CC for ; Tue, 4 May 2004 19:45:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 38F0658C16; Tue, 4 May 2004 19:45:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id CB04B58C9E for ; Tue, 4 May 2004 19:45:29 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 4 May 2004 16:45:33 -0700 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 May 2004 16:45:29 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 16:45:29 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 May 2004 16:43:13 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 May 2004 16:45:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Tue, 4 May 2004 16:45:33 -0700 Message-ID: Thread-Topic: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Thread-Index: AcQyLUvVxZl3j6YcQnSXLRtIWNbZ1AAA9cqA From: "Christian Huitema" To: "Erik Guttman" , X-OriginalArrivalTime: 04 May 2004 23:45:28.0026 (UTC) FILETIME=[E0D813A0:01C43231] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > [LL62] >=20 > Description of Issue: Do not space probes randomly > > ... >=20 > Why space probes randomly? I have still not seen any credible > justification for this, neither credible theoretical analysis, nor > experimental data. This text was introduced because of a misunderstanding > of something Christian Huitema said a year ago, and it's been in the > document ever since. An initial random delay is justified. Further > randomness is just voodoo. >=20 > [Erik] >=20 > This was debated frequently in the WG over the past year and in each > case the delay was kept in the document. If you really believe that the > current text is not reasonable, please contact Christian and see if he > agrees with you. As I recall, the WG agreed with Christian, who > supported this text and we ended with rough consensus, with you in a > dissenting position. See LL31. The really important part is the initial randomization. It is then important that each successive trial be space by a sufficient delay. But it is also important to randomize the second delay to avoid "persistent bad luck", i.e. the situation where N hosts pick the same initial delay and then all repeat all of their NUM_PROBE packets at the same time. Since you need to have a random number generation ready in any case the implementation overhead is negligible, so why not do the right thing? -- Christian Huitema From owner-zeroconf@merit.edu Tue May 4 20:22:29 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10033 for ; Tue, 4 May 2004 20:22:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 987B2912FF; Tue, 4 May 2004 20:20:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9770291305; Tue, 4 May 2004 20:20:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98234912F2 for ; Tue, 4 May 2004 20:16:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8434058D6A; Tue, 4 May 2004 20:16:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 2736558C9E for ; Tue, 4 May 2004 20:16:38 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 04 May 2004 16:30:59 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i450GZSu004091; Tue, 4 May 2004 17:16:35 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID68226; Tue, 4 May 2004 20:16:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504201526.01f24af8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 20:16:31 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Should the initial delay be "0 to PROBE_MAX" seconds? I think the second randomization is appropriate. - Ralph At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL61] > >Description of Issue: Remove initial wait >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: LL12 >Comment Type ['t'ech|'e'dit]: t >Prio ['S' Must|1 should|2 may]: S >Section: 2.2.1 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> When ready to begin probing, the host should then wait for a random >> time interval selected uniformly in the range PROBE_MIN 0 >> seconds, and should then send NUM_PROBES probe packets, spaced >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > >Why "wait for a random time interval selected uniformly in the range >PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial >one-second delay? It just slows things down. > >[Erik] > >This delay was intended to stop a set of hosts from beginning at the >same time in a 'LAN power up' situation. This text has passed all >reviews and numerous WG issues to revise and hone it. > >[Stuart] > >I was not asking about the [0,1] random interval. That's been there since >draft-05. > >I was asking about why it is now 1 + [0,1]. What's the extra fixed >one-second delay for? What is achieved by making the process uniformly >take a second longer than it should? > >[Erik] > > Hmm. Reviewing all records, I can't see how this entered the doc. > I don't have time for archeology to find out when it entered. I > don't see why waiting an extra second helps, except to wait for > network infrastructure to come up (see ll12). > >Requested Change: > >Text was: > > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range PROBE_MIN to PROBE_MAX > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. > >Text becomes: > > When ready to begin probing, the host should send NUM_PROBES probe > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. From owner-zeroconf@merit.edu Tue May 4 20:40:40 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10987 for ; Tue, 4 May 2004 20:40:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9CEF791203; Tue, 4 May 2004 20:40:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E970912B4; Tue, 4 May 2004 20:40:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8526991203 for ; Tue, 4 May 2004 20:40:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 75A6058EC8; Tue, 4 May 2004 20:40:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 9E6FD58F46 for ; Tue, 4 May 2004 20:40:31 -0400 (EDT) Received: from [192.168.2.19] ([192.168.2.19]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id i450eUq27967 for ; Tue, 4 May 2004 17:40:30 -0700 Mime-Version: 1.0 (Apple Message framework v613) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Alex Karahalios Subject: Re: IPR notice regarding draft-ietf-zeroconf-IPv4-linklocal Date: Tue, 4 May 2004 17:40:28 -0700 To: Zeroconf X-Mailer: Apple Mail (2.613) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Since utility patents filed before June 7, 1995 are granted for a period of 17 years, and since the Apple patents (4,661,902 & 4,689,786) were granted on April 28, 1987 and August 25, 1987 respectively, it seems to me that one of them has expired and the other will expire after August 25th this year. Is this really a problem, since the IESG will probably not be ready with the final draft, considering all the last minute issues that just came up for consideration? I guess little guys like me will not be shipping products until September. Alex Karahalios On May 4, 2004, at 3:35 PM, Erik Guttman wrote: > The IETF has been notified that Apple has IPR related to > draft-ietf-zeroconf-linklocal-ipv4-13.txt. The referenced note also > includes licensing terms, consistent with the obligations under RFC > 3668. From owner-zeroconf@merit.edu Tue May 4 21:01:13 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11917 for ; Tue, 4 May 2004 21:01:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF5D9912BD; Tue, 4 May 2004 21:00:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A2BE912BB; Tue, 4 May 2004 21:00:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26356912B4 for ; Tue, 4 May 2004 21:00:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 09F9A58E26; Tue, 4 May 2004 21:00:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 9BE1758D51 for ; Tue, 4 May 2004 21:00:51 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 17:13:59 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4510mW9022831; Tue, 4 May 2004 18:00:49 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID69938; Tue, 4 May 2004 21:00:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504205140.02dd2f00@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 20:53:03 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL52] Text surrounding RFC 2119 clause is poor Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the requested change. Quoting from RFC 2119: Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. - Ralph At 01:00 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL52] > >Description of Issue: Text surrounding RFC 2119 clause is poor >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.1 >Rationale/Explanation: >Lengthy Description: > >> In this document, several words are used to signify the requirements >> of the specification. These words are often capitalized. > >[Stuart] >*Often* capitalized? What does that mean? What does it mean if MUST is >capitalized? What does it mean if it is not capitalized? > >[Erik] >This is the standard text which goes out with literally every RFC. > >[Stuart] >I disagee. > >The draft-07 version *was* the standard text. This is not. > >Just reading it, it makes no sense. > >It's the wrong paragraph extracted from RFC 2119, out of context, such >that it has no sensible meaning. > >[Erik] > >RFC 2119 includes the text in the abstract. A quick skim of >a dozen standards track RFCs show that they do not include the >text you are objecting to, only the legalistic reference to the >reserved upper case words. > >Requested Change: > >Omit the unnecessary text before "The key words ..." > >Was: >1.1. Requirements > > In this document, several words are used to signify the requirements > of the specification. These words are often capitalized. The key > words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document > are to be interpreted as described in [RFC2119]. > >Becomes: >1.1. Requirements > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", i > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. From owner-zeroconf@merit.edu Tue May 4 21:01:38 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11935 for ; Tue, 4 May 2004 21:01:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DAAA1912B4; Tue, 4 May 2004 21:00:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A60C1912BB; Tue, 4 May 2004 21:00:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B262B912B4 for ; Tue, 4 May 2004 21:00:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8A3F158E50; Tue, 4 May 2004 21:00:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 48DBB58D51 for ; Tue, 4 May 2004 21:00:53 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 17:14:01 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4510mWB022831; Tue, 4 May 2004 18:00:51 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID69939; Tue, 4 May 2004 21:00:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504205351.01f48d48@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 20:54:04 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL54] Consistent terminology for out of scope Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the proposed change. - Ralph At 01:00 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL54] > >Description of Issue: Consistent terminology for out of scope >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.3, 2.2.1 >Rationale/Explanation: >Lengthy Description: > >Page 5 says: > >> Link-layer technologies that do not support ARP may be able to use >> other techniques for determining whether a particular IP address is >> currently in use. However, the application of claim-and-defend >> mechanisms to such networks is outside the scope of this document. > >Page 10/11 say: > >> On a link-layer such as IEEE 802 that supports ARP, conflict >> detection is done using ARP probes. On link-layer technologies that >> do not support ARP other techniques may be available for determining >> whether a particular IPv4 address is currently in use. However, the >> application of claim-and-defend mechanisms to such networks is left >> to a future document. > >Lets be consistent. Can we pick one phrase? Either "outside the scope of >this document" or "left to a future document". > >Requested Change: > >Use consistent terminology: 'out of scope' in each case. From owner-zeroconf@merit.edu Tue May 4 21:17:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12589 for ; Tue, 4 May 2004 21:17:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C04D91205; Tue, 4 May 2004 21:16:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCBC591252; Tue, 4 May 2004 21:16:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2600B91205 for ; Tue, 4 May 2004 21:16:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 134A358E52; Tue, 4 May 2004 21:16:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id B9AEA58E50 for ; Tue, 4 May 2004 21:16:54 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 17:30:03 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i451GqW9015286; Tue, 4 May 2004 18:16:52 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID70551; Tue, 4 May 2004 21:16:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504210837.01f46058@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 21:09:27 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk "Reduce the risk" doesn't seem strong enough to me. How about: To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised: - Ralph At 01:00 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL55] > >Description of Issue: 'Prevent' is too strong >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.4 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> In order to prevent use of IPv4 Link-Local addresses in off-link >> communication, the following cautionary measures are advised: > >"prevent" is a bit strong. How about: > >> In order to reduce the risk of accidental use of IPv4 Link-Local >> addresses in off-link communication, the following cautionary >> measures are advised: > >[Erik] > >We seek the unequivocal prevention of IPv4 LL addressses use off-link >not to reduction of the risk of their accidental use off-link. > >[Stuart] > >You seek unequivocal prevention, but the cautionary measures you advise >don't deliver that. > >Therefore, stating that the advised cautionary measures "prevent use of >IPv4 Link-Local addresses in off-link communication" is demonstrably >false. They reduce the risk, but they don't prevent it. Either we need >stronger measures, or a weaker statement. Something needs to be fixed. > >The IP address of my printer is 169.254.207.63. > >There, I just used a Link-Local address in off-link communication. > >Can you propose a software measure that would have unequivocally >prevented me from doing that? > >No. > >The general containment problem is known to be unsolvable. > >There's no reason to have this kind of mistake in the document. > >[Erik] > > The problem is the word 'prevent' for you means 'absolutely prevent' > where others have not found this to be the case. Merriam Webster > a) to deprive of power or hoep of acting or succeeding > b) to keep from happening or existing > c) to hold or keep back: HINDER, STOP > > 'in order to prevent... the following cautionary measures are advised' > means 'We advise measures to avoid ...' not 'here is something you can > do to absolutely make it impossible for ... to ever occur.' > > I find your suggested wording unacceptable because we are not seeking > to reduce the likelihood of off-link use. This implies that in some > sense off-link use is OK. > >Requested Change: > >In 1.4 change > >> In order to prevent use of IPv4 Link-Local addresses in off-link >> communication, the following cautionary measures are advised: > >to > >> In order to reduce the risk of accidental use of IPv4 Link-Local >> addresses in off-link communication, the following cautionary >> measures are advised: From owner-zeroconf@merit.edu Tue May 4 21:17:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12626 for ; Tue, 4 May 2004 21:17:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6AC1F91235; Tue, 4 May 2004 21:17:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09B0C91252; Tue, 4 May 2004 21:17:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 706CA91235 for ; Tue, 4 May 2004 21:16:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3391458E52; Tue, 4 May 2004 21:16:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by segue.merit.edu (Postfix) with ESMTP id E7FBB58A49 for ; Tue, 4 May 2004 21:16:56 -0400 (EDT) Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i451GqWB015286; Tue, 4 May 2004 18:16:54 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID70552; Tue, 4 May 2004 21:16:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504211109.01f28ee8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 21:16:48 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Comments inline. - Ralph At 01:02 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL57] > >Description of Issue: Straightforward editorial fixes >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.9 >Rationale/Explanation: >Lengthy Description: >Requested Change: > >--- > >>1.9. When to configure a IPv4 Link-Local address > >Search and replace "a IP" with "an IP" OK with me. >--- > >[Stuart] > >>2.4. Announcing an Address >> >> The host MUST then announce its claimed address by broadcasting >> PROBE_N ARP announcements, spaced PROBE_MAX seconds apart. > >Change to: > >> ANNOUNCE_N ARP announcements, spaced ANNOUNCE_INTERVAL seconds apart > >Add to section 9: > >ANNOUNCE_N 2 >ANNOUNCE_INTERVAL 2 seconds OK with me. >--- > >Section 2.5 > >> (b) If a host currently has active TCP connections or other reasons >> to prefer to keep the same IPv4 address, and it has not seen any >> other conflicting ARP packets recently (for IEEE 802, within the last >> ten seconds) then it MAY elect to attempt to defend its address > >becomes > > If a host currently has active TCP connections or other reasons > to prefer to keep the same IPv4 address, and it has not seen any > other conflicting ARP packets recently (for IEEE 802, within the last >| WATCH_WAIT seconds) then it MAY elect to attempt to defend its address, by > recording the time that the conflicting ARP packet was received, and > then broadcasting one single ARP announcement, giving its own IP and > hardware addresses as the sender addresses of the ARP. Having done > this, the host can then continue to use the address normally without > any further special action. However, if this is not the first > conflicting ARP packet the host has seen, and the time recorded for > the previous conflicting ARP packet is recent (within WATCH_WAIT > seconds for IEEE 802) then the host MUST immediately cease using this > address and configure a new IPv4 Link-Local address as described > above. This is necessary to ensure that two hosts do not get stuck > in an endless loop with both hosts trying to defend the same address. Is the replacement of "ten" with "WATCH_WAIT" the only proposed change? If so, I agree - noting that "WATCH_WAIT" needs to be added to the section in which constants are defined. >--- > >2.6.2 > >> Whichever interface is used, if the destination address is in the >> 169.254/16 prefix (excluding the address 169.254.255, which is the >> broadcast address for the Link-Local prefix), then the sender MUST > >169.254.244 > >becomes > >169.254.255.255 Assuming 169.254.255 is what is replaced, this change is OK with me. >--- > >3.1 > >> > This answer is usually answered by referring to a routing table, >> > which expresses which interface (with which address) to send, and how > >becomes > > This question is usually answered by referring to a routing table, > which expresses on which interface (with which address) to send, and how OK with me. >--- > >from: > >> >3.4. Unintentional Autoimmunity > >to: > >> >3.4. Unintentional Autoimmune Response OK with me. >--- > >6.1 >From: > > IPv4 Link-Local addresses used by an application may change over > time. Some application software encountering an address change will > fail. For example, client TCP connections will fail, > >to: > > IPv4 Link-Local addresses used by an application may change over > time. Some application software encountering an address change will > fail. For example, existing client TCP connections will be aborted, OK with me. >--- > >6.2 >From: > >> If the FTP client transmits its passive IPv4 > >to: > >> If the FTP client transmits its stale out-of-date passive IPv4 OK with me. From owner-zeroconf@merit.edu Tue May 4 21:23:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12925 for ; Tue, 4 May 2004 21:23:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E41B912BB; Tue, 4 May 2004 21:22:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 298E291252; Tue, 4 May 2004 21:22:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C756912BB for ; Tue, 4 May 2004 21:22:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F40158A53; Tue, 4 May 2004 21:22:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id DF3D458E89 for ; Tue, 4 May 2004 21:22:51 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 May 2004 17:37:13 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i451MnW9023430; Tue, 4 May 2004 18:22:49 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID70799; Tue, 4 May 2004 21:22:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504211832.02d9e748@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 21:21:15 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL60] Forward reference style Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk While it's not a big deal, the statement "This is standard practice in all RFCs that include constants" can be disproven by counterexample; RFC 3315 defines all of the symbolic constants in an early section before any of those constants are referenced in the specification. I suggest simply moving section 9 so that it appears before any of the defined symbolic constants are first referenced. - Ralph At 01:05 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL60] > >Description of Issue: Forward reference style >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.2 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> When ready to begin probing, the host should then wait for a random >> time interval selected uniformly in the range PROBE_MIN to PROBE_MAX >> seconds, and should then send NUM_PROBES probe packets, spaced >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > >PROBE_MIN and PROBE_MAX suddenly appear, without mention. Can we give >their values FIRST, so the reader has a clue what we're talking about. > >[Erik] > >This is standard practice in all RFCs that include constants. We could >add text to section 1.2 if you think that this is confusing to >implementors. > >Personally I feel this goes without saying and adding it would only be a >matter of (questionable) style. > >[Stuart] > >I disagee. > >What is the harm in helping the reader understand the document better? > >How can unexplained forward references be good style? > > >Requested Change: > >Add to section 1.2 > > Constants are introduced in all capital letters. Their values are > given in Section 9. From owner-zeroconf@merit.edu Tue May 4 21:38:07 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13779 for ; Tue, 4 May 2004 21:38:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79D27912C0; Tue, 4 May 2004 21:37:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C134912BF; Tue, 4 May 2004 21:37:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43B6391252 for ; Tue, 4 May 2004 21:37:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20BB858F49; Tue, 4 May 2004 21:37:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id D143958C16 for ; Tue, 4 May 2004 21:37:52 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 May 2004 17:52:15 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i451bnW9011668; Tue, 4 May 2004 18:37:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID71265; Tue, 4 May 2004 21:37:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504212142.02e093d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 21:25:19 -0400 To: "Erik Guttman" From: Ralph Droms Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with Christian; randomizing the successive probes may be superstition ("voodoo" seems a little harsh), but it also is common practice and I don't think it hurts to specify it here. BTW, are we assuming the link layer takes care of collisions or should there be some explicit provision for retransmitting if one of the probes suffers a collision? - Ralph At 04:45 PM 5/4/2004 -0700, Christian Huitema wrote: > > [LL62] > > > > Description of Issue: Do not space probes randomly > > > > ... > > > > Why space probes randomly? I have still not seen any credible > > justification for this, neither credible theoretical analysis, nor > > experimental data. This text was introduced because of a >misunderstanding > > of something Christian Huitema said a year ago, and it's been in the > > document ever since. An initial random delay is justified. Further > > randomness is just voodoo. > > > > [Erik] > > > > This was debated frequently in the WG over the past year and in each > > case the delay was kept in the document. If you really believe that >the > > current text is not reasonable, please contact Christian and see if he > > agrees with you. As I recall, the WG agreed with Christian, who > > supported this text and we ended with rough consensus, with you in a > > dissenting position. See LL31. > >The really important part is the initial randomization. It is then >important that each successive trial be space by a sufficient delay. But >it is also important to randomize the second delay to avoid "persistent >bad luck", i.e. the situation where N hosts pick the same initial delay >and then all repeat all of their NUM_PROBE packets at the same time. >Since you need to have a random number generation ready in any case the >implementation overhead is negligible, so why not do the right thing? > >-- Christian Huitema From owner-zeroconf@merit.edu Tue May 4 21:38:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13814 for ; Tue, 4 May 2004 21:38:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE11591252; Tue, 4 May 2004 21:37:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91441912C2; Tue, 4 May 2004 21:37:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 308F991252 for ; Tue, 4 May 2004 21:37:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C3A858F5F; Tue, 4 May 2004 21:37:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id C106A58F57 for ; Tue, 4 May 2004 21:37:54 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 17:51:03 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i451boWB011677; Tue, 4 May 2004 18:37:52 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID71267; Tue, 4 May 2004 21:37:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504212814.02d88800@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 21:28:51 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL64] Simplify some text Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the suggested change. While we're at it, "to whom" ought to be replaced with "to which". - Ralph At 01:18 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL64] > >Description of Issue: Simplify some text >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 2 >Section: 3.1 >Rationale/Explanation: >Lengthy Description: > >> The application knows >> the source address of the sender to whom the application will reply. >> >> The first scoped address problem is source address selection. ... > >It's confusing. People will think: If the application knows the source >address, how can there be a source address selection problem? How about: > >> The application knows >> the address of the sender to whom the application will reply. >> >> The first scoped address problem is source address selection. ... > > >Requested Change: > >Change >> The application knows >> the source address of the sender to whom the application will reply. >> >> The first scoped address problem is source address selection. ... > >to: > > The application knows > the address of the sender to whom the application will reply. > > The first scoped address problem is source address selection. From owner-zeroconf@merit.edu Tue May 4 21:38:44 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13831 for ; Tue, 4 May 2004 21:38:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B49E6912C1; Tue, 4 May 2004 21:37:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6374B912BE; Tue, 4 May 2004 21:37:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3D18912BE for ; Tue, 4 May 2004 21:37:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86E3C58F24; Tue, 4 May 2004 21:37:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 45BDC58F57 for ; Tue, 4 May 2004 21:37:53 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 May 2004 17:51:01 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i451boW9011677; Tue, 4 May 2004 18:37:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID71266; Tue, 4 May 2004 21:37:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504212557.02dd0678@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 21:27:24 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I can't respond to this issue without text suggesting what would be acceptable wording. - Ralph At 01:17 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL63] > >Description of Issue: Text should be more specific >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: LL40 >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 2.11 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> Several early implementations of IPv4 Link-Local have modified the >> DHCP state machine in an attempt to make IPv4 Link-Local more >> reliable, and the field experience we have gained from this has >> shown that it does not work - reliability of DHCP service is >> significantly reduced. > >Is this referring to some Windows bug? It's too vague. We should either >make it concrete enough that the reader understands the specific example >that's being given, or delete it. > >[Erik] > >This text was very difficult to craft and resulted in 3 successive WG >last call discussions. Revision of this text, or worse, its removal, >would cause the document to become unacceptable to the DHC WG. > >See LL40 especially. > >[Stuart] > >Okay, I'll be more blunt: This statement is false. It is an outright lie. >Why put known falsehood in the document? If I'm wrong, then please state >which "early implementations of IPv4 Link-Local have modified the DHCP >state machine in an attempt to make IPv4 Link-Local more reliable" and >then I'll be happy with the text. > >[Erik] > >You don't like the word 'several' in the cited section, is that >the issue? I have no objects changing the word 'several' to 'at least >one' > >Requested Change: > >TEXT NEEDED From owner-zeroconf@merit.edu Tue May 4 22:45:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16515 for ; Tue, 4 May 2004 22:45:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 96ED7912C2; Tue, 4 May 2004 22:44:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 622E8912C3; Tue, 4 May 2004 22:44:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A4F2912C2 for ; Tue, 4 May 2004 22:44:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 328EE58F89; Tue, 4 May 2004 22:44:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by segue.merit.edu (Postfix) with ESMTP id E4C2B58F80 for ; Tue, 4 May 2004 22:44:55 -0400 (EDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 04 May 2004 19:47:04 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i452irpI012256; Tue, 4 May 2004 22:44:53 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-50.cisco.com [10.86.242.50]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AID73154; Tue, 4 May 2004 22:44:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040504214332.01f46160@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 May 2004 22:44:49 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL70] DNAv4 normative or informative? Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Well, I notice there's a difference in usage between draft-ietf-dhc-dna-ipv4-07.txt and draft-ietf-zeroconf-ipv4-linklocal-14.txt: draft-ietf-dhc-dna-ipv4-07.txt: 2.2. Reachability Test If the host has a valid routable IPv4 address on the "most likely" point of attachment, the host will typically perform a reachability test, as described in this section. The purpose of the reachability test is to confirm whether the host is connected to a network on which it has a valid routable IPv4 address. draft-ietf-zeroconf-ipv4-linklocal-14.txt: 1.9. When to configure a Link-Local IPv4 address [...] A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. I read a subtle difference in meaning between these two text snippets: in draft-ietf-dhc-dna-ipv4-07.txt, a valid routable address need not pass the reachability test, while in draft-ietf-zeroconf-ipv4-linklocal-14.txt, a routable address becomes a valid routable address once it has passed the reachability test. And, it's not clear draft-ietf-dhc-dna-ipv4-07.txt is consistent in its use of the phrase "valid routable address". Now, back to the real problem. Unfortunately, it appears draft-ietf-dhc-dna-ipv4-07.txt truly is a normative reference in draft-ietf-zeroconf-ipv4-linklocal-14.txt as the text currently stands. An implementor has to read and understand draft-ietf-dhc-dna-ipv4-07.txt to implement draft-ietf-zeroconf-ipv4-linklocal-14.txt. We could try to finesse the problem as Erik suggests, by changing the reference to the reachability test in draft-ietf-dhc-dna-ipv4-07.txt to be advisory rather than mandatory. Another way around the problem would be to copy the text about reachability testing into draft-ietf-zeroconf-ipv4-linklocal-14.txt. Seems like a lot of text to insert that would cause yet another delay, but I don't have a better suggestion. I don't think removing the restriction against selecting a link-local address when a usable routable address is available shold be removed. - Ralph At 01:26 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[ll70] > >Description of Issue: DNAv4 normative or informative? >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: t >Prio ['S' Must|1 should|2 may]: S >Section: References >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >>[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", >> draft-ietf-dhc-dna-ipv4-06.txt, Internet draft (work in >> progress), March 2004. > >Is this normative or informative? > >If ICMP is normative, this should be too. > >Or neither should be. > >[Erik] > >Why do you say that? The only places we mention DNAv4 is in connection >with DHCPv4. If the IESG is happy with the informative reference >categorization, so am I. Adding this to the Normative reference section >would delay publication of IPv4LL till DNAv4 is done. I do not believe >DNAv4 will complete within a year. > >[Stuart] > >I disagee. > > For these > reasons, a host SHOULD NOT have both a valid routable address and an > IPv4 Link-Local address configured on the same interface. > > A "valid routable address" is a routable address that passes the > reachability test described in section 2 of "Detection of Network > Attachment (DNA) in IPv4" [DNAv4]. > >To implement this "SHOULD NOT" requirement, an implementation has to also >implement [DNAv4] to determine what's a "valid routable address". > >Hence, normative reference (or the "SHOULD NOT" prohibition could be >removed or refined to not depend on DNAv4). > >[Erik] > >Hmmm. Do you realize you want to raise the bar for the publishing >of this document beyond what the IESG has called for. This change >of category may well result in tens of months delay of publication of this >RFC. > >Can we change the 'is' verb in the second cited sentence to one >that reads 'may be determined' and add some text from DNAv4 with >an informative reference 'for further information'? That is the >way specific citations to 'upcoming work' are usually handled in >order to avoid creating document dependencies. > >Requested Change: > >Move DNAv4 from informative to normative. From owner-zeroconf@merit.edu Wed May 5 00:25:37 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21245 for ; Wed, 5 May 2004 00:25:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B3E1F912C3; Wed, 5 May 2004 00:25:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EE8A912C4; Wed, 5 May 2004 00:25:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48D86912C3 for ; Wed, 5 May 2004 00:25:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34BA858E9A; Wed, 5 May 2004 00:25:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id CC1BA58E97 for ; Wed, 5 May 2004 00:25:28 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i452PRg03207; Tue, 4 May 2004 19:25:27 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i454PSi29055; Tue, 4 May 2004 21:25:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Date: Tue, 4 May 2004 21:25:27 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C6EBED8@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Thread-Index: AcQyNwdUfqo4mmnhQI2QzB2bNmRgVgAH6zUw From: "Elder, Alex" To: "Ralph Droms" , "Erik Guttman" Cc: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I made this point in my December "document review blast" e-mail. I'm sorry I didn't make it more formally. I believe there should be an initial delay, but it should be 0.. seconds, although that need not be related to PROBE_MAX. (It has more to do with the number of "time slots" you want to allot for participants to randomly select from.) The proposed text does NOT include any initial delay, therefore I do not agree with it. If the proposal were to have a random initial delay, with a minimum value zero I would agree with it. -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Ralph Droms > Sent: Tuesday, May 04, 2004 7:17 PM > To: Erik Guttman > Cc: zeroconf@merit.edu > Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait >=20 >=20 > Should the initial delay be "0 to PROBE_MAX" seconds? >=20 > I think the second randomization is appropriate. >=20 > - Ralph >=20 > At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote: > >Please post discussion of this issue to the mailing list=20 > over the next two=20 > >weeks > >ending May 18, 2004. In order to accept this issued, we=20 > will need a strong WG > >consensus given that this is very late in the process. > > > >Please see=20 > http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of > >current issues and their status. > > > >[LL61] > > > >Description of Issue: Remove initial wait > >Submitter Name: Stuart Cheshire > >Submitter Email Address: cheshire@apple.com > >Date first submitted: 04 May 04 > >Reference: LL12 > >Comment Type ['t'ech|'e'dit]: t > >Prio ['S' Must|1 should|2 may]: S > >Section: 2.2.1 > >Rationale/Explanation: > >Lengthy Description: > > > >[Stuart] > > > >> When ready to begin probing, the host should then wait=20 > for a random > >> time interval selected uniformly in the range PROBE_MIN 0 > >> seconds, and should then send NUM_PROBES probe packets, spaced > >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > >Why "wait for a random time interval selected uniformly in the range > >PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial > >one-second delay? It just slows things down. > > > >[Erik] > > > >This delay was intended to stop a set of hosts from beginning at the > >same time in a 'LAN power up' situation. This text has passed all > >reviews and numerous WG issues to revise and hone it. > > > >[Stuart] > > > >I was not asking about the [0,1] random interval. That's=20 > been there since > >draft-05. > > > >I was asking about why it is now 1 + [0,1]. What's the extra fixed > >one-second delay for? What is achieved by making the process=20 > uniformly > >take a second longer than it should? > > > >[Erik] > > > > Hmm. Reviewing all records, I can't see how this=20 > entered the doc. > > I don't have time for archeology to find out when it entered. I > > don't see why waiting an extra second helps, except to wait for > > network infrastructure to come up (see ll12). > > > >Requested Change: > > > >Text was: > > > > When ready to begin probing, the host should then wait=20 > for a random > > time interval selected uniformly in the range PROBE_MIN=20 > to PROBE_MAX > > seconds, and should then send NUM_PROBES probe packets, spaced > > randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > >Text becomes: > > > > When ready to begin probing, the host should send=20 > NUM_PROBES probe > > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 >=20 From owner-zeroconf@merit.edu Wed May 5 00:29:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21361 for ; Wed, 5 May 2004 00:29:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3C4B2912C4; Wed, 5 May 2004 00:29:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09621912C5; Wed, 5 May 2004 00:29:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD889912C4 for ; Wed, 5 May 2004 00:29:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1E4958E62; Wed, 5 May 2004 00:29:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id 6349258D18 for ; Wed, 5 May 2004 00:29:27 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i452TQg05293; Tue, 4 May 2004 19:29:26 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i454TQi30813; Tue, 4 May 2004 21:29:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Tue, 4 May 2004 21:29:26 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C01117529@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Thread-Index: AcQyLT4oeEbZvReOQGaBrxrJBHo55wALAJ9Q From: "Elder, Alex" To: "Erik Guttman" , Cc: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I made this point as well in December. I think that an initial random delay is sufficient to avoid excessive collisions (i.e., to avoid a storm during a network power-on event). The subsequent randomness is unnecessary. -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Erik Guttman > Sent: Tuesday, May 04, 2004 6:12 PM > To: zeroconf@merit.edu > Cc: huitema@windows.microsoft.com > Subject: WG ACTION: 2 weeks to discuss [LL62] Do not space probes > randomly >=20 >=20 > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will=20 > need a strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html=20 > for a list of > current issues and their status. >=20 > [LL62] >=20 > Description of Issue: Do not space probes randomly > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: LL31 > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: s > Section: 2.2.1 > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > > When ready to begin probing, the host should then wait=20 > for a random > > time interval selected uniformly in the range PROBE_MIN=20 > to PROBE_MAX > > seconds, and should then send NUM_PROBES probe packets, spaced > > randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 > Why space probes randomly? I have still not seen any credible > justification for this, neither credible theoretical analysis, nor > experimental data. This text was introduced because of a=20 > misunderstanding > of something Christian Huitema said a year ago, and it's been in the > document ever since. An initial random delay is justified. Further > randomness is just voodoo. >=20 > [Erik] >=20 > This was debated frequently in the WG over the past year and in each > case the delay was kept in the document. If you really=20 > believe that the > current text is not reasonable, please contact Christian and see if he > agrees with you. As I recall, the WG agreed with Christian, who > supported this text and we ended with rough consensus, with you in a > dissenting position. See LL31. >=20 > [Stuart] >=20 > I disagee. >=20 > I asked frequently for credible debate, but never got any, and the > *misplaced randomness* was kept in the document. (My objection here is > not the delay, or even the randomness; it's the pointless=20 > inappropriate > misplaced randomness.) >=20 > I did ask Christian Huitema repeatedly, in public and in=20 > private, if he > was willing to defend this statement that had been attributed=20 > to him, but > he never responded to any of the requests. >=20 > [Erik] >=20 > Requested Change: >=20 > TEXT NEEDED >=20 From owner-zeroconf@merit.edu Wed May 5 00:41:58 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21911 for ; Wed, 5 May 2004 00:41:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 917F0912C5; Wed, 5 May 2004 00:41:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DC5B912C8; Wed, 5 May 2004 00:41:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD7AD912C5 for ; Wed, 5 May 2004 00:41:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7DF658EEC; Wed, 5 May 2004 00:41:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id 6809F58EE6 for ; Wed, 5 May 2004 00:41:49 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i452fmg10674; Tue, 4 May 2004 19:41:48 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i454fmi03115; Tue, 4 May 2004 21:41:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable Date: Tue, 4 May 2004 21:41:48 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C0111752B@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable Thread-Index: AcQyLtrdmR65mfu2QTeIHbm8Ttp/4wAK2TEA From: "Elder, Alex" To: "Erik Guttman" , Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I have no objection to making it clear that the symbolic values do not imply they are configurable. But behind that I don't agree with the statmeent that a symbol implies an abstraction which implies configurability. The benefit of using a symbolic value is that it can improve clarity, providing more meaning than (for example) a raw number can. But I'm sure Stuart isn't the only one that will interpret this use that way, so I see no problem with some clarification. -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Erik Guttman > Sent: Tuesday, May 04, 2004 6:23 PM > To: zeroconf@merit.edu > Subject: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not > user configurable >=20 >=20 > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will=20 > need a strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html=20 > for a list of > current issues and their status. >=20 > [ll68] >=20 > Description of Issue: Stress constants are not user=20 > configurable > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: e > Prio ['S' Must|1 should|2 may]: s > Section: all > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > Also, we need to stress that these are MUST NOT be user-configurable > options, or the users will just decide they can set them to=20 > zero to "make > it go faster". >=20 > [Erik] >=20 > No user configurable options are mentioned in the text. I do not > understand what you mean by 'set them to zero.' What settings are you > referring to? >=20 > [Stuart] >=20 > When you use symbolic identifiers in place of concrete values=20 > it implies > abstraction (Generalisation; ignoring or hiding details to=20 > capture some > kind of commonality between different instances), which=20 > implies therefore > that there are different instances with different values for those > abstracted identifiers. >=20 > If the intention is that different instances will have=20 > different values > for these symbolic identifiers, then the draft should say so. >=20 > If the intention is that different instances will have NOT different > values for these symbolic identifiers, then the draft should say so. >=20 > I'm just asking for clarification. >=20 > [Erik] >=20 > The reasons we are using constants are > * The WG called for it, primarily > * There has been an interest in specifying new sets of > constants 'in the future' for specific link layers which > might call for different timing > * Use of constants instead of values in the text is considered > absolutely necessary by many technical reviewers, for clarity > and style consistent with other IETF published technical > documentation. > * Use of a constant term assures the assignment of the term will > be in one authoritative place. This improves the overall > consistency of the document and improves ease of reference. > In this respect technical writing parallels acceptable program > coding practice. >=20 > Requested Change: >=20 > TEXT NEEDED >=20 From owner-zeroconf@merit.edu Wed May 5 11:36:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21435 for ; Wed, 5 May 2004 11:36:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3E2691210; Wed, 5 May 2004 11:36:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AD779120F; Wed, 5 May 2004 11:36:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5232C9120E for ; Wed, 5 May 2004 11:36:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F44258F52; Wed, 5 May 2004 11:36:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs180204.pp.htv.fi [213.243.180.204]) by segue.merit.edu (Postfix) with ESMTP id 465E958F13 for ; Wed, 5 May 2004 11:35:59 -0400 (EDT) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-5) with ESMTP id i45Fb5is004521; Wed, 5 May 2004 18:37:05 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-5) id i45Fb2w3004520; Wed, 5 May 2004 18:37:02 +0300 Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait From: Mika Liljeberg To: "Elder, Alex" Cc: Ralph Droms , Erik Guttman , zeroconf@merit.edu In-Reply-To: <70D0D0CAB1117740B92ABC760349069C6EBED8@aime2k01.adaptec.com> References: <70D0D0CAB1117740B92ABC760349069C6EBED8@aime2k01.adaptec.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083771422.1129.9.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 05 May 2004 18:37:02 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I believe it should have been random initial delay + retransmissions spaced 1 seconds apart, rather than what somehow came out in the document. MikaL On Wed, 2004-05-05 at 07:25, Elder, Alex wrote: > I made this point in my December "document review > blast" e-mail. I'm sorry I didn't make it more > formally. > > I believe there should be an initial delay, but it > should be 0.. seconds, although that > need not be related to PROBE_MAX. > (It has more to do with the number of "time slots" > you want to allot for participants to randomly > select from.) > > The proposed text does NOT include any initial > delay, therefore I do not agree with it. > > If the proposal were to have a random initial > delay, with a minimum value zero I would agree > with it. > > -Alex > > > -----Original Message----- > > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > > Behalf Of Ralph Droms > > Sent: Tuesday, May 04, 2004 7:17 PM > > To: Erik Guttman > > Cc: zeroconf@merit.edu > > Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait > > > > > > Should the initial delay be "0 to PROBE_MAX" seconds? > > > > I think the second randomization is appropriate. > > > > - Ralph > > > > At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote: > > >Please post discussion of this issue to the mailing list > > over the next two > > >weeks > > >ending May 18, 2004. In order to accept this issued, we > > will need a strong WG > > >consensus given that this is very late in the process. > > > > > >Please see > > http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of > > >current issues and their status. > > > > > >[LL61] > > > > > >Description of Issue: Remove initial wait > > >Submitter Name: Stuart Cheshire > > >Submitter Email Address: cheshire@apple.com > > >Date first submitted: 04 May 04 > > >Reference: LL12 > > >Comment Type ['t'ech|'e'dit]: t > > >Prio ['S' Must|1 should|2 may]: S > > >Section: 2.2.1 > > >Rationale/Explanation: > > >Lengthy Description: > > > > > >[Stuart] > > > > > >> When ready to begin probing, the host should then wait > > for a random > > >> time interval selected uniformly in the range PROBE_MIN 0 > > >> seconds, and should then send NUM_PROBES probe packets, spaced > > >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > > >Why "wait for a random time interval selected uniformly in the range > > >PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial > > >one-second delay? It just slows things down. > > > > > >[Erik] > > > > > >This delay was intended to stop a set of hosts from beginning at the > > >same time in a 'LAN power up' situation. This text has passed all > > >reviews and numerous WG issues to revise and hone it. > > > > > >[Stuart] > > > > > >I was not asking about the [0,1] random interval. That's > > been there since > > >draft-05. > > > > > >I was asking about why it is now 1 + [0,1]. What's the extra fixed > > >one-second delay for? What is achieved by making the process > > uniformly > > >take a second longer than it should? > > > > > >[Erik] > > > > > > Hmm. Reviewing all records, I can't see how this > > entered the doc. > > > I don't have time for archeology to find out when it entered. I > > > don't see why waiting an extra second helps, except to wait for > > > network infrastructure to come up (see ll12). > > > > > >Requested Change: > > > > > >Text was: > > > > > > When ready to begin probing, the host should then wait > > for a random > > > time interval selected uniformly in the range PROBE_MIN > > to PROBE_MAX > > > seconds, and should then send NUM_PROBES probe packets, spaced > > > randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > > >Text becomes: > > > > > > When ready to begin probing, the host should send > > NUM_PROBES probe > > > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > From owner-zeroconf@merit.edu Thu May 6 06:19:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03185 for ; Thu, 6 May 2004 06:19:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7802F912CF; Thu, 6 May 2004 06:18:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42547912D0; Thu, 6 May 2004 06:18:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B165912CF for ; Thu, 6 May 2004 06:18:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 346F858FCC; Thu, 6 May 2004 06:18:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cuneata.net (CPE-61-9-204-42.nsw.bigpond.net.au [61.9.204.42]) by segue.merit.edu (Postfix) with SMTP id 3BA6458FAD for ; Thu, 6 May 2004 06:18:55 -0400 (EDT) Received: (qmail 1998 invoked from network); 6 May 2004 10:18:42 -0000 Received: from pc-00034.cuneata.net (192.168.0.34) by squirt.cuneata.net (192.168.0.1) with ESMTP; 06 May 2004 10:18:42 -0000 From: Brad Hards To: Erik Guttman Subject: Re: IPR notice regarding draft-ietf-zeroconf-IPv4-linklocal Date: Thu, 6 May 2004 20:18:38 +1000 User-Agent: KMail/1.6.51 Cc: zeroconf@merit.edu, cheshire@apple.com References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200405062018.38396.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 5 May 2004 8:35 am, Erik Guttman wrote: > The WG needs to be take this IPR (and the provided licensing terms) > into consideration and decide how or whether this new IPR issue in > anyway changes the WG's previous decision to request that the IESG > publish the zeroconf document as PS. Note: the IESG's earlier concerns > with this document have been resolved. According to the IESG the main > remaining hurdle to having this document approved/published is the IPR > issue that just came up. Can the WG chairs identify, or request Apple to identify, the specific claims that alleged to be applicable in each patent? I am opposed to any Proposed Standard that requires RAND licensing. Apple can update it to reflect their proprietary "standard" and release it as an Informational RFC if they wish. Brad From owner-zeroconf@merit.edu Thu May 6 06:39:47 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04596 for ; Thu, 6 May 2004 06:39:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D531912D3; Thu, 6 May 2004 06:39:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 197AA912D2; Thu, 6 May 2004 06:39:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D554912D0 for ; Thu, 6 May 2004 06:39:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28B0858FE7; Thu, 6 May 2004 06:39:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id D576458FE4 for ; Thu, 6 May 2004 06:39:35 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 02:53:00 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46AdVC1018902; Thu, 6 May 2004 03:39:31 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-176.cisco.com [10.86.242.176]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE65155; Thu, 6 May 2004 06:39:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20040506063725.02d85c20@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 06:38:00 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL56] Contradictory text? Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I understand the issue but can't comment until the "Requested Change" is specified. - Ralph At 12:59 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL56] > >Description of Issue: Contradictory text? >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: t >Prio ['S' Must|1 should|2 may]: S >Section: 1.4, 1.8 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> IPv4 addresses ... >> ... which can only be resolved on the local link ... >> ... SHOULD only be sent when a Link-Local address >> is used as the source address. > >Sent how? In the header? In the payload? Doesn't this contradict the text >later in the document that says: > >> There will be cases when devices with a configured Link-Local address >> will need to communicate with a device with a routable address >> configured on the same physical link, and vice versa. The rules in >> Section 2.6 allow this communication. > >This says that link-local addresses *can* be used when the source address >is *not* link-local. > >[Erik] > >The IPv4 address would be sent in the LLMNR (DNS) payload. I though >that was obvious due the the context in the paragraph. > >The first paragraph refers to text in section 1.4.b which discuss >limitations of the use of IPv4 LL when used with LLMNR. The second >paragraph is in section 1.8 which discusses general communication >between two hosts. In the latter case, the text is definitely >appropriate. > >I believe there is no contradiction. 1.4.b does not hinder the use of >LLMNR or IPv4 LL configuration except in one case: A host implementor >is admonished (using SHOULD) to only hand out a LL address using LLMNR >when the host has a LL configuration and only from an interface which in >fact has been configured with an LL adddress. > >[Stuart] > >I disagee. > >As stated, a device with a routable address, and a link-local-scope name >of some kind, is prohibited from answering queries for that name, because >the name can only be resolved on the local link, but the device doesn't >have a Link-Local address to use as the source IP address. > >[Erik] > > The full quote is: > > IPv4 addresses and names which can only be resolved on the local > link SHOULD NOT be forwarded, they SHOULD only be sent when a > Link-Local address is used as the source address. This strong > advice should hinder limited scope addresses and names from > leaving the context in which they apply. > > There is no prohibition. There is only a 'SHOULD' implying that > this is not a great idea. The issue of 'leaving the context ni > which they apply' is not very serious *today* since LLMNR has only > LL scope. In the future, LLMNR might be admin scope MNR. In this > case, we will need the SHOULD above - so that link-local scope > identifiers (addresses and names) are properly contained. > >Requested Change: > >TEXT NEEDED From owner-zeroconf@merit.edu Thu May 6 06:40:00 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04616 for ; Thu, 6 May 2004 06:40:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C61B7912D1; Thu, 6 May 2004 06:39:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AE8F912D0; Thu, 6 May 2004 06:39:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AAC14912D1 for ; Thu, 6 May 2004 06:39:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 953FF58FE7; Thu, 6 May 2004 06:39:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 541E358FE4 for ; Thu, 6 May 2004 06:39:37 -0400 (EDT) Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 06 May 2004 02:53:02 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46AdVC3018902; Thu, 6 May 2004 03:39:35 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-176.cisco.com [10.86.242.176]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE65156; Thu, 6 May 2004 06:39:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20040506063819.02d6c808@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 06:38:43 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL53] Forward references requested Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I'm neutral about the proposed change - doesn't seem necessary to me but I don't object to it. - Ralph At 01:00 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL53] > >Description of Issue: Forward references requested >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.3 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> Link-layer technologies that support ARP but operate at rates below 1 >> Mbps or latencies above one second may need to specify different >> values for the following parameters described in Sections 2.2, 2.3 >> and 2.4: >> >> (a) the number of, and interval between, ARP probes, >> (b) the number of, and interval between, ARP announcements, >> (c) the maximum rate at which address claiming may be attempted, and >> (d) the time interval between conflicting ARPs below which a host >> MUST reconfigure instead of attempting to defend its address. > >Aren't these all now parametrized in Section 9? > >[Erik] > >Yes, they are parameterized there. However, the text here describes >what we are doing and why. > >[Stuart] > >Does "the number of, and interval between, ARP probes" refer to >PROBE_MIN, PROBE_MAX, PROBE_N, or NUM_PROBES? Why not just make it clear? > >[Erik] > > Which of the following versions do you prefer? > See > http://www.drizzle.org/~aboba/ZEROCONF/draft-ietf-zeroconf-ipv4-linklocal-15.txt > > in order to make sense of the 'Section references' > > A > > Link-layer technologies that support ARP but operate at rates below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters described in Sections 2.2.1, 2.4 > and 2.5: > > (a) the number of, and interval between, ARP probes, > (b) the number of, and interval between, ARP announcements, > (c) the maximum rate at which address claiming may be attempted, and > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address. > > B > > Link-layer technologies that support ARP but operate at rates below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters. > > (a) the number of, and interval between, ARP probes > See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 > > (b) the number of, and interval between, ARP announcements, > See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 > > (c) the maximum rate at which address claiming may be attempted > See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section 2.2.1 > > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address > See WATCH_WAIT defined in section 2.5 > > Personally I slightly prefer A. If you have an alternative > proposal, please send text. > >Requested Change: > >Sec. 3.1 from > > Link-layer technologies that support ARP but operate at rates below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters described in Sections 2.2, 2.3 > and 2.4: > > (a) the number of, and interval between, ARP probes, > (b) the number of, and interval between, ARP announcements, > (c) the maximum rate at which address claiming may be attempted, and > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address. > > >to > > Link-layer technologies that support ARP but operate at rates below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters. > > (a) the number of, and interval between, ARP probes > See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 > > (b) the number of, and interval between, ARP announcements, > See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 > > (c) the maximum rate at which address claiming may be attempted > See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section 2.2.1 > > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address > See WATCH_WAIT defined in section 2.5 From owner-zeroconf@merit.edu Thu May 6 06:48:05 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05076 for ; Thu, 6 May 2004 06:48:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF8CD912D0; Thu, 6 May 2004 06:47:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92D02912D2; Thu, 6 May 2004 06:47:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EEB1912D0 for ; Thu, 6 May 2004 06:47:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CA3B58FDB; Thu, 6 May 2004 06:47:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by segue.merit.edu (Postfix) with ESMTP id EE53358FC6 for ; Thu, 6 May 2004 06:47:55 -0400 (EDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 May 2004 03:42:53 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46AlrYu017838; Thu, 6 May 2004 06:47:53 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-176.cisco.com [10.86.242.176]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE65287; Thu, 6 May 2004 06:47:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20040506064401.02d9cee8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 06:44:39 -0400 To: Erik Guttman From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL59] Wireless comment not needed Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I do not agree with the suggested change. The sentence is harmless and satisfies a requirement from the IESG. - Ralph At 01:04 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL59] > >Description of Issue: Wireless comment not needed >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: e >Prio ['S' Must|1 should|2 may]: 2 >Section: 2.2 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> (This example does >> not imply that IPv4 Link-Local configuration is inapplicable >> to wireless interfaces). > >Is this sentence necessary? > >[Erik] > >Yes, it is needed. This response comes from an IESG comment which would >have been a 'discuss' comment and slowed down the progress of the >document. Further, this changed text was approved in the WG last call >process last month. > >[Stuart] > >Just for my own benefit, could you please explain what that sentence is >talking about? Why single out wireless? What about powerline? Infrared? >HPNA? IP-over-USB? > >[Erik] > > This sentence addresses the concern of an IESG member. The > proper time to engage them is during the interval in which they > are reviewing the document. > > The sentence is harmless, though not very useful. Including it > was necessary to get the document approved. > >Requested Change: > >Omit > >> (This example does >> not imply that IPv4 Link-Local configuration is inapplicable >> to wireless interfaces). From owner-zeroconf@merit.edu Thu May 6 06:48:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05094 for ; Thu, 6 May 2004 06:48:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CF71912D4; Thu, 6 May 2004 06:48:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FD20912D2; Thu, 6 May 2004 06:48:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA14C912D4 for ; Thu, 6 May 2004 06:47:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC92858FB8; Thu, 6 May 2004 06:47:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by segue.merit.edu (Postfix) with ESMTP id 80A5258FC6 for ; Thu, 6 May 2004 06:47:57 -0400 (EDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 06 May 2004 03:42:54 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i46AlrYw017838; Thu, 6 May 2004 06:47:55 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-176.cisco.com [10.86.242.176]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE65288; Thu, 6 May 2004 06:47:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20040506064545.02d8c8a0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 May 2004 06:46:35 -0400 To: cheshire@apple.com From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL66] Additional statistical example Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart - for my own understanding, can you explain the computation you made for your statistical example? - Ralph At 01:20 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL66] > >Description of Issue: Additional statistical example >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: t >Prio ['S' Must|1 should|2 may]: 1 >Section: 1.3 >Rationale/Explanation: >Lengthy Description: > >> When these address conflicts are detected, the subsequent forced >> reconfiguration may be disruptive, causing TCP connections to be >> broken. However, it is expected that such disruptions will be rare. >> It should be relatively uncommon for networks to be joined while >> hosts on those networks are active. Also, 65024 addresses are >> available for IPv4 Link-Local use, so even when two small networks >> are joined, the chance of collision for any given host is fairly >> small. > >A specific example with numbers: If two 100-host networks are joined, >there's still a better than 75% chance that not a single host on either >network will have to select a new address. > >[Erik] > >There has been no demand in successive reviews for further example. > >[Stuart] > >I calculated specific numbers to substantiate the previously vague >assertion. > >I believe concrete facts are more informative than vagueness. > >[Erik] > >Thanks for the numbers. My point is that we need to publish this >document with as few changes as possible. This is not an editorial >change. In my opinion 'fact' assertions generate a lot of debate. > >Requested Change: > >Add to section 1.3 > > This specification is intended for use with small ad-hoc networks - a > single link containing only a few hosts. Although 65024 IPv4 Link- > Local addresses are available in principle, attempting to use all > those addresses on a single link would result a high probability of > an address conflict, requiring a host to take an inordinate amount of > time to find an available address. > >becomes > > This specification is intended for use with small ad-hoc networks - a > single link containing only a few hosts. Although 65024 IPv4 Link- > Local addresses are available in principle, attempting to use all > those addresses on a single link would result a high probability of > an address conflict, requiring a host to take an inordinate amount of > time to find an available address. > > If two 100-host networks are joined, > there's still a better than 75% chance that not a single host on either > network will have to select a new address. From owner-zeroconf@merit.edu Thu May 6 07:53:38 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07941 for ; Thu, 6 May 2004 07:53:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB991912D6; Thu, 6 May 2004 07:53:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E623912D7; Thu, 6 May 2004 07:53:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 630F7912D6 for ; Thu, 6 May 2004 07:53:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D99559003; Thu, 6 May 2004 07:53:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id D462C58FCC for ; Thu, 6 May 2004 07:53:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i46BrSsm007210 for ; Thu, 6 May 2004 07:53:28 -0400 (EDT) Received: from [10.0.0.14] (CPE-24-163-147-32.kc.rr.com [24.163.147.32]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i46BrOAf023217 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 6 May 2004 07:53:26 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Thu, 06 May 2004 06:53:23 -0500 Subject: Re: IPR notice regarding draft-ietf-zeroconf-IPv4-linklocal From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200405062018.38396.bhards@bigpond.net.au> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable On 5/6/04 5:18 AM, "Brad Hards" wrote: >> The WG needs to be take this IPR (and the provided licensing terms) >> into consideration and decide how or whether this new IPR issue in >> anyway changes the WG's previous decision to request that the IESG >> publish the zeroconf document as PS. Note: the IESG's earlier concerns >> with this document have been resolved. According to the IESG the main >> remaining hurdle to having this document approved/published is the IPR >> issue that just came up. > Can the WG chairs identify, or request Apple to identify, the specific cl= aims > that alleged to be applicable in each patent? >=20 > I am opposed to any Proposed Standard that requires RAND licensing. Apple= can > update it to reflect their proprietary "standard" and release it as an > Informational RFC if they wish. Before we get too worried about something that may or may not happen, what is the history of similar circumstances and how has it played out? (I'd be surprised if this is the first time this has happened) john --=20 If, while chugging a beer, the phrase, =B3I bet this is going to be the last coherent thought I have tonight,=B2 runs through your head, get someone to take you home. Now. From owner-zeroconf@merit.edu Thu May 6 15:24:15 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13531 for ; Thu, 6 May 2004 15:24:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3573912EB; Thu, 6 May 2004 15:23:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 705F5912EA; Thu, 6 May 2004 15:23:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7CA191224 for ; Thu, 6 May 2004 15:23:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9278A58FEE; Thu, 6 May 2004 15:23:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 1CCFA58E32 for ; Thu, 6 May 2004 15:23:54 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNp012276 for ; Fri, 7 May 2004 02:23:51 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i450rGgY023323; Wed, 5 May 2004 07:53:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i450px6H023496; Wed, 5 May 2004 07:52:26 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL65] Need a requirement for multihomed hosts In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 07:51:59 +0700 Message-ID: <24298.1083718319@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:19:49 +0200 From: Erik Guttman Message-ID: [Stuart really...] | The host may not *know* they are bridged onto the same link. This is the | real problem that can fool you. Yes, it is, this can be a real difficulty. | I'd prefer a stronger requirement: If a host has more than one interface | (on the same network or not) then it MUST NOT attempt to confgure the | same LL address on more than one interface. There's no need for that in the protocol. | From my implementation experience, I can tell you that any implementation | that tries to configure the same address on more than one interface will | run into problems. It very well might. But that doesn't mean that it can't be done. This is up to the implementors to decide. Nothing requires that the host use the same address on all interfaces - if an implementor decides that using a different one on every interface is the easy way to avoid problems, then that's fine. But some other implementor may decide to do it some other way. The protocol works whichever decision they make, this restriction isn't needed (and wasn't any of the other of the dozen times this has been discussed). Reject this change. kre From owner-zeroconf@merit.edu Thu May 6 15:24:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13549 for ; Thu, 6 May 2004 15:24:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6784F912EC; Thu, 6 May 2004 15:23:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C28A8912E8; Thu, 6 May 2004 15:23:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6C04912E8 for ; Thu, 6 May 2004 15:23:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7BF35903B; Thu, 6 May 2004 15:23:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 4241959047 for ; Thu, 6 May 2004 15:23:54 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNo012275 for ; Fri, 7 May 2004 02:23:51 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i4513FgY001582; Wed, 5 May 2004 08:03:15 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i4512F6H020472; Wed, 5 May 2004 08:02:15 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu, huitema@windows.microsoft.com Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 08:02:15 +0700 Message-ID: <14207.1083718935@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:11:53 +0200 From: Erik Guttman Message-ID: | Why space probes randomly? I have still not seen any credible | justification for this, neither credible theoretical analysis, nor | experimental data. This text was introduced because of a misunderstanding | of something Christian Huitema said a year ago, and it's been in the | document ever since. An initial random delay is justified. Further | randomness is just voodoo. We have been through this before. Stuart seems to have a fixation on one (incorrect) rationale for this, and ignores all attempts to point out the real reason. Leave this just as it is (ie: I agree with Christian's response). kre From owner-zeroconf@merit.edu Thu May 6 15:25:04 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13650 for ; Thu, 6 May 2004 15:25:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 91B0C912E9; Thu, 6 May 2004 15:24:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64A67912F2; Thu, 6 May 2004 15:24:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8FD891224 for ; Thu, 6 May 2004 15:23:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B3275904A; Thu, 6 May 2004 15:23:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id EEECE58FEE for ; Thu, 6 May 2004 15:23:55 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNr012282 for ; Fri, 7 May 2004 02:23:53 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i45165gY028248; Wed, 5 May 2004 08:06:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i451526H024898; Wed, 5 May 2004 08:05:03 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 08:05:02 +0700 Message-ID: <26187.1083719102@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:23:25 +0200 From: Erik Guttman Message-ID: | [Stuart] | | Also, we need to stress that these are MUST NOT be user-configurable | options, or the users will just decide they can set them to zero to "make | it go faster". This is just plain silly. Nothing suggests that anything is user configurable. That said, if the users demand to be able to configure any of these numbers, the implementations will make them configurable, whatever the text says. No change is needed here. kre From owner-zeroconf@merit.edu Thu May 6 15:25:05 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13680 for ; Thu, 6 May 2004 15:25:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A19B912ED; Thu, 6 May 2004 15:24:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 905FA912EF; Thu, 6 May 2004 15:24:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD6A0912ED for ; Thu, 6 May 2004 15:23:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF8DB5903B; Thu, 6 May 2004 15:23:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3A54658E32 for ; Thu, 6 May 2004 15:23:57 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNm012271 for ; Fri, 7 May 2004 02:23:48 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i451CdgY018095; Wed, 5 May 2004 08:12:39 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i451BU6H026445; Wed, 5 May 2004 08:11:30 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL70] DNAv4 normative or informative? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 08:11:30 +0700 Message-ID: <25066.1083719490@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:26:14 +0200 From: Erik Guttman Message-ID: [Stuart] | To implement this "SHOULD NOT" requirement, an implementation has to also | implement [DNAv4] to determine what's a "valid routable address". | | Hence, normative reference (or the "SHOULD NOT" prohibition could be | removed or refined to not depend on DNAv4). I agree with that, it is clearly a normative reference as the text currently stands. | [Erik] | | Hmmm. Do you realize you want to raise the bar for the publishing | of this document beyond what the IESG has called for. Yes, we could cheat, but then if the DNA doc never appears, the LL spec will be useless. The best way to fix this is to rewrite the reference so that it is no longer normative -- the easy way to do that would be to simply copy the text from the DNA draft that describes what is a valid routable address, and include it in this doc (and then add an informative reference to note the source of the text). Do that we get exactly the meaning the doc currently has, no indefinite delay waiting for another WG's doc to appear, and no cheating of the process (with everyone just looking the other way) either. [Aside: even if the IESG allow this through, because of negligence or collusion, the RFC editor may spot it, and hold up publication anyway, so it needs to be fixed, one way or another]. kre From owner-zeroconf@merit.edu Thu May 6 15:25:13 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13731 for ; Thu, 6 May 2004 15:25:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34190912EA; Thu, 6 May 2004 15:24:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A38AC912E8; Thu, 6 May 2004 15:24:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5922E912E9 for ; Thu, 6 May 2004 15:23:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D0AB59047; Thu, 6 May 2004 15:23:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id AC98458E32 for ; Thu, 6 May 2004 15:23:55 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNq012279 for ; Fri, 7 May 2004 02:23:53 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i450vHgY027053; Wed, 5 May 2004 07:57:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i450uN6H027305; Wed, 5 May 2004 07:56:23 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL54] Consistent terminology for out of scope In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 07:56:23 +0700 Message-ID: <27454.1083718583@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:00:29 +0200 From: Erik Guttman Message-ID: | Lets be consistent. Can we pick one phrase? Either "outside the scope of | this document" or "left to a future document". This isn't even worth discussing, the text as it stands is fine. (It would be OK if it had used the same phrase both places, but there's no need to go changing it now just for that purpose). kre From owner-zeroconf@merit.edu Thu May 6 15:25:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13784 for ; Thu, 6 May 2004 15:25:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DC04912EF; Thu, 6 May 2004 15:24:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4116291224; Thu, 6 May 2004 15:24:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AB7C91224 for ; Thu, 6 May 2004 15:24:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81D0E58E32; Thu, 6 May 2004 15:24:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 0EC8C5903B for ; Thu, 6 May 2004 15:23:59 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNu012291 for ; Fri, 7 May 2004 02:23:56 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i450tfgY016619; Wed, 5 May 2004 07:55:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i450sn6H027958; Wed, 5 May 2004 07:54:49 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL69] Move constants to beginning of doc In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 07:54:49 +0700 Message-ID: <26053.1083718489@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:24:53 +0200 From: Erik Guttman Message-ID: | Abstractions are great for experts, but not for people learning. RFCs are for implementors, not for people learning. Implementors, if not necessarily experts, should at least be competent. If someone wants to publish a book "IPv4 link local addresses for morons" (or whatever) then they can do it in a way which manes it easy for beginners to learn the protocol. The RFC doesn't need to do that. Reject this (and other similar) change requests (there was at least one more that was just like this one). kre From owner-zeroconf@merit.edu Thu May 6 15:25:21 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13780 for ; Thu, 6 May 2004 15:25:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 755D3912E8; Thu, 6 May 2004 15:24:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB987912F3; Thu, 6 May 2004 15:24:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C295912EF for ; Thu, 6 May 2004 15:23:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9CF558E32; Thu, 6 May 2004 15:23:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 5E7F659048 for ; Thu, 6 May 2004 15:23:57 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNs012285 for ; Fri, 7 May 2004 02:23:54 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i450x6gY001622; Wed, 5 May 2004 07:59:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i450wA6H026180; Wed, 5 May 2004 07:58:10 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 07:58:10 +0700 Message-ID: <27637.1083718690@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:00:48 +0200 From: Erik Guttman Message-ID: [Stuart] | The IP address of my printer is 169.254.207.63. | | There, I just used a Link-Local address in off-link communication. No, you didn't use the address, you just typed it, the address wasn't used (not as an address anyway). Leave this text as it is, it is fine as it stands. kre From owner-zeroconf@merit.edu Thu May 6 15:25:37 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13934 for ; Thu, 6 May 2004 15:25:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97E82912F0; Thu, 6 May 2004 15:24:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F23EE912F2; Thu, 6 May 2004 15:24:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2560912F0 for ; Thu, 6 May 2004 15:23:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD62358E32; Thu, 6 May 2004 15:23:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 38C2759038 for ; Thu, 6 May 2004 15:23:58 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i46JNt012288 for ; Fri, 7 May 2004 02:23:55 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i450kTgY027352; Wed, 5 May 2004 07:46:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i450ji6H013439; Wed, 5 May 2004 07:45:45 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 May 2004 07:45:44 +0700 Message-ID: <19704.1083717944@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 May 2004 01:02:06 +0200 From: Erik Guttman Message-ID: Most of this issue is (or seems to be) editorial, and if someone checks, and decides that the changes are all editorial (changing "a IP" to "an IP" clearly is) then I have no problems with most of them. However, this one, which is mixed in with all that noise ... | Section 2.5 | | > (b) If a host currently has active TCP connections or other reasons | > to prefer to keep the same IPv4 address, and it has not seen any | > other conflicting ARP packets recently (for IEEE 802, within the last | > ten seconds) then it MAY elect to attempt to defend its address | | becomes | | If a host currently has active TCP connections or other reasons | to prefer to keep the same IPv4 address, and it has not seen any | other conflicting ARP packets recently (for IEEE 802, within the last | | WATCH_WAIT seconds) then it MAY elect to attempt to defend its address, by | recording the time that the conflicting ARP packet was received, and | then broadcasting one single ARP announcement, giving its own IP and | hardware addresses as the sender addresses of the ARP. Having done | this, the host can then continue to use the address normally without | any further special action. However, if this is not the first | conflicting ARP packet the host has seen, and the time recorded for | the previous conflicting ARP packet is recent (within WATCH_WAIT | seconds for IEEE 802) then the host MUST immediately cease using this | address and configure a new IPv4 Link-Local address as described | above. This is necessary to ensure that two hosts do not get stuck | in an endless loop with both hosts trying to defend the same address. if fundamentally wrong. I know that Stuart believes that the most important issue is to prevent 2 hosts getting locked up, each refusing to abandon a duplicated address. I disagree. For me, the most important issue is to prevent the trivial ability of a host to cause my system to abandon its addresses after which it can take over all my TCP connections (they're on the same link, by definition using LL addresses, on many media types, that means the "bad guy" has all the info needed to pick up my connections, after I have abandoned the address, and what's more, with nothing to interfere with his continued use of the connections - my host won't be sending any packets that might get in the way, which it would if I had retained the address). By all means, Stuart can make his implementations release addresses as soon as it sees a conflict (or a 2nd conflict) - I just won't use anything that absurd on any system I care about. There's no need for the spec to prohibit that kind of behaviour. But the spec must not try and enforce it. Leave this text as it is. kre From owner-zeroconf@merit.edu Fri May 7 01:34:53 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12703 for ; Fri, 7 May 2004 01:34:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21B4291232; Fri, 7 May 2004 01:34:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E17FF91233; Fri, 7 May 2004 01:34:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07D6691232 for ; Fri, 7 May 2004 01:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6E1858C4B; Fri, 7 May 2004 01:34:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 6AC8A58F7B for ; Fri, 7 May 2004 01:34:43 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475Ygdq004223 for ; Thu, 6 May 2004 22:34:42 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:34:42 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i475YeO0026250 for ; Thu, 6 May 2004 22:34:41 -0700 (PDT) Message-Id: <200405070534.i475YeO0026250@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL52] Text surrounding RFC 2119 clause is poor Date: Thu, 6 May 2004 22:34:44 -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 >Requested Change: > >Omit the unnecessary text before "The key words ..." > >Was: >1.1. Requirements > > In this document, several words are used to signify the requirements > of the specification. These words are often capitalized. The key > words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document > are to be interpreted as described in [RFC2119]. > >Becomes: >1.1. Requirements > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", i > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. Actually, specifically what I'd like is that we just put it back exactly how it was in earlier drafts: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC 2119]. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:39:23 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12889 for ; Fri, 7 May 2004 01:39:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B35A691233; Fri, 7 May 2004 01:39:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8305991234; Fri, 7 May 2004 01:39:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 956F091233 for ; Fri, 7 May 2004 01:39:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 72C9859087; Fri, 7 May 2004 01:39:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 2E5E859084 for ; Fri, 7 May 2004 01:39:13 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475dCpf004461 for ; Thu, 6 May 2004 22:39:12 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:39:12 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay1.apple.com (8.12.11/8.12.11) with SMTP id i475dAZW010257 for ; Thu, 6 May 2004 22:39:11 -0700 (PDT) Message-Id: <200405070539.i475dAZW010257@relay1.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL53] Forward references requested Date: Thu, 6 May 2004 22:39: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 > Personally I slightly prefer A. If you have an alternative > proposal, please send text. What I suggest is: 1. List the constants, with a brief explanation, and give the value. The brief explanation doesn't have to duplicate the full explanation which appears later -- just enough to demystify an otherwise opaque name. 2. State the technologies that may use other values. e.g. Section 1.3 "Constants" The following constants are defined here and referenced later in this document. START_WAIT 1 second (initial random delay) PROBE_NUM 3 (number of probe packets) PROBE_INTERVAL 1 second (time between probe packets) ANNOUNCE_NUM 2 (number of announcement packets) ANNOUNCE_INTERVAL 2 seconds (time between announcement packets) RATE_LIMIT_NUM 10 (max collisions before rate limiting) RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) DEFEND_INTERVAL 10 seconds (minimum time between defensive ARPs) These values are fixed for all implementations conforming to this standard. They MUST NOT be end-user configurable options, nor should the listing of the values here be taken to imply that each implementer is free to substitute other values instead, based on what they think will suit each device best. An important part of creating interoperable products is being able to depend on predictable behaviour from the other products you're interoperating with, and having arbitrary variation between different implementations would significantly undermine that ability. Future standards documents, extending IPv4 Link-Local Addressing to media types other than those covered in this document, may specify different values for these constants. Section 1.4 "Applicability" ... Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the constants listed in Section 1.3. [delete the a/b/c/d list] Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:41:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13011 for ; Fri, 7 May 2004 01:41:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 110AF91234; Fri, 7 May 2004 01:40:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4DE091236; Fri, 7 May 2004 01:40:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0363391234 for ; Fri, 7 May 2004 01:40:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E12C65908F; Fri, 7 May 2004 01:40:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 7022D59059 for ; Fri, 7 May 2004 01:40:56 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475eta7004604 for ; Thu, 6 May 2004 22:40:55 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:40:55 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i475erW9021996 for ; Thu, 6 May 2004 22:40:54 -0700 (PDT) Message-Id: <200405070540.i475erW9021996@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong Date: Thu, 6 May 2004 22:40:58 -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 >We seek the unequivocal prevention of IPv4 LL addressses use off-link >not to reduction of the risk of their accidental use off-link. > The problem is the word 'prevent' for you means 'absolutely prevent' > where others have not found this to be the case. Merriam Webster > a) to deprive of power or hoep of acting or succeeding > b) to keep from happening or existing > c) to hold or keep back: HINDER, STOP Erik, you say that (a) you want to use the word 'prevent' because you seek absolute prohibition on IPv4 LL addresses leaving the link, and then you say that (b) the word 'prevent' DOES NOT mean "absolute prohibition"; it only means something milder, like "hinder". This is self-contradictory. To my original point: When you say, "In order to A you should B," that implies that doing B will result in A. In this case, that is untrue, which is why I suggest the following: Implementers should take every possible precaution to prevent IPv4 Link-Local addresses being communicated off the local link. To that end, the precautions listed below, and others as appropriate, should be followed: ... Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:47:25 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13272 for ; Fri, 7 May 2004 01:47:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6878B91236; Fri, 7 May 2004 01:47:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C2F491237; Fri, 7 May 2004 01:47:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17D4391236 for ; Fri, 7 May 2004 01:47:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E62C359029; Fri, 7 May 2004 01:47:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id A599558F60 for ; Fri, 7 May 2004 01:47:15 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475lFV4005055 for ; Thu, 6 May 2004 22:47:15 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:47:14 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i475kvdg011950 for ; Thu, 6 May 2004 22:46:58 -0700 (PDT) Message-Id: <200405070546.i475kvdg011950@relay4.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong Date: Thu, 6 May 2004 22:47:02 -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 IP address of my printer is 169.254.207.63. > | > | There, I just used a Link-Local address in off-link communication. > >No, you didn't use the address, you just typed it, the address >wasn't used (not as an address anyway). Robert, please re-read the section in question. It is not talking about addresses used "as addresses", it is talking about a prohibition on addresses appearing as data within the IP payload of other packets that DO go off-link, such as DNS packets. The word "use" in this context means "place it in a packet that goes off-link". Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:47:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13306 for ; Fri, 7 May 2004 01:47:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44F1091237; Fri, 7 May 2004 01:47:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14AC0912E9; Fri, 7 May 2004 01:47:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 650FD91237 for ; Fri, 7 May 2004 01:47:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5089859015; Fri, 7 May 2004 01:47:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id E638859023 for ; Fri, 7 May 2004 01:47:26 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475lQ0u005073 for ; Thu, 6 May 2004 22:47:26 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:47:26 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay1.apple.com (8.12.11/8.12.11) with SMTP id i475lOmA012713 for ; Thu, 6 May 2004 22:47:25 -0700 (PDT) Message-Id: <200405070547.i475lOmA012713@relay1.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL56] Contradictory text? Date: Thu, 6 May 2004 22:47:29 -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 >Requested Change: > >TEXT NEEDED Replace IPv4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded, they SHOULD only be sent when a Link-Local address is used as the source address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply. with IPv4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded to destinations outside the local link. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:49:50 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13386 for ; Fri, 7 May 2004 01:49:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1546E912E9; Fri, 7 May 2004 01:49:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D48F5912EA; Fri, 7 May 2004 01:49:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E210E912E9 for ; Fri, 7 May 2004 01:49:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C459E5906E; Fri, 7 May 2004 01:49:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 8539259063 for ; Fri, 7 May 2004 01:49:41 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475nfwt005294 for ; Thu, 6 May 2004 22:49:41 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:49:41 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i475nOfZ001052 for ; Thu, 6 May 2004 22:49:24 -0700 (PDT) Message-Id: <200405070549.i475nOfZ001052@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL58] Duplicate inconsistent routable address definition Date: Thu, 6 May 2004 22:49: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 >Requested Change: > >From > >1.9. When to configure a Link-Local IPv4 address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a valid routable address and a > Link-Local IPv4 address configured on the same interface. > > A routable address is any address that is: > > * a unicast address (see Section 1.2) > * not a loopback address > * not contained within the 169.254/16 prefix reserved for Link-Local > IPv4 addresses > >To > >1.9. When to configure an IPv4 Link-Local address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a valid routable address and an > IPv4 Link-Local address configured on the same interface. Also, "Terminology" needs to be updated to incorporate the "not a loopback address" restriction. Replace This document uses the term "routable address" to refer to all unicast IPv4 addresses outside the 169.254/16 prefix, including global addresses and private addresses such as Net 10/8 [RFC1918], all of which may be forwarded via routers. with This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1 Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:51:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13512 for ; Fri, 7 May 2004 01:51:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E870912EA; Fri, 7 May 2004 01:50:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DB2F912EF; Fri, 7 May 2004 01:50:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78B53912EA for ; Fri, 7 May 2004 01:50:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 628E45907B; Fri, 7 May 2004 01:50:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 23BF759071 for ; Fri, 7 May 2004 01:50:50 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475onOt005381 for ; Thu, 6 May 2004 22:50:49 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:50:49 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i475olpZ001550 for ; Thu, 6 May 2004 22:50:48 -0700 (PDT) Message-Id: <200405070550.i475olpZ001550@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL59] Wireless comment not needed Date: Thu, 6 May 2004 22:50:52 -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 do not agree with the suggested change. The sentence is harmless and >satisfies a requirement from the IESG. > >- Ralph All I've heard from anyone to defend this is "someone else wanted it". If no one in this WG can explain what it means, then how is a new reader to make sense of it? The best I can piece together is this: Russ Housley said "An entry in the list that does not imply an infrastructure of any kind is desirable." (Whatever that means.) The proposed remedy was a double negative: "This example does not imply that IPv4LL configuration is inapplicable to wireless interfaces." Philip Nye wrote, sensibly: >Personally, I don't think any of these changes are necessary - this >clearly appears in an "examples include" section and the next line >mentions wireless networking. The inexplicable parenthetical comment was then added to the document. That logic seems weak to me. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:52:15 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13603 for ; Fri, 7 May 2004 01:52:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0E20912F0; Fri, 7 May 2004 01:52:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC0F7912F2; Fri, 7 May 2004 01:52:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5011912F0 for ; Fri, 7 May 2004 01:52:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B30F95909A; Fri, 7 May 2004 01:52:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 71D2759099 for ; Fri, 7 May 2004 01:52:06 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475q6C4005474 for ; Thu, 6 May 2004 22:52:06 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:52:05 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay1.apple.com (8.12.11/8.12.11) with SMTP id i475q4DX014218 for ; Thu, 6 May 2004 22:52:04 -0700 (PDT) Message-Id: <200405070552.i475q4DX014218@relay1.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL60] Forward reference style Date: Thu, 6 May 2004 22:52: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 >While it's not a big deal, the statement "This is standard practice in all >RFCs that include constants" can be disproven by counterexample; RFC 3315 >defines all of the symbolic constants in an early section before any of >those constants are referenced in the specification. > >I suggest simply moving section 9 so that it appears before any of the >defined symbolic constants are first referenced. Thank you Ralph. Hopefully my proposed changes for LL53 address this. Robert Elz wrote: >RFCs are for implementors, not for people learning. Implementors, if >not necessarily experts, should at least be competent. If someone wants >to publish a book "IPv4 link local addresses for morons" (or whatever) >then they can do it in a way which manes it easy for beginners to >learn the protocol. The RFC doesn't need to do that. I cannot fathom this point of view. The first time someone reads any document, including an RFC, they're learning what the document says. What possible reason would we have to NOT make an RFC as clear and understandable as possible? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:53:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13729 for ; Fri, 7 May 2004 01:53:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49F7D912EF; Fri, 7 May 2004 01:53:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 192CE912F2; Fri, 7 May 2004 01:53:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 36364912EF for ; Fri, 7 May 2004 01:53:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21EE159083; Fri, 7 May 2004 01:53:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id A6B005907B for ; Fri, 7 May 2004 01:53:17 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475rH1V005562 for ; Thu, 6 May 2004 22:53:17 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:53:17 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i475rFqU014199 for ; Thu, 6 May 2004 22:53:15 -0700 (PDT) Message-Id: <200405070553.i475rFqU014199@relay4.apple.com> Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Date: Thu, 6 May 2004 22:53:19 -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 believe it should have been random initial delay + retransmissions >spaced 1 seconds apart, rather than what somehow came out in the >document. > > MikaL A long time ago, draft-07 said: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to two seconds, and should then send four probe packets, spaced two seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. With our new parametrized text, this becomes: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to START_WAIT seconds, and should then send PROBE_NUM probe packets, spaced PROBE_INTERVAL seconds apart. This initial randomized delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. I believe this is perfectly adequate. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:55:03 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13880 for ; Fri, 7 May 2004 01:55:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B002912F2; Fri, 7 May 2004 01:54:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A3D6912F4; Fri, 7 May 2004 01:54:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C971912F2 for ; Fri, 7 May 2004 01:54:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4799D59089; Fri, 7 May 2004 01:54:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id CEC2D59081 for ; Fri, 7 May 2004 01:54:54 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475ssOF005649 for ; Thu, 6 May 2004 22:54:54 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id ; Thu, 6 May 2004 22:54:54 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i475sqoE026936; Thu, 6 May 2004 22:54:52 -0700 (PDT) Message-Id: <200405070554.i475sqoE026936@relay3.apple.com> Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Thu, 6 May 2004 22:54:56 -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 really important part is the initial randomization. It is then >important that each successive trial be space by a sufficient delay. But >it is also important to randomize the second delay to avoid "persistent >bad luck", i.e. the situation where N hosts pick the same initial delay >and then all repeat all of their NUM_PROBE packets at the same time. >Since you need to have a random number generation ready in any case the >implementation overhead is negligible, so why not do the right thing? Right: The really important part is the initial randomization. That's been in since draft-05. There are many problems with adding successive random intervals to this -- misconceptions about the nature of "collisions", added implementation cost, lower behavioural predictability, which translates into additional burdens at layers above and below, but the biggest problem may be this: The sum of random variables is LESS random than the individual variables. Ask any statistician, or do a Google search for "central limit theorem" or "strong law of large numbers". Here's a simple example that should be familiar to everyone: If you throw one die, the numbers 1,2,3,4,5,6 are all equally likely. If you throw two dice, and add up the results, then 7 is the most likely outcome. You are SIX TIMES more likely to get 7 than either 2 or 12. When you take two uniform (flat) random distributions and add them together, you get a distribution that is sharply spiked in the middle. Add three or four, and it gets even worse. A single uniformly distributed random delay, followed by intervals that are fixed, not random, avoids this collapse around a central spike: For n hosts powered on simultaneously that become ready to probe simultaneously, the probability that a probe packet will be transmitted (by any host) in the first millisecond is n/1000. The probability that a probe packet will be transmitted during the second millisecond is also n/1000. The probability that a probe packet will be transmitted during any given millisecond within the first second is n/1000. The probability that a probe packet will be transmitted during any given millisecond within the second or third seconds is also n/1000. The probability density function looks like this: p| | | | ---------------- | | | | | | | | | |----|----|----|----|----|----| -1 0 1 2 3 4 time (seconds) In terms of minimizing peak demand on the Ethernet switch, or wireless spectrum, or whatever resource we are trying to protect, there is no better distribution than a completely flat one. The moment you start summing uniform random distributions, you get a pointy distribution with a peak of exaggerated busyness in the middle. If we want to avoid overflowing the buffers in the Ethernet switch, a sharp burst of traffic is the worst thing to do. A steady uniformly distributed stream of traffic with no sudden peaks is what's least likely to cause loss. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:56:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14073 for ; Fri, 7 May 2004 01:56:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F768912F4; Fri, 7 May 2004 01:56:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E100F912F6; Fri, 7 May 2004 01:56:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 780F8912F4 for ; Fri, 7 May 2004 01:56:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50FC1590A5; Fri, 7 May 2004 01:56:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id EC286590A2 for ; Fri, 7 May 2004 01:55:59 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475tx1U005762 for ; Thu, 6 May 2004 22:55:59 -0700 (PDT) Received: from relay1.apple.com (relay1.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:55:59 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay1.apple.com (8.12.11/8.12.11) with SMTP id i475tvX2015302 for ; Thu, 6 May 2004 22:55:58 -0700 (PDT) Message-Id: <200405070555.i475tvX2015302@relay1.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Thu, 6 May 2004 22:56:02 -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 >Requested Change: > >TEXT NEEDED Replace A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. Several early implementations of IPv4 Link-Local have modified the DHCP state machine in an attempt to make IPv4 Link-Local more reliable, and the field experience we have gained from this has shown that it does not work - reliability of DHCP service is significantly reduced. If increased reliability of IPv4 Link-Local is desired, we recommend that the IPv4 Link-Local state machine track the DHCP client state machine and, in cases where it is not certain that the DHCP-assigned address is correct, the IPv4 Link-Local state machine acquire an IPv4 Link-Local address without causing the DHCP state machine to relinquish its address. Further discussion of this issue is provided in [DNAv4]. with just A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:57:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14200 for ; Fri, 7 May 2004 01:57:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22024912F5; Fri, 7 May 2004 01:57:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5558912F6; Fri, 7 May 2004 01:57:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0271C912F5 for ; Fri, 7 May 2004 01:57:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1ED659098; Fri, 7 May 2004 01:57:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id A3C745908F for ; Fri, 7 May 2004 01:57:25 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i475vdDX020023 for ; Thu, 6 May 2004 22:57:39 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:57:25 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i475vNPD027685 for ; Thu, 6 May 2004 22:57:23 -0700 (PDT) Message-Id: <200405070557.i475vNPD027685@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL65] Need a requirement for multihomed hosts Date: Thu, 6 May 2004 22:57:27 -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 My point was this. The document *already* says: > If a host has two interfaces on the same network, then claiming and > defending on those interfaces must ensure that they end up with > different addresses just as if they were on different hosts. If we say they "must ensure that they end up with different addresses" via the usual claiming and defending process, then why not just take the next logical step and say they must not try to claim the same address on two interfaces in the first place? Why try something that you know is supposed to fail? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 01:58:44 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14299 for ; Fri, 7 May 2004 01:58:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0EA6912F6; Fri, 7 May 2004 01:58:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99FE5912F8; Fri, 7 May 2004 01:58:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A68A912F6 for ; Fri, 7 May 2004 01:58:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74D85590A2; Fri, 7 May 2004 01:58:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 097D35909E for ; Fri, 7 May 2004 01:58:36 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i475wZ5q005875 for ; Thu, 6 May 2004 22:58:35 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 22:58:35 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i475wXCO016172 for ; Thu, 6 May 2004 22:58:33 -0700 (PDT) Message-Id: <200405070558.i475wXCO016172@relay4.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL66] Additional statistical example Date: Thu, 6 May 2004 22:58:37 -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 >Stuart - for my own understanding, can you explain the computation you made >for your statistical example? > >- Ralph Answering your question, I noticed I had a typo in the email I sent to Erik. I meant "better than 85% chance", not 75%. When we join one network onto another, we can model this as a network with 100 hosts on it (the "existing hosts"), and 100 new hosts joining that network (the "new hosts"), with the additional constraint that the 100 new hosts are already known not to conflict with each other. What is the probability that this entire merge completes without a single conflict? Notation: p(sn) is the probability that new host n joins without conflict. p(Sn) is the cumulative probability that n new hosts join without conflict. p(sn|S(n-1)) is the probability that new host n joins without conflict, given that the previous hosts all joined without conflict. p(S100) is the probability that the merge completes without conflict. By induction p(Sn) = p(sn|S(n-1)) * p(S(n-1)) [Probability of event Sn is probability of event sn, given event S(n-1), times probability of event S(n-1)] so p(S100) = p(s100|S99) * p(S99) [The probability of complete success (p(S100)) is the probability that host 100 will join without conflict, given that the 99 previous ones also joined without conflict, times the probability that the 99 previous ones also joined without conflict.] and p(S0) = 1 [Base case: There can be no conflict when no hosts have joined.] Therefore, what we want to calculate is the product of p(s1|S0) ... p(s100|S99) What is p(s1|S0)? The network has 65024 possible addresses. 100 are in use, so 64924 addresses are available. New host 1 could have any of the 65024 possible addresses. The 64924 of these that are free yield success; the 100 that are in use yield failure. p(s1) = 64924/65024 = 99.85% chance of finding a free address. p(S1) = p(s1|S0) * p(S0) = 0.9985 * 1 = 0.9985. What is p(s2|S1)? We now know, given event S1, that the address of new host 1 is not in use by another host, on existing or new. That means that there are 65023 possible other addresses that could be used by existing hosts and by new host 2. The probability that new host 2 does not conflict with any existing host, given that host 1 did not, is 64923/65023. In general, p(s(n+1)|Sn) = (64924-n)/(65024-n) For n in the range [0,99], this value ranges from 99.8462% to 99.8460% probability of success for each host, and the cumulative product of these values is 85.7250% chance of complete success. C code is below: #include int main(int argc, char **argv) { double p = 1.0; double existinghosts = 100.0; double newhosts = 0.0; int i; for (i=1; i<=100; i++) { double range = (256.0 * 254.0) - newhosts; double psuccess = (range - existinghosts) / range; p *= psuccess; newhosts += 1.0; printf("host %3d; newhosts %3.0f; psuccess = %f; p = %f\n", i, newhosts, psuccess, p); } } Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 02:00:46 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15107 for ; Fri, 7 May 2004 02:00:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B2CE912F8; Fri, 7 May 2004 02:00:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E128912F9; Fri, 7 May 2004 02:00:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 121B7912F8 for ; Fri, 7 May 2004 02:00:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A8D758F60; Fri, 7 May 2004 02:00:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 3138658FC6 for ; Fri, 7 May 2004 02:00:11 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i4760PFZ020190 for ; Thu, 6 May 2004 23:00:25 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 23:00:10 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i47608FP004116 for ; Thu, 6 May 2004 23:00:09 -0700 (PDT) Message-Id: <200405070600.i47608FP004116@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable Date: Thu, 6 May 2004 23:00:12 -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 >Requested Change: > >TEXT NEEDED Hopefully my proposed changes for LL53 address this. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 02:01:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15997 for ; Fri, 7 May 2004 02:01:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D5C9912FC; Fri, 7 May 2004 02:01:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCA5A912FB; Fri, 7 May 2004 02:01:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD8B1912FD for ; Fri, 7 May 2004 02:01:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A32858FE8; Fri, 7 May 2004 02:01:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 5B59B58FDB for ; Fri, 7 May 2004 02:01:16 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i4761U2q020365 for ; Thu, 6 May 2004 23:01:30 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Thu, 6 May 2004 23:01:15 -0700 Received: from [17.219.205.19] ([17.219.205.19]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i4760w9L016583 for ; Thu, 6 May 2004 23:00:59 -0700 (PDT) Message-Id: <200405070600.i4760w9L016583@relay4.apple.com> Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Thu, 6 May 2004 23:01:02 -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 >BTW, are we assuming the link layer takes care of collisions or should >there be some explicit provision for retransmitting if one of the probes >suffers a collision? The reason for having three probes is to mitigate the effects of undetected loss. Most links like 802.11 and 802.3 have some low-level loss detection to mask some (but not all) losses. If the link could guarantee to report or recover from *all* losses, there wouldn't be any undetected loss, so one probe would be enough. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 05:34:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10374 for ; Fri, 7 May 2004 05:34:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 04992912FD; Fri, 7 May 2004 05:34:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1CC1912FE; Fri, 7 May 2004 05:34:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0AAC912FD for ; Fri, 7 May 2004 05:34:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B872A58DAA; Fri, 7 May 2004 05:34:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 36D195907E for ; Fri, 7 May 2004 05:34:36 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 3E9FB1BB423; Fri, 7 May 2004 10:34:36 +0100 (BST) Message-ID: <00f401c43416$82b56f70$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405070554.i475sqoE026936@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 09:34:35 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Stuart Cheshire" >=20 > ...but the biggest problem may be this: >=20 > The sum of random variables is LESS random than the individual = variables. >=20 > Ask any statistician, or do a Google search for "central limit = theorem"=20 > or "strong law of large numbers". >=20 > Here's a simple example that should be familiar to everyone: >=20 > If you throw one die, the numbers 1,2,3,4,5,6 are all equally likely. >=20 > If you throw two dice, and add up the results, then 7 is the most = likely=20 > outcome. You are SIX TIMES more likely to get 7 than either 2 or 12. Stuart, This is a completely spurious statistical argument I'm afraid. If you = want to use the dice example - here is the scenario: You an I both generate a series of 4 numbers. The first value is = generated by throwing a single die. case A. Each subsequent value is generated by adding 4, 3 and 4 = respectively to the preceeding value. case B. Each subsequent value is generated by throwing the die again and = adding that value to the preceeding value. Now the probability that you are talking about is that you and I agree = on AT LEAST ONE value in our series which does increase in case B. It is = 1/6 for A and approximately 0.52 for B. However that is irrelevant, the chance we need to avoid is that you and = I both agree on ALL FOUR values in our series. For A this probability is = 1/6 while for B it is 1/(6^4) =3D 1/1296. Returning to the computer algorithm, given the fact that in many = implementations a "random" delay is likely to be quantised to the = inherent tick frequency of the operating system, then the probability of = an initial delay in the range 0..1 second being the same for two hosts = is not very low (1/100 for a typical OS and as big as 1/20 for some). = Making subsequent delays also random drastically increases the chances = that at least some of the probes will not clash. What is the reason for sending four probes? In the case of only the = initial delay being randomised, the extra ones merely guard against the = possibility that probes may be dropped or lost. In the case of = consecutive random delays this still applies but they have the added = benefit of reducing the chances of all probes being lost because of = timing clashes. In conclusion. I agree with Christian that the initial wait should be in = the range 0..(PROBE_MAX - PROBE_MIN) which is different from the current = draft. I also agree with him that the subsequent delays should be = randomised exactly as in the current draft. Philip From owner-zeroconf@merit.edu Fri May 7 05:53:42 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11584 for ; Fri, 7 May 2004 05:53:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A362B912FF; Fri, 7 May 2004 05:53:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7079091300; Fri, 7 May 2004 05:53:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D175912FF for ; Fri, 7 May 2004 05:53:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 590C35906E; Fri, 7 May 2004 05:53:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by segue.merit.edu (Postfix) with ESMTP id 224B959059 for ; Fri, 7 May 2004 05:53:35 -0400 (EDT) Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 07 May 2004 02:56:07 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i479rVpI021406; Fri, 7 May 2004 05:53:32 -0400 (EDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-2-4.cisco.com [10.86.242.4]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF42439; Fri, 7 May 2004 05:53:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20040507055028.00c8c2a8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 May 2004 05:52:45 -0400 To: Stuart Cheshire From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL52] Text surrounding RFC 2119 clause is poor Cc: In-Reply-To: <200405070534.i475YeO0026250@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk As I suggested earlier, we should follow the recommendation of RFC 2119: Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. - Ralph At 10:34 PM 5/6/2004 -0700, Stuart Cheshire wrote: > >Requested Change: > > > >Omit the unnecessary text before "The key words ..." > > > >Was: > >1.1. Requirements > > > > In this document, several words are used to signify the requirements > > of the specification. These words are often capitalized. The key > > words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document > > are to be interpreted as described in [RFC2119]. > > > >Becomes: > >1.1. Requirements > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", i > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > >Actually, specifically what I'd like is that we just put it back exactly >how it was in earlier drafts: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in "Key words for use in > RFCs to Indicate Requirement Levels" [RFC 2119]. > > >Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 05:56:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11753 for ; Fri, 7 May 2004 05:56:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E59B91300; Fri, 7 May 2004 05:56:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2172E91301; Fri, 7 May 2004 05:56:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3689D91300 for ; Fri, 7 May 2004 05:56:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1ED6A5904F; Fri, 7 May 2004 05:56:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id D586D59081 for ; Fri, 7 May 2004 05:56:28 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 4618A1BB3EB; Fri, 7 May 2004 10:56:29 +0100 (BST) Message-ID: <00fa01c43419$914f8130$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405070557.i475vNPD027685@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL65] Need a requirement for multihomed hosts Date: Fri, 7 May 2004 09:56:28 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Stuart Cheshire" > My point was this. The document *already* says: >=20 > > If a host has two interfaces on the same network, then claiming = and > > defending on those interfaces must ensure that they end up with > > different addresses just as if they were on different hosts. >=20 > If we say they "must ensure that they end up with different addresses" = > via the usual claiming and defending process, then why not just take = the=20 > next logical step and say they must not try to claim the same address = on=20 > two interfaces in the first place? We only say they must end up with different addresses "If a host has two = interfaces on the same network". We also suggest that the best thing is to run the algorithm = independently on each interface and if this is done then the requirement = will be met as a consequence of defending one interface against the = other and the algorithm need not be explicitly aware of whether they are = on a common network or not. The document talks about the difficulty of trying to run zeroconf on = multiple interfaces and in some systems avoiding the same address on = multiple interfaces may help reduce the problems - but does not resolve = them all. However, in other systems (e.g. where the interface to use is = explicitly specified - by some other means than by IP address) then = there is not necessarily any problem with using the same address = provided those interfaces are on separate networks. Fully independent = running of the algorithm may occasionally end up this way without the = system ever noticing. I do not support the proposed change. We should stick to the existing = text - maybe change "must" to "MUST" Philip From owner-zeroconf@merit.edu Fri May 7 06:40:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14436 for ; Fri, 7 May 2004 06:40:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6626F91301; Fri, 7 May 2004 06:40:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3948191302; Fri, 7 May 2004 06:40:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5069491301 for ; Fri, 7 May 2004 06:40:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39E3B590A0; Fri, 7 May 2004 06:40:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id E84FC5909A for ; Fri, 7 May 2004 06:40:02 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id B32FC1BB453; Fri, 7 May 2004 11:40:03 +0100 (BST) Message-ID: <013001c4341f$a79a14e0$131010ac@aldebaran> From: "Philip Nye" To: "Ralph Droms" , "Zeroconf Working Group" References: <4.3.2.7.2.20040507055028.00c8c2a8@flask.cisco.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL52] Text surrounding RFC 2119 clause is poor Date: Fri, 7 May 2004 10:40:03 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Ralph Droms" > > As I suggested earlier, we should follow the recommendation of RFC = 2119: >=20 > Authors who follow these guidelines > should incorporate this phrase near the beginning of their = document: >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described = in > RFC 2119. We have the recommended text verbatim from RFC2119. We also have two introductory sentences: "In this document, several = words are used to signify the requirements of the specification. These = words are often capitalized." The two extra sentences are also lifted directly from RFC2119 and as = such it is hard to argue against them. They may be redundant, but they = are not harmful and it should be too late to change them. Philip From owner-zeroconf@merit.edu Fri May 7 06:53:53 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15089 for ; Fri, 7 May 2004 06:53:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 91C2191304; Fri, 7 May 2004 06:53:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58B6191305; Fri, 7 May 2004 06:53:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EC7491304 for ; Fri, 7 May 2004 06:53:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18ACE5908C; Fri, 7 May 2004 06:53:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 16C1E59085 for ; Fri, 7 May 2004 06:53:45 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id C75F51BB48E; Fri, 7 May 2004 11:53:45 +0100 (BST) Message-ID: <013901c43421$91985060$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL56] Contradictory text? Date: Fri, 7 May 2004 10:53:45 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I support Erik's analysis. The special case of having a routable address but only a locally = resolvable name and particularly if there is some knowledge that the = name will not be used off-link is sufficient justification for an = implementer to reject the "SHOULD" and is why this is not "MUST". Finally, I don't think this is a deal breaker and it should be too late = to make a change. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 10:59 PM Subject: WG ACTION: 2 weeks to discuss [LL56] Contradictory text? > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [LL56] >=20 > Description of Issue: Contradictory text? > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: S > Section: 1.4, 1.8 > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > > IPv4 addresses ... > > ... which can only be resolved on the local link ... > > ... SHOULD only be sent when a Link-Local address > > is used as the source address. >=20 > Sent how? In the header? In the payload? Doesn't this contradict the = text > later in the document that says: >=20 > > There will be cases when devices with a configured Link-Local = address > > will need to communicate with a device with a routable address > > configured on the same physical link, and vice versa. The rules = in > > Section 2.6 allow this communication. >=20 > This says that link-local addresses *can* be used when the source = address > is *not* link-local. >=20 > [Erik] >=20 > The IPv4 address would be sent in the LLMNR (DNS) payload. I though > that was obvious due the the context in the paragraph. >=20 > The first paragraph refers to text in section 1.4.b which discuss > limitations of the use of IPv4 LL when used with LLMNR. The second > paragraph is in section 1.8 which discusses general communication > between two hosts. In the latter case, the text is definitely > appropriate. >=20 > I believe there is no contradiction. 1.4.b does not hinder the use of > LLMNR or IPv4 LL configuration except in one case: A host implementor > is admonished (using SHOULD) to only hand out a LL address using LLMNR > when the host has a LL configuration and only from an interface which = in > fact has been configured with an LL adddress. >=20 > [Stuart] >=20 > I disagee. >=20 > As stated, a device with a routable address, and a link-local-scope = name > of some kind, is prohibited from answering queries for that name, = because > the name can only be resolved on the local link, but the device = doesn't > have a Link-Local address to use as the source IP address. >=20 > [Erik] >=20 > The full quote is: >=20 > IPv4 addresses and names which can only be resolved on the = local > link SHOULD NOT be forwarded, they SHOULD only be sent when a > Link-Local address is used as the source address. This strong > advice should hinder limited scope addresses and names from > leaving the context in which they apply. >=20 > There is no prohibition. There is only a 'SHOULD' implying that > this is not a great idea. The issue of 'leaving the context ni > which they apply' is not very serious *today* since LLMNR has = only > LL scope. In the future, LLMNR might be admin scope MNR. In = this > case, we will need the SHOULD above - so that link-local scope > identifiers (addresses and names) are properly contained. >=20 > Requested Change: >=20 > TEXT NEEDED > From owner-zeroconf@merit.edu Fri May 7 07:02:26 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15401 for ; Fri, 7 May 2004 07:02:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 342CA91305; Fri, 7 May 2004 07:02:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF47E91306; Fri, 7 May 2004 07:02:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D19AA91305 for ; Fri, 7 May 2004 07:02:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BF5CA58FC6; Fri, 7 May 2004 07:02:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 4D3AC58C4B for ; Fri, 7 May 2004 07:02:19 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 08F4E1BB402; Fri, 7 May 2004 12:02:20 +0100 (BST) Message-ID: <015b01c43422$c41501e0$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL53] Forward references requested Date: Fri, 7 May 2004 11:02:19 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I'm neutral about the proposed change. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:00 PM Subject: WG ACTION: 2 weeks to discuss [LL53] Forward references = requested > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [LL53] >=20 > Description of Issue: Forward references requested > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: e > Prio ['S' Must|1 should|2 may]: 1 > Section: 1.3 > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > > Link-layer technologies that support ARP but operate at rates = below 1 > > Mbps or latencies above one second may need to specify different > > values for the following parameters described in Sections 2.2, = 2.3 > > and 2.4: > > > > (a) the number of, and interval between, ARP probes, > > (b) the number of, and interval between, ARP announcements, > > (c) the maximum rate at which address claiming may be attempted, = and > > (d) the time interval between conflicting ARPs below which a host > > MUST reconfigure instead of attempting to defend its address. >=20 > Aren't these all now parametrized in Section 9? >=20 > [Erik] >=20 > Yes, they are parameterized there. However, the text here describes > what we are doing and why. >=20 > [Stuart] >=20 > Does "the number of, and interval between, ARP probes" refer to > PROBE_MIN, PROBE_MAX, PROBE_N, or NUM_PROBES? Why not just make it = clear? >=20 > [Erik] >=20 > Which of the following versions do you prefer? > See=20 > = http://www.drizzle.org/~aboba/ZEROCONF/draft-ietf-zeroconf-ipv4-linklocal= -15.txt=20 >=20 > in order to make sense of the 'Section references' >=20 > A >=20 > Link-layer technologies that support ARP but operate at rates = below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters described in Sections 2.2.1, = 2.4 > and 2.5: >=20 > (a) the number of, and interval between, ARP probes, > (b) the number of, and interval between, ARP announcements, > (c) the maximum rate at which address claiming may be attempted, = and > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address. >=20 > B >=20 > Link-layer technologies that support ARP but operate at rates = below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters. >=20 > (a) the number of, and interval between, ARP probes > See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 >=20 > (b) the number of, and interval between, ARP announcements, > See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 >=20 > (c) the maximum rate at which address claiming may be attempted > See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section = 2.2.1 >=20 > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address > See WATCH_WAIT defined in section 2.5 >=20 > Personally I slightly prefer A. If you have an alternative > proposal, please send text. >=20 > Requested Change: >=20 > Sec. 3.1 from >=20 > Link-layer technologies that support ARP but operate at rates = below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters described in Sections 2.2, 2.3 > and 2.4: >=20 > (a) the number of, and interval between, ARP probes, > (b) the number of, and interval between, ARP announcements, > (c) the maximum rate at which address claiming may be attempted, = and > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address. >=20 >=20 > to >=20 > Link-layer technologies that support ARP but operate at rates = below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters. >=20 > (a) the number of, and interval between, ARP probes > See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 >=20 > (b) the number of, and interval between, ARP announcements, > See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 >=20 > (c) the maximum rate at which address claiming may be attempted > See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section = 2.2.1 >=20 > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address > See WATCH_WAIT defined in section 2.5 >=20 > From owner-zeroconf@merit.edu Fri May 7 07:06:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15517 for ; Fri, 7 May 2004 07:06:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8810591306; Fri, 7 May 2004 07:05:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5713E91307; Fri, 7 May 2004 07:05:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7653391306 for ; Fri, 7 May 2004 07:05:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6042859077; Fri, 7 May 2004 07:05:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 30A865906F for ; Fri, 7 May 2004 07:05:57 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 2DBA41BB3C1; Fri, 7 May 2004 12:05:58 +0100 (BST) Message-ID: <016a01c43423$46197630$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL54] Consistent terminology for out of scope Date: Fri, 7 May 2004 11:05:57 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Lets be consistent. Can we pick one phrase? Either "outside the scope = of > this document" or "left to a future document". I really don't care which phrase we use, nor do I mind using both in = different places, but it is way too late to make trivial changes like = this. Philip From owner-zeroconf@merit.edu Fri May 7 07:09:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15600 for ; Fri, 7 May 2004 07:09:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CAA691307; Fri, 7 May 2004 07:09:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39A5A91308; Fri, 7 May 2004 07:09:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52E1A91307 for ; Fri, 7 May 2004 07:09:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3829D5907B; Fri, 7 May 2004 07:09:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 90DCF59077 for ; Fri, 7 May 2004 07:09:25 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 60E2F1BB4F9; Fri, 7 May 2004 12:09:26 +0100 (BST) Message-ID: <017901c43423$c23242b0$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong Date: Fri, 7 May 2004 11:09:25 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > In order to prevent use of IPv4 Link-Local addresses in off-link > > communication, the following cautionary measures are advised: >=20 > to >=20 > > In order to reduce the risk of accidental use of IPv4 Link-Local > > addresses in off-link communication, the following cautionary > > measures are advised: This is very clearly advisory stuff. I really don't care which phrase we = use but it is way too late to make trivial changes like this. Philip From owner-zeroconf@merit.edu Fri May 7 07:21:51 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15985 for ; Fri, 7 May 2004 07:21:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7822591308; Fri, 7 May 2004 07:21:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 431D291309; Fri, 7 May 2004 07:21:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1327991308 for ; Fri, 7 May 2004 07:21:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F15D558FD4; Fri, 7 May 2004 07:21:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id 95CF558FB8 for ; Fri, 7 May 2004 07:21:36 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i479LWg07914; Fri, 7 May 2004 02:21:32 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i47BLWi02866; Fri, 7 May 2004 04:21:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL53] Forward references requested Date: Fri, 7 May 2004 04:21:32 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C6EBEE2@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL53] Forward references requested Thread-Index: AcQz9aLqYuwrgGUcTD2pKtwcL3VDvwALt8SQ From: "Elder, Alex" To: "Stuart Cheshire" , Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I have no objection to the suggestion to move the parameters definition to the front of the document. Even if it is left in section 9, I think Stuart has done a fine job with his proposed text. It addresses all of my original concerns about parameterization and probing intervals. One minor exception, I think the sentence that begins, "An important part of creating interoperable products..." is a bit preachy. -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Stuart Cheshire > Sent: Friday, May 07, 2004 12:39 AM > To: zeroconf@merit.edu > Subject: Re: WG ACTION: 2 weeks to discuss [LL53] Forward references > requested >=20 >=20 > > Personally I slightly prefer A. If you have an alternative > > proposal, please send text. >=20 > What I suggest is: >=20 > 1. List the constants, with a brief explanation, and give the=20 > value. The=20 > brief explanation doesn't have to duplicate the full=20 > explanation which=20 > appears later -- just enough to demystify an otherwise opaque name. >=20 > 2. State the technologies that may use other values. >=20 > e.g. >=20 > Section 1.3 "Constants" >=20 > The following constants are defined here and referenced later in > this document. >=20 > START_WAIT 1 second (initial random delay) > PROBE_NUM 3 (number of probe packets) > PROBE_INTERVAL 1 second (time between probe packets) > ANNOUNCE_NUM 2 (number of announcement packets) > ANNOUNCE_INTERVAL 2 seconds (time between announcement packets) > RATE_LIMIT_NUM 10 (max collisions before=20 > rate limiting) > RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) > DEFEND_INTERVAL 10 seconds (minimum time between=20 > defensive ARPs) >=20 > These values are fixed for all implementations conforming to this > standard. They MUST NOT be end-user configurable options,=20 > nor should > the listing of the values here be taken to imply that each > implementer is free to substitute other values instead,=20 > based on what > they think will suit each device best. An important part=20 > of creating > interoperable products is being able to depend on predictable > behaviour from the other products you're interoperating with, and > having arbitrary variation between different implementations would > significantly undermine that ability. >=20 > Future standards documents, extending IPv4 Link-Local Addressing to > media types other than those covered in this document, may specify > different values for these constants. >=20 > Section 1.4 "Applicability" >=20 > ... >=20 > Link-layer technologies that support ARP but operate at=20 > rates below 1 > Mbps or latencies above one second may need to specify different > values for the constants listed in Section 1.3. >=20 > [delete the a/b/c/d list] >=20 > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org >=20 >=20 From owner-zeroconf@merit.edu Fri May 7 07:39:22 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16549 for ; Fri, 7 May 2004 07:39:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8544191309; Fri, 7 May 2004 07:39:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5247A9130A; Fri, 7 May 2004 07:39:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34ACE91309 for ; Fri, 7 May 2004 07:39:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21F7858EF1; Fri, 7 May 2004 07:39:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id A582E58FB8 for ; Fri, 7 May 2004 07:39:06 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 78FBC1BB4AD; Fri, 7 May 2004 12:39:07 +0100 (BST) Message-ID: <018601c43427$e7ca9a00$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes Date: Fri, 7 May 2004 11:39:06 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Comments interspersed. One or two are genuine editorial mistakes, = several appear to be pedantic filibusters! > >1.9. When to configure a IPv4 Link-Local address >=20 > Search and replace "a IP" with "an IP" [philip] I'm comfortable with either. >=20 > --- >=20 > [Stuart] >=20 > >2.4. Announcing an Address > > > > The host MUST then announce its claimed address by broadcasting > > PROBE_N ARP announcements, spaced PROBE_MAX seconds apart. >=20 > Change to: >=20 > > ANNOUNCE_N ARP announcements, spaced ANNOUNCE_INTERVAL seconds = apart >=20 > Add to section 9: >=20 > ANNOUNCE_N 2 > ANNOUNCE_INTERVAL 2 seconds [philip] The change is probably better. I believe this is more than an editorial = change since it decouples ANNOUNCE_INTERVAL from PROBE_MAX. >=20 > --- >=20 > Section 2.5 >=20 > > (b) If a host currently has active TCP connections or other = reasons > > to prefer to keep the same IPv4 address, and it has not seen any > > other conflicting ARP packets recently (for IEEE 802, within the = last > > ten seconds) then it MAY elect to attempt to defend its address >=20 > becomes >=20 > If a host currently has active TCP connections or other reasons > to prefer to keep the same IPv4 address, and it has not seen any > other conflicting ARP packets recently (for IEEE 802, within the = last > | WATCH_WAIT seconds) then it MAY elect to attempt to defend its = address, by > recording the time that the conflicting ARP packet was received, = and > then broadcasting one single ARP announcement, giving its own IP = and > hardware addresses as the sender addresses of the ARP. Having = done > this, the host can then continue to use the address normally = without > any further special action. However, if this is not the first > conflicting ARP packet the host has seen, and the time recorded = for > the previous conflicting ARP packet is recent (within WATCH_WAIT > seconds for IEEE 802) then the host MUST immediately cease using = this > address and configure a new IPv4 Link-Local address as described > above. This is necessary to ensure that two hosts do not get = stuck > in an endless loop with both hosts trying to defend the same = address. >=20 [philip] I see no need for the change. However, if we are to parameterize WATCH_WAIT as proposed we should do = it properly. The text should read: "...and it has not seen any other conflicting ARP packets within = WATCH_WAIT seconds then it MAY elect..." and in section 9: WATCH_WAIT 10 seconds for IEEE802 > --- >=20 > 2.6.2 >=20 > > Whichever interface is used, if the destination address is in the > > 169.254/16 prefix (excluding the address 169.254.255, which is = the > > broadcast address for the Link-Local prefix), then the sender = MUST >=20 > 169.254.244 >=20 > becomes >=20 > 169.254.255.255 [philip] Agreed >=20 > --- >=20 > 3.1 >=20 > > > This answer is usually answered by referring to a routing = table, > > > which expresses which interface (with which address) to send, = and how >=20 > becomes >=20 > This question is usually answered by referring to a routing table, > which expresses on which interface (with which address) to send, = and how [philip] Agree changing "answer" to "question". Neutral on adding "on" - it is a very pedantic change. >=20 > --- >=20 > from: >=20 > > >3.4. Unintentional Autoimmunity >=20 > to: >=20 > > >3.4. Unintentional Autoimmune Response [philip] This change adds nothing so don't make it. >=20 > --- >=20 > 6.1 > From: >=20 > IPv4 Link-Local addresses used by an application may change over > time. Some application software encountering an address change = will > fail. For example, client TCP connections will fail, >=20 > to: >=20 > IPv4 Link-Local addresses used by an application may change over > time. Some application software encountering an address change = will > fail. For example, existing client TCP connections will be = aborted, [philip] It's way too late to make trivial changes like this - there is no = grammatical error, the difference in meaning is minimal and it is an = example not a technical definition. >=20 > --- >=20 > 6.2 > From: >=20 > > If the FTP client transmits its passive IPv4 >=20 > to: >=20 > > If the FTP client transmits its stale out-of-date passive IPv4 [philip] It's way too late to make trivial changes like this - there is no = grammatical error, the difference in meaning is minimal and it is an = example not a technical definition. From owner-zeroconf@merit.edu Fri May 7 07:47:47 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16811 for ; Fri, 7 May 2004 07:47:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 20E349130A; Fri, 7 May 2004 07:47:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDE429130B; Fri, 7 May 2004 07:47:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D69A79130A for ; Fri, 7 May 2004 07:47:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BC56A58F60; Fri, 7 May 2004 07:47:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 80BBC58FF3 for ; Fri, 7 May 2004 07:47:37 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 715F41BB4F9; Fri, 7 May 2004 12:47:38 +0100 (BST) Message-ID: <019501c43429$18598540$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL58] Duplicate inconsistent routable address definition Date: Fri, 7 May 2004 11:47:37 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Section 1.9 duplicates (but not entirely agrees with) Section 1.2. Stuart is right that there is an issue and in fact the definition of 1.9 = is better than that of 1.2. I agree with the proposed change and the additional modification in = Stuarts subsequent email: Replace This document uses the term "routable address" to refer to all unicast IPv4 addresses outside the 169.254/16 prefix, including global addresses and private addresses such as Net 10/8 [RFC1918], all of which may be forwarded via routers. with This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1 Philip From owner-zeroconf@merit.edu Fri May 7 07:54:15 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17013 for ; Fri, 7 May 2004 07:54:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C5E79130B; Fri, 7 May 2004 07:54:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6759D9130C; Fri, 7 May 2004 07:54:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8486B9130B for ; Fri, 7 May 2004 07:54:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 70CC05909C; Fri, 7 May 2004 07:54:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 3710F5908E for ; Fri, 7 May 2004 07:54:06 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 249691BB4F9; Fri, 7 May 2004 12:54:07 +0100 (BST) Message-ID: <01a201c4342a$00022d70$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL59] Wireless comment not needed Date: Fri, 7 May 2004 11:54:06 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Stuart that this text is unnecessary and the more I read it = the less it means. However, I also agree with Erik and Ralph that this text has already = delayed the document, that it does no harm and that it has been through = last call so the chance to argue it has passed. Philip From owner-zeroconf@merit.edu Fri May 7 07:56:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17071 for ; Fri, 7 May 2004 07:56:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA3F49130E; Fri, 7 May 2004 07:56:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A741E9130C; Fri, 7 May 2004 07:56:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 636949130E for ; Fri, 7 May 2004 07:56:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2E3459095; Fri, 7 May 2004 07:56:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 930B259091 for ; Fri, 7 May 2004 07:56:15 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id A86511BB4C1; Fri, 7 May 2004 12:56:16 +0100 (BST) Message-ID: <01a901c4342a$4d37f480$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL60] Forward reference style Date: Fri, 7 May 2004 11:56:15 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I have no problem at all with the way parameters are currently dealt = with in the document. It is common usage - keep it as it is. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:05 PM Subject: WG ACTION: 2 weeks to discuss [LL60] Forward reference style > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [LL60] >=20 > Description of Issue: Forward reference style > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: e > Prio ['S' Must|1 should|2 may]: 1 > Section: 1.2 > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > > When ready to begin probing, the host should then wait for a = random > > time interval selected uniformly in the range PROBE_MIN to = PROBE_MAX > > seconds, and should then send NUM_PROBES probe packets, spaced > > randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 > PROBE_MIN and PROBE_MAX suddenly appear, without mention. Can we give > their values FIRST, so the reader has a clue what we're talking about. >=20 > [Erik] >=20 > This is standard practice in all RFCs that include constants. We = could > add text to section 1.2 if you think that this is confusing to > implementors. >=20 > Personally I feel this goes without saying and adding it would only be = a > matter of (questionable) style. >=20 > [Stuart] >=20 > I disagee. >=20 > What is the harm in helping the reader understand the document better? >=20 > How can unexplained forward references be good style? >=20 >=20 > Requested Change: >=20 > Add to section 1.2 >=20 > Constants are introduced in all capital letters. Their values are > given in Section 9. >=20 > From owner-zeroconf@merit.edu Fri May 7 08:01:31 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17195 for ; Fri, 7 May 2004 08:01:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E58449130D; Fri, 7 May 2004 08:00:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B69E891310; Fri, 7 May 2004 08:00:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69CC69130D for ; Fri, 7 May 2004 08:00:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B097C58FD4; Fri, 7 May 2004 08:00:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 8A7AD59014 for ; Fri, 7 May 2004 08:00:40 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 748C61BB492; Fri, 7 May 2004 13:00:41 +0100 (BST) Message-ID: <01b301c4342a$eb0bb3e0$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Date: Fri, 7 May 2004 12:00:40 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Agree in principle but suggested text change is wrong. text should read: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range 0 to (PROBE_MAX - = PROBE_MIN) seconds, and should then send NUM_PROBES probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. Alternatively use PROBE_MIN and PROBE_RANGE: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range 0 to PROBE_RANGE seconds, and should then send NUM_PROBES probe packets, spaced randomly, PROBE_MIN to (PROBE_MIN + PROBE_RANGE) seconds apart. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:07 PM Subject: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [LL61] >=20 > Description of Issue: Remove initial wait > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: LL12 > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: S > Section: 2.2.1 > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > > When ready to begin probing, the host should then wait for a = random > > time interval selected uniformly in the range PROBE_MIN to = PROBE_MAX > > seconds, and should then send NUM_PROBES probe packets, spaced > > randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 > Why "wait for a random time interval selected uniformly in the range > PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial > one-second delay? It just slows things down. >=20 > [Erik] >=20 > This delay was intended to stop a set of hosts from beginning at the > same time in a 'LAN power up' situation. This text has passed all > reviews and numerous WG issues to revise and hone it. >=20 > [Stuart] >=20 > I was not asking about the [0,1] random interval. That's been there = since > draft-05. >=20 > I was asking about why it is now 1 + [0,1]. What's the extra fixed > one-second delay for? What is achieved by making the process uniformly > take a second longer than it should? >=20 > [Erik] >=20 > Hmm. Reviewing all records, I can't see how this entered the = doc. > I don't have time for archeology to find out when it entered. I > don't see why waiting an extra second helps, except to wait for > network infrastructure to come up (see ll12). >=20 > Requested Change: >=20 > Text was: >=20 > When ready to begin probing, the host should then wait for a = random > time interval selected uniformly in the range PROBE_MIN to = PROBE_MAX > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 > Text becomes: >=20 > When ready to begin probing, the host should send NUM_PROBES probe > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. > From owner-zeroconf@merit.edu Fri May 7 08:17:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17898 for ; Fri, 7 May 2004 08:17:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A99D991310; Fri, 7 May 2004 08:16:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 789FB91311; Fri, 7 May 2004 08:16:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58F1A91310 for ; Fri, 7 May 2004 08:16:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3356A5904F; Fri, 7 May 2004 08:16:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id CB95E59079 for ; Fri, 7 May 2004 08:16:54 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id C29A21BB503; Fri, 7 May 2004 13:16:55 +0100 (BST) Message-ID: <01c501c4342d$2fc32f70$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405070555.i475tvX2015302@relay1.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Fri, 7 May 2004 12:16:54 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Stuart Cheshire" >=20 > Replace >=20 > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate > IPv4 Link-Local configuration. In particular configuration of an > IPv4 Link-Local address, whether or not a DHCP server is currently > responding, is not sufficient reason to unconfigure a valid DHCP > lease, to stop the DHCP client from attempting to acquire a new IP > address, to change DHCP timeouts or to change the behavior of the > DHCP state machine in any other way. >=20 > Several early implementations of IPv4 Link-Local have modified the > DHCP state machine in an attempt to make IPv4 Link-Local more > reliable, and the field experience we have gained from this has > shown that it does not work - reliability of DHCP service is > significantly reduced. If increased reliability of IPv4 = Link-Local > is desired, we recommend that the IPv4 Link-Local state machine = track > the DHCP client state machine and, in cases where it is not certain > that the DHCP-assigned address is correct, the IPv4 Link-Local = state > machine acquire an IPv4 Link-Local address without causing the DHCP > state machine to relinquish its address. >=20 > Further discussion of this issue is provided in [DNAv4]. >=20 > with just >=20 > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate > IPv4 Link-Local configuration. In particular configuration of an > IPv4 Link-Local address, whether or not a DHCP server is currently > responding, is not sufficient reason to unconfigure a valid DHCP > lease, to stop the DHCP client from attempting to acquire a new IP > address, to change DHCP timeouts or to change the behavior of the > DHCP state machine in any other way. This is omitting a specific recommendation as well as the unspecified = example you objected to. Whether just one or more implementations have made the mistake is = irrelevant - it has been established as a mistake and useful guidance is = provided. However, this reads to me like a worry that unspecified "bad" former = implementations may become erroneously associated with particular = companies. If this is the case, I could accept changing the first part of the = offending paragraph: Several early implementations of IPv4 Link-Local have modified the DHCP state machine in an attempt to make IPv4 Link-Local more reliable, and the field experience we have gained from this has shown that it does not work - reliability of DHCP service is significantly reduced. To: Field experience has shown that modifying the DHCP state machine in an attempt to make IPv4 Link-Local more reliable does not work - reliability of DHCP service is significantly reduced. Philip From owner-zeroconf@merit.edu Fri May 7 08:22:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18020 for ; Fri, 7 May 2004 08:22:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 878AD91311; Fri, 7 May 2004 08:21:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 527EE91312; Fri, 7 May 2004 08:21:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73CD591311 for ; Fri, 7 May 2004 08:21:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A1785904F; Fri, 7 May 2004 08:21:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 236A45908B for ; Fri, 7 May 2004 08:21:53 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 067201BB503; Fri, 7 May 2004 13:21:54 +0100 (BST) Message-ID: <01d301c4342d$e1b00b40$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL64] Simplify some text Date: Fri, 7 May 2004 12:21:53 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I prefer the text as it stands. Using "source address" reminds the = reader of why we know the address of the sender - because it came as the = source address in the incoming message. Philip From owner-zeroconf@merit.edu Fri May 7 08:27:41 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18177 for ; Fri, 7 May 2004 08:27:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42F3C91312; Fri, 7 May 2004 08:27:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 181CB91313; Fri, 7 May 2004 08:27:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0492791312 for ; Fri, 7 May 2004 08:27:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3422590B1; Fri, 7 May 2004 08:27:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 3B95F59091 for ; Fri, 7 May 2004 08:27:30 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 307CF1BB4B0; Fri, 7 May 2004 13:27:31 +0100 (BST) Message-ID: <01f001c4342e$aa7c9d90$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL66] Additional statistical example Date: Fri, 7 May 2004 12:27:30 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I see no compelling need for an example here and it's too late in the = day. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:20 PM Subject: WG ACTION: 2 weeks to discuss [LL66] Additional statistical = example > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [LL66] >=20 > Description of Issue: Additional statistical example > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: 1 > Section: 1.3 > Rationale/Explanation: > Lengthy Description: >=20 > > When these address conflicts are detected, the subsequent forced > > reconfiguration may be disruptive, causing TCP connections to be > > broken. However, it is expected that such disruptions will be = rare. > > It should be relatively uncommon for networks to be joined while > > hosts on those networks are active. Also, 65024 addresses are > > available for IPv4 Link-Local use, so even when two small = networks > > are joined, the chance of collision for any given host is fairly > > small. >=20 > A specific example with numbers: If two 100-host networks are joined, > there's still a better than 75% chance that not a single host on = either > network will have to select a new address. >=20 > [Erik] >=20 > There has been no demand in successive reviews for further example. >=20 > [Stuart] >=20 > I calculated specific numbers to substantiate the previously vague > assertion. >=20 > I believe concrete facts are more informative than vagueness. >=20 > [Erik] >=20 > Thanks for the numbers. My point is that we need to publish this > document with as few changes as possible. This is not an editorial > change. In my opinion 'fact' assertions generate a lot of debate. >=20 > Requested Change: >=20 > Add to section 1.3 >=20 > This specification is intended for use with small ad-hoc networks = - a > single link containing only a few hosts. Although 65024 IPv4 Link- > Local addresses are available in principle, attempting to use all > those addresses on a single link would result a high probability = of > an address conflict, requiring a host to take an inordinate amount = of > time to find an available address. >=20 > becomes >=20 > This specification is intended for use with small ad-hoc networks = - a > single link containing only a few hosts. Although 65024 IPv4 Link- > Local addresses are available in principle, attempting to use all > those addresses on a single link would result a high probability = of > an address conflict, requiring a host to take an inordinate amount = of > time to find an available address. >=20 > If two 100-host networks are joined, > there's still a better than 75% chance that not a single host on = either > network will have to select a new address. > From owner-zeroconf@merit.edu Fri May 7 08:31:23 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18368 for ; Fri, 7 May 2004 08:31:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 106ED91313; Fri, 7 May 2004 08:30:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3E9C91315; Fri, 7 May 2004 08:30:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B45CB91313 for ; Fri, 7 May 2004 08:30:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15AFE58FB8; Fri, 7 May 2004 08:30:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 3715458ED4 for ; Fri, 7 May 2004 08:30:27 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 541681BB502; Fri, 7 May 2004 13:30:28 +0100 (BST) Message-ID: <01f701c4342f$14114580$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL67] Fix clause which forbids routable to LL communication Date: Fri, 7 May 2004 12:30:27 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I support the proposed change. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:22 PM Subject: WG ACTION: 2 weeks to discuss [LL67] Fix clause which forbids = routable to LL communication > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [LL67] >=20 > Description of Issue: Fix clause which forbids routable to=20 > LL communication > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: S > Section: 6.2 > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > > IPv4 Link-Local addresses MUST NOT be forwarded via an = application > > protocol (for example in a URL), to a destination which is not = Link- > > Local, on the same link. This is discussed further in Section = 2.9 > > and 3. >=20 > How about: > > IPv4 Link-Local addresses MUST NOT be forwarded via an = application > > protocol (for example in a URL), to a destination which is not > > on the same link. This is discussed further in Section 2.9 and = 3. >=20 > [Erik] >=20 > Your sentence means something entirely different than what is in the > document. In your text host A with LL address a could send 'a' in an > application protocol to host B with a routable address. In the = current > document, this would not be allowed. We want proper interaction > between hosts A and B with as few restrictions as possible without > disruptive consequences. That is the fine line we've had to walk for > the past 5 years. I personally prefer your wording (and its meaning) = to > what the document currently says. To open this up would require us to > go back to discussion, last calls, etc. however. >=20 > [Stuart] >=20 > As written, other places in the draft allow routable-to-LL = communication, > but this "MUST NOT" prohibits that. A routable device can't send = packets > to an LL device unless it knows the LL device's LL address, but how = can a > routable device learn the LL device's LL address, if sending an LL > address to a non-LL destination address is prohibited? >=20 > [Erik] >=20 > This is clearly a technical revision we need to consider. I agree > that we should make this change. >=20 > Requested Change: >=20 > Section 6.2, From: >=20 > > IPv4 Link-Local addresses MUST NOT be forwarded via an = application > > protocol (for example in a URL), to a destination which is not = Link- > > Local, on the same link. This is discussed further in Section = 2.9 > > and 3. >=20 > To: >=20 > > IPv4 Link-Local addresses MUST NOT be forwarded via an = application > > protocol (for example in a URL), to a destination which is not > > on the same link. This is discussed further in Section 2.9 and = 3. >=20 > From owner-zeroconf@merit.edu Fri May 7 08:33:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18410 for ; Fri, 7 May 2004 08:33:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E32B891315; Fri, 7 May 2004 08:33:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B235D91316; Fri, 7 May 2004 08:33:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EC4891315 for ; Fri, 7 May 2004 08:33:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6946C58FD4; Fri, 7 May 2004 08:33:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 19A0D5908E for ; Fri, 7 May 2004 08:32:56 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 127D31BB502; Fri, 7 May 2004 13:32:57 +0100 (BST) Message-ID: <01fe01c4342f$6cb82050$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable Date: Fri, 7 May 2004 12:32:56 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I do not support the proposed change. I am quite happy with the current text. The use of protocol constants in = the way we have done is commonplace and this is a protocol = specification, not a guide for dummies. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:23 PM Subject: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not = user configurable > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [ll68] >=20 > Description of Issue: Stress constants are not user configurable > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: e > Prio ['S' Must|1 should|2 may]: s > Section: all > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > Also, we need to stress that these are MUST NOT be user-configurable > options, or the users will just decide they can set them to zero to = "make > it go faster". >=20 > [Erik] >=20 > No user configurable options are mentioned in the text. I do not > understand what you mean by 'set them to zero.' What settings are you > referring to? >=20 > [Stuart] >=20 > When you use symbolic identifiers in place of concrete values it = implies > abstraction (Generalisation; ignoring or hiding details to capture = some > kind of commonality between different instances), which implies = therefore > that there are different instances with different values for those > abstracted identifiers. >=20 > If the intention is that different instances will have different = values > for these symbolic identifiers, then the draft should say so. >=20 > If the intention is that different instances will have NOT different > values for these symbolic identifiers, then the draft should say so. >=20 > I'm just asking for clarification. >=20 > [Erik] >=20 > The reasons we are using constants are > * The WG called for it, primarily > * There has been an interest in specifying new sets of > constants 'in the future' for specific link layers which > might call for different timing > * Use of constants instead of values in the text is considered > absolutely necessary by many technical reviewers, for clarity > and style consistent with other IETF published technical > documentation. > * Use of a constant term assures the assignment of the term will > be in one authoritative place. This improves the overall > consistency of the document and improves ease of reference. > In this respect technical writing parallels acceptable program > coding practice. >=20 > Requested Change: >=20 > TEXT NEEDED > From owner-zeroconf@merit.edu Fri May 7 08:34:29 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18460 for ; Fri, 7 May 2004 08:34:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F132591316; Fri, 7 May 2004 08:34:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C24C991317; Fri, 7 May 2004 08:34:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB63F91316 for ; Fri, 7 May 2004 08:34:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C669459028; Fri, 7 May 2004 08:34:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 92E6458F7B for ; Fri, 7 May 2004 08:34:19 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id C33D21BB505; Fri, 7 May 2004 13:34:20 +0100 (BST) Message-ID: <020501c4342f$9e9d6940$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL69] Move constants to beginning of doc Date: Fri, 7 May 2004 12:34:19 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I do not support the proposed change. The current usage and placement of = constants is fine. Philip From owner-zeroconf@merit.edu Fri May 7 08:53:29 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19116 for ; Fri, 7 May 2004 08:53:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1B1B91317; Fri, 7 May 2004 08:53:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92BB891318; Fri, 7 May 2004 08:53:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7519091317 for ; Fri, 7 May 2004 08:53:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62E2559028; Fri, 7 May 2004 08:53:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id EBCE659091 for ; Fri, 7 May 2004 08:53:19 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id C226A1BB492; Fri, 7 May 2004 13:53:20 +0100 (BST) Message-ID: <026d01c43432$4616e050$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" References: Subject: Re: WG ACTION: 2 weeks to discuss [LL70] DNAv4 normative or informative? Date: Fri, 7 May 2004 12:53:18 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree that as it stands the reference is normative. We could get around this by making the definition more vague: Change: A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. to: "valid routable address": The determination of whether a routable address is valid will vary with the network infrastructure and system context. A useful guide is provided by the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4] which is performed by attempting to verify reachability of the default gateway(s). Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 04, 2004 11:26 PM Subject: WG ACTION: 2 weeks to discuss [LL70] DNAv4 normative or = informative? > Please post discussion of this issue to the mailing list over the=20 > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a = strong WG > consensus given that this is very late in the process. >=20 > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a = list of > current issues and their status. >=20 > [ll70] >=20 > Description of Issue: DNAv4 normative or informative? > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: S > Section: References > Rationale/Explanation: > Lengthy Description: >=20 > [Stuart] >=20 > >[DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", > > draft-ietf-dhc-dna-ipv4-06.txt, Internet draft (work in > > progress), March 2004. >=20 > Is this normative or informative? >=20 > If ICMP is normative, this should be too. >=20 > Or neither should be. >=20 > [Erik] >=20 > Why do you say that? The only places we mention DNAv4 is in = connection > with DHCPv4. If the IESG is happy with the informative reference > categorization, so am I. Adding this to the Normative reference = section > would delay publication of IPv4LL till DNAv4 is done. I do not = believe > DNAv4 will complete within a year. >=20 > [Stuart] >=20 > I disagee. >=20 > For these > reasons, a host SHOULD NOT have both a valid routable address and = an > IPv4 Link-Local address configured on the same interface. >=20 > A "valid routable address" is a routable address that passes the > reachability test described in section 2 of "Detection of Network > Attachment (DNA) in IPv4" [DNAv4]. >=20 > To implement this "SHOULD NOT" requirement, an implementation has to = also > implement [DNAv4] to determine what's a "valid routable address". >=20 > Hence, normative reference (or the "SHOULD NOT" prohibition could be > removed or refined to not depend on DNAv4). >=20 > [Erik] >=20 > Hmmm. Do you realize you want to raise the bar for the publishing > of this document beyond what the IESG has called for. This change > of category may well result in tens of months delay of publication of = this RFC. >=20 > Can we change the 'is' verb in the second cited sentence to one > that reads 'may be determined' and add some text from DNAv4 with > an informative reference 'for further information'? That is the > way specific citations to 'upcoming work' are usually handled in > order to avoid creating document dependencies. >=20 > Requested Change: >=20 > Move DNAv4 from informative to normative. > From owner-zeroconf@merit.edu Fri May 7 09:52:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22080 for ; Fri, 7 May 2004 09:52:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2936B91318; Fri, 7 May 2004 09:52:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F066191319; Fri, 7 May 2004 09:52:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F131591318 for ; Fri, 7 May 2004 09:52:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB7F65909A; Fri, 7 May 2004 09:52:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id 10DFE5909E for ; Fri, 7 May 2004 09:52:50 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47DqlXF006496 for ; Fri, 7 May 2004 09:52:47 -0400 (EDT) Received: from [172.16.245.200] ([216.87.40.137]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47DqiAf001529 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 09:52:46 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 08:52:42 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <01fe01c4342f$6cb82050$131010ac@aldebaran> 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 On 5/7/04 7:32 AM, "Philip Nye" wrote: > I am quite happy with the current text. The use of protocol constants in the > way we have done is commonplace and this is a protocol specification, not a > guide for dummies. Would it not then behoove us to eliminate ambiguity wherever possible? Ego about "this is not a guide for dummies" set aside, ambiguity about standards has cause problems before. For an example, see "The Great Microsoft Kerberos Scandal." Clarity is always preferable to ambiguity. john -------------------------------------------------------- Misquotation of unattributed, trite metaphysical saying goes here. Stupid ascii Unnecessary notice of graphic goes here. responsibility goes here. --------------------------------------------------------- From owner-zeroconf@merit.edu Fri May 7 09:56:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22333 for ; Fri, 7 May 2004 09:56:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 481379131B; Fri, 7 May 2004 09:56:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08F339131C; Fri, 7 May 2004 09:56:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15E7D9131B for ; Fri, 7 May 2004 09:56:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03BE6590AC; Fri, 7 May 2004 09:56:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id 7EC35590AF for ; Fri, 7 May 2004 09:56:39 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47DudXF007421 for ; Fri, 7 May 2004 09:56:39 -0400 (EDT) Received: from [172.16.245.200] ([216.87.40.137]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47DuZAf003162 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 09:56:37 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 08:56:33 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL69] Move constants to beginning of doc From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:24 PM, "Erik Guttman" wrote: >> 9. Constants >> >> The following timing constants are used in this protocol. >> >> PROBE_MIN 1 second >> PROBE_MAX 2 seconds >> PROBE_N 2 >> NUM_PROBES 3 >> MAX_COLLISIONS 10 >> RATE_LIMIT_INTERVAL 60 seconds > > Can we list this *before* they are used in the text? I support this. Regardless of how other RFCs do this, it is far more sensible to define constants and other RFC specific terms prior to their use. Again, this is not catering to the lowest common denominator, but rather giving the people who will use this RFC more clarity in the terms used by the RFC. john -- "I think love is a snowmobile racing across the arctic tundra which suddenly flips, pinning you underneath. At night, the ice-weasels come...." Matt Groening From owner-zeroconf@merit.edu Fri May 7 10:00:47 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22645 for ; Fri, 7 May 2004 10:00:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 400E59131E; Fri, 7 May 2004 10:00:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BA229131D; Fri, 7 May 2004 10:00:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E5D79131C for ; Fri, 7 May 2004 10:00:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 985FE58CED; Fri, 7 May 2004 10:00:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id 4215458FEB for ; Fri, 7 May 2004 10:00:11 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47E0AXF008802 for ; Fri, 7 May 2004 10:00:10 -0400 (EDT) Received: from [172.16.245.200] ([216.87.40.137]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47E07Af004519 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 10:00:09 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 09:00:05 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL52] Text surrounding RFC 2119 clause is poor From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:00 PM, "Erik Guttman" wrote: > Requested Change: > > Omit the unnecessary text before "The key words ..." > > Was: > 1.1. Requirements > > In this document, several words are used to signify the requirements > of the specification. These words are often capitalized. The key > words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", > "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document > are to be interpreted as described in [RFC2119]. > > Becomes: > 1.1. Requirements > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", i > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. I support this. The fact that they are capitalized as they are listed is a clear sign that this is a common case usage. Telling people they are often capitalized is redundant, especially with the reference to 2119. john -- Know and use all the capabilities in your airplane. If you don't, sooner or later, some guy who does use them all will kick your ass. -- Dave 'Preacher' Pace From owner-zeroconf@merit.edu Fri May 7 10:02:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22745 for ; Fri, 7 May 2004 10:02:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73AAE9131C; Fri, 7 May 2004 10:02:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42AE59131D; Fri, 7 May 2004 10:02:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 498ED9131C for ; Fri, 7 May 2004 10:02:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32FDB59066; Fri, 7 May 2004 10:02:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id B92455904F for ; Fri, 7 May 2004 10:02:26 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47E2QXF009789 for ; Fri, 7 May 2004 10:02:26 -0400 (EDT) Received: from [172.16.245.200] ([65.170.48.201]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47E2MAf005360 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 10:02:25 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 09:02:20 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL54] Consistent terminology for out of scope From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:00 PM, "Erik Guttman" wrote: > Lets be consistent. Can we pick one phrase? Either "outside the scope of > this document" or "left to a future document". > > Requested Change: > > Use consistent terminology: 'out of scope' in each case. Agreed. "Out of scope" implies that however this is settled, it won't be here. "In a future document" implies that it may be settled in a future rev of this document, in a future rev of some other document, some document that is being built, or in some document that does not yet exist, and may never exist. "Out of scope" is simpler, and more clear. john -- Paene meracus malorum sum (I am nearly pure evil) From owner-zeroconf@merit.edu Fri May 7 10:04:50 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22953 for ; Fri, 7 May 2004 10:04:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A10A9131F; Fri, 7 May 2004 10:04:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 071A891320; Fri, 7 May 2004 10:04:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DE3D9131F for ; Fri, 7 May 2004 10:04:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE8585907B; Fri, 7 May 2004 10:04:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id EDF3F5907C for ; Fri, 7 May 2004 10:04:36 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47E4aXF010386 for ; Fri, 7 May 2004 10:04:36 -0400 (EDT) Received: from [172.16.245.200] ([65.170.48.9]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47E4XAf006322 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 10:04:35 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 09:04:31 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL59] Wireless comment not needed From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:04 PM, "Erik Guttman" wrote: > The sentence is harmless, though not very useful. Including it > was necessary to get the document approved. > > Requested Change: > > Omit > >> (This example does >> not imply that IPv4 Link-Local configuration is inapplicable >> to wireless interfaces). If it's the only way to get it approved, fine, but it's useless verbiage, and really doesn't belong. It should be deleted. john -- "Who Dares, Wins." British Special Air Service (SAS) From owner-zeroconf@merit.edu Fri May 7 10:07:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23221 for ; Fri, 7 May 2004 10:07:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1002E9131D; Fri, 7 May 2004 10:07:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D538B91320; Fri, 7 May 2004 10:07:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE20A9131D for ; Fri, 7 May 2004 10:07:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA30759081; Fri, 7 May 2004 10:07:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id 5D6795908B for ; Fri, 7 May 2004 10:07:27 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47E7RXF011524 for ; Fri, 7 May 2004 10:07:27 -0400 (EDT) Received: from [172.16.245.200] ([65.170.48.9]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47E7MAf007428 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 10:07:24 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 09:07:20 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL60] Forward reference style From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:05 PM, "Erik Guttman" wrote: >> When ready to begin probing, the host should then wait for a random >> time interval selected uniformly in the range PROBE_MIN to PROBE_MAX >> seconds, and should then send NUM_PROBES probe packets, spaced >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > > PROBE_MIN and PROBE_MAX suddenly appear, without mention. Can we give > their values FIRST, so the reader has a clue what we're talking about. > > [Erik] > > This is standard practice in all RFCs that include constants. We could > add text to section 1.2 if you think that this is confusing to > implementors. > > Personally I feel this goes without saying and adding it would only be a > matter of (questionable) style. > > [Stuart] > > I disagee. > > What is the harm in helping the reader understand the document better? > > How can unexplained forward references be good style? I will say that at least in American English, suddenly using undefined terms will get you fussed at by almost anyone. Using terms without defining them first is a great way to cause problems. Since this is an engineering document of sorts, document - specific terms should be properly defined as to their usage in the document prior to that usage. john -- "C++? That is for children. A Klingon Warrior uses only machine code, keyed in on the front panel switches in raw binary." From owner-zeroconf@merit.edu Fri May 7 10:08:20 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23305 for ; Fri, 7 May 2004 10:08:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C613E91320; Fri, 7 May 2004 10:08:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 910DF91321; Fri, 7 May 2004 10:08:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 93E5E91320 for ; Fri, 7 May 2004 10:08:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 826BD5907F; Fri, 7 May 2004 10:08:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id 191965909C for ; Fri, 7 May 2004 10:08:10 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47E89XF011671 for ; Fri, 7 May 2004 10:08:09 -0400 (EDT) Received: from [172.16.245.200] ([216.87.40.137]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47E85Af007719 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 10:08:08 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 09:08:03 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:07 PM, "Erik Guttman" wrote: > I was asking about why it is now 1 + [0,1]. What's the extra fixed > one-second delay for? What is achieved by making the process uniformly > take a second longer than it should? > > [Erik] > > Hmm. Reviewing all records, I can't see how this entered the doc. > I don't have time for archeology to find out when it entered. I > don't see why waiting an extra second helps, except to wait for > network infrastructure to come up (see ll12). If we can't see how it got in, it should be taken out. john -- Wear the condom. No, for the love of Pete, not the mint-flavored one. Jesus, that thing burns. From owner-zeroconf@merit.edu Fri May 7 10:11:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23726 for ; Fri, 7 May 2004 10:11:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B37F291321; Fri, 7 May 2004 10:10:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 868A491322; Fri, 7 May 2004 10:10:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D59F91321 for ; Fri, 7 May 2004 10:10:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7ADC7590B6; Fri, 7 May 2004 10:10:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by segue.merit.edu (Postfix) with ESMTP id 0C888590B9 for ; Fri, 7 May 2004 10:10:54 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i47EArXF012259 for ; Fri, 7 May 2004 10:10:53 -0400 (EDT) Received: from [172.16.245.200] ([65.170.48.137]) (authenticated bits=0) (User authenticated as jwelch@ATHENA.MIT.EDU) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i47EAoAf008825 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 7 May 2004 10:10:52 -0400 (EDT) User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Fri, 07 May 2004 09:10:48 -0500 Subject: Re: WG ACTION: 2 weeks to discuss [LL69] Move constants to beginning of doc From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 On 5/4/04 6:24 PM, "Erik Guttman" wrote: > [Stuart] > >> 9. Constants >> >> The following timing constants are used in this protocol. >> >> PROBE_MIN 1 second >> PROBE_MAX 2 seconds >> PROBE_N 2 >> NUM_PROBES 3 >> MAX_COLLISIONS 10 >> RATE_LIMIT_INTERVAL 60 seconds > > Can we list this *before* they are used in the text? > > Abstractions are great for experts, but not for people learning. Think > about children. They learn specific examples first, and then from a > collection of specific examples generalize to abstractions. Beginning > with the abstract is not the way to inform the reader. > > [Erik] > > Listing constants early in the RFC is not common practice. Constants > are not abstractions. > > [Stuart] > > Using a symbolic identifier in place of a concrete value is not > abstraction? > > Since when? I support this. It's far better practice to define terms prior to use. john -- "Keecking butt fahr gudness" Baldur's Gate From owner-zeroconf@merit.edu Fri May 7 10:14:53 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24181 for ; Fri, 7 May 2004 10:14:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28D3B91322; Fri, 7 May 2004 10:14:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7EB791323; Fri, 7 May 2004 10:14:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABD0C91322 for ; Fri, 7 May 2004 10:14:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94207590C2; Fri, 7 May 2004 10:14:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id 1090B590AC for ; Fri, 7 May 2004 10:14:44 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i47CEcg20790; Fri, 7 May 2004 05:14:38 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i47EEci04736; Fri, 7 May 2004 07:14:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 07:14:38 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C6EBEE4@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Thread-Index: AcQ0FoZ6FpoSrL+WSoyX1jpa7MaQ4AAJH6rA From: "Elder, Alex" To: "Philip Nye" , "Stuart Cheshire" , Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Stuart is right that the sum of randomness leads to less randomness. However Philip is right that it doesn't really apply here, since by definition we're dealing with a case in which a probe resulted in a collision (i.e., two hosts picked the same initial delay). My contention has been that the initial random delay is sufficient to address this collision issue, provided the range of that delay is big enough that the number of quantized "slots" therein is adequate. Going back to the dice example, it's rolling a 12-sided die once instead of a 6-sided die twice. (Also, again, the purpose of this delay is different from the purpose of the probe interval, so should be defined independent from PROBE_MIN and PROBE_MAX.) -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Philip Nye > Sent: Friday, May 07, 2004 4:35 AM > To: Stuart Cheshire; zeroconf@merit.edu > Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes > randomly >=20 >=20 > > From: "Stuart Cheshire" > >=20 > > ...but the biggest problem may be this: > >=20 > > The sum of random variables is LESS random than the=20 > individual variables. > >=20 > > Ask any statistician, or do a Google search for "central=20 > limit theorem"=20 > > or "strong law of large numbers". > >=20 > > Here's a simple example that should be familiar to everyone: > >=20 > > If you throw one die, the numbers 1,2,3,4,5,6 are all=20 > equally likely. > >=20 > > If you throw two dice, and add up the results, then 7 is=20 > the most likely=20 > > outcome. You are SIX TIMES more likely to get 7 than either 2 or 12. >=20 > Stuart, >=20 > This is a completely spurious statistical argument I'm=20 > afraid. If you want to use the dice example - here is the scenario: >=20 > You an I both generate a series of 4 numbers. The first value=20 > is generated by throwing a single die. >=20 > case A. Each subsequent value is generated by adding 4, 3 and=20 > 4 respectively to the preceeding value. >=20 > case B. Each subsequent value is generated by throwing the=20 > die again and adding that value to the preceeding value. >=20 > Now the probability that you are talking about is that you=20 > and I agree on AT LEAST ONE value in our series which does=20 > increase in case B. It is 1/6 for A and approximately 0.52 for B. >=20 > However that is irrelevant, the chance we need to avoid is=20 > that you and I both agree on ALL FOUR values in our series.=20 > For A this probability is 1/6 while for B it is 1/(6^4) =3D 1/1296. >=20 > Returning to the computer algorithm, given the fact that in=20 > many implementations a "random" delay is likely to be=20 > quantised to the inherent tick frequency of the operating=20 > system, then the probability of an initial delay in the range=20 > 0..1 second being the same for two hosts is not very low=20 > (1/100 for a typical OS and as big as 1/20 for some). Making=20 > subsequent delays also random drastically increases the=20 > chances that at least some of the probes will not clash. >=20 > What is the reason for sending four probes? In the case of=20 > only the initial delay being randomised, the extra ones=20 > merely guard against the possibility that probes may be=20 > dropped or lost. In the case of consecutive random delays=20 > this still applies but they have the added benefit of=20 > reducing the chances of all probes being lost because of=20 > timing clashes. >=20 > In conclusion. I agree with Christian that the initial wait=20 > should be in the range 0..(PROBE_MAX - PROBE_MIN) which is=20 > different from the current draft. I also agree with him that=20 > the subsequent delays should be randomised exactly as in the=20 > current draft. >=20 > Philip >=20 >=20 From owner-zeroconf@merit.edu Fri May 7 10:25:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25429 for ; Fri, 7 May 2004 10:24:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03C2191324; Fri, 7 May 2004 10:24:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8F6C91325; Fri, 7 May 2004 10:24:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B381291324 for ; Fri, 7 May 2004 10:24:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 99DD5590AB; Fri, 7 May 2004 10:24:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id 16B875909C for ; Fri, 7 May 2004 10:24:43 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i47COdg25002; Fri, 7 May 2004 05:24:39 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i47EOei08447; Fri, 7 May 2004 07:24:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Date: Fri, 7 May 2004 07:24:40 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C6EBEE5@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Thread-Index: AcQz95o/O0FzgC05S42wURSNgezvMgARrAkg From: "Elder, Alex" To: "Stuart Cheshire" , Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable My only comment on this is that the paragraph that would follow this one in the document should be updated as well, to indicate something like: If during this period, from the beginning of the probing process until PROBE_INTERVAL seconds after the last probe packet is sent, the = host receives any ARP packet (It previously used "PROBE_MAX" rather than "PROBE_INTERVAL".) Also, a few paragraphs later: If, by PROBE_INTERVAL seconds after the transmission of the last ARP = probe no conflicting ARP Reply or ARP probe has been received, then the host has successfully claimed the desired Link-Local IPv4 address. (I haven't done any exhaustive review of the document for this so there could be other spots.) -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Stuart Cheshire > Sent: Friday, May 07, 2004 12:53 AM > To: zeroconf@merit.edu > Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait >=20 >=20 > >I believe it should have been random initial delay + retransmissions > >spaced 1 seconds apart, rather than what somehow came out in the > >document. > > > > MikaL >=20 > A long time ago, draft-07 said: >=20 > When ready to begin probing, the host should then wait for a > random time interval selected uniformly in the range zero to two > seconds, and should then send four probe packets, spaced two > seconds apart. This initial random delay helps ensure that a > large number of hosts powered on at the same time do not all send > their initial probe packets simultaneously. >=20 > With our new parametrized text, this becomes: >=20 > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range zero to START_WAIT > seconds, and should then send PROBE_NUM probe packets, spaced > PROBE_INTERVAL seconds apart. This initial randomized delay helps > ensure that a large number of hosts powered on at the same time do > not all send their initial probe packets simultaneously. >=20 > I believe this is perfectly adequate. >=20 > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org >=20 >=20 From owner-zeroconf@merit.edu Fri May 7 11:34:23 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01612 for ; Fri, 7 May 2004 11:34:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF26291238; Fri, 7 May 2004 11:34:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80D9091228; Fri, 7 May 2004 11:34:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B8C291327 for ; Fri, 7 May 2004 11:34:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7DFAF59083; Fri, 7 May 2004 11:34:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by segue.merit.edu (Postfix) with ESMTP id 43FD959028 for ; Fri, 7 May 2004 11:34:08 -0400 (EDT) Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-2.cisco.com with ESMTP; 07 May 2004 08:33:37 -0700 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47FY1Yu001073 for ; Fri, 7 May 2004 11:34:02 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF61174; Fri, 7 May 2004 11:34:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20040507112828.01fc4ab0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 May 2004 11:33:59 -0400 To: From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly In-Reply-To: <00f401c43416$82b56f70$131010ac@aldebaran> References: <200405070554.i475sqoE026936@relay3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with Philip's reasoning - the subsequent randomization addresses the (admittedly small, assuming good random number generators) problem that two hosts might pick an initial delay within a collision window of each other. If there is no randomization of subsequent probes, there is no point in specifying multiple probes. - Ralph At 09:34 AM 5/7/2004 +0000, Philip Nye wrote: > > From: "Stuart Cheshire" > > > > ...but the biggest problem may be this: > > > > The sum of random variables is LESS random than the individual variables. > > > > Ask any statistician, or do a Google search for "central limit theorem" > > or "strong law of large numbers". > > > > Here's a simple example that should be familiar to everyone: > > > > If you throw one die, the numbers 1,2,3,4,5,6 are all equally likely. > > > > If you throw two dice, and add up the results, then 7 is the most likely > > outcome. You are SIX TIMES more likely to get 7 than either 2 or 12. > >Stuart, > >This is a completely spurious statistical argument I'm afraid. If you want >to use the dice example - here is the scenario: > >You an I both generate a series of 4 numbers. The first value is generated >by throwing a single die. > >case A. Each subsequent value is generated by adding 4, 3 and 4 >respectively to the preceeding value. > >case B. Each subsequent value is generated by throwing the die again and >adding that value to the preceeding value. > >Now the probability that you are talking about is that you and I agree on >AT LEAST ONE value in our series which does increase in case B. It is 1/6 >for A and approximately 0.52 for B. > >However that is irrelevant, the chance we need to avoid is that you and I >both agree on ALL FOUR values in our series. For A this probability is 1/6 >while for B it is 1/(6^4) = 1/1296. > >Returning to the computer algorithm, given the fact that in many >implementations a "random" delay is likely to be quantised to the inherent >tick frequency of the operating system, then the probability of an initial >delay in the range 0..1 second being the same for two hosts is not very >low (1/100 for a typical OS and as big as 1/20 for some). Making >subsequent delays also random drastically increases the chances that at >least some of the probes will not clash. > >What is the reason for sending four probes? In the case of only the >initial delay being randomised, the extra ones merely guard against the >possibility that probes may be dropped or lost. In the case of consecutive >random delays this still applies but they have the added benefit of >reducing the chances of all probes being lost because of timing clashes. > >In conclusion. I agree with Christian that the initial wait should be in >the range 0..(PROBE_MAX - PROBE_MIN) which is different from the current >draft. I also agree with him that the subsequent delays should be >randomised exactly as in the current draft. > >Philip From owner-zeroconf@merit.edu Fri May 7 13:48:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08511 for ; Fri, 7 May 2004 13:48:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 251CE91236; Fri, 7 May 2004 13:46:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4D9591238; Fri, 7 May 2004 13:46:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6CA791236 for ; Fri, 7 May 2004 13:46:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B86F858B4C; Fri, 7 May 2004 13:46:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 6CC3D58B1F for ; Fri, 7 May 2004 13:46:57 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i47HlC5g021657 for ; Fri, 7 May 2004 10:47:12 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 10:46:56 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i47HkdQp007221 for ; Fri, 7 May 2004 10:46:40 -0700 (PDT) Message-Id: <200405071746.i47HkdQp007221@relay4.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 10:46:39 -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 Philip Nye wrote: >the chance we need to avoid is that you and I >both agree on ALL FOUR values in our series. This is statement is asserted without any supporting evidence, and it is false. This is NOT what we need to avoid. In order to be a good network citizen, we want to minimize the aggregate peak load that a large number of hosts may impose on network infrastructure, since peak load is what causes loss. This issue only arises when there are a large number of hosts probing simultaneously. Two hosts, or three, or four or even ten host probing at *exactly* the same time is NOT a problem. The Ethernet collision loss myth has existed for decades. University computer science lecturers teach students that it's a myth, but still the myth persists in the larger population. Collisions do not cause loss on Ethernet. They did not on thick coax, thin coax, or on UTP. Pay particular attention to the second paragraph below. >What Vernon says is quite right and I'll only add that Collision sensing >and recovery happens in times on the order of 200 uS to a few mS, on >even extremely highly contended Ethernet segments (many stations ready >with pkts to send all the time). This is far faster than Token passing >(many mS), in any of its forms, as a very pertinent graph from the >original IEEE 802 standarization simulations shows (it can be faxed to >anyone who wishes a copy). This graph is particularly telling in that >CSMA/CD become better in relation to Token as the number of contending >nodes increases -- yes, better. > >One reason for trying to rid the world of 'collision' myths is that they >serve as an alarm for how easily misinformation can arise and how hard >it is to gather peoples' intellects together to stamp the myths out. >Confining ourselves to networking, we must be aware that this applies in >the TCP/IP realm as well. Back to the LAN realm, which the original IP >world had no cognizance of, the collision myth, that started as an IBM >marketing weapon, matured into a switch vendors' scare tactic to sell at >first cut-through (a bad idea now in disrepute) and later "a segment for >every node", so that "collisions would no longer occur" -- just pushing >the problem into provisioning of the switch fabric. "Caveat emptor" is >as necessary today as it has ever been. Ralph Droms wrote: >If there is no randomization of subsequent probes, there is no point in >specifying multiple probes. No, this is false. We don't assume the ARP probes are the ONLY traffic on the network. The reason for trying three times is that there may be OTHER brief bursts of traffic on the link that overflow the switch buffers (or cause CSMA/CD breakdown, etc.) resulting in one or more probes being lost. In reality, the amount of traffic generated by ARP probing is too low by itself to cause switch buffer overflow -- PROVIDING that it is distributed over several seconds. Should all the probes be sent in a tight bunch, then the chance of switch buffer overflow could become non-zero, which is why the initial random delay is useful to eliminate that. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 13:52:22 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08745 for ; Fri, 7 May 2004 13:52:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 208BA91234; Fri, 7 May 2004 13:52:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E267091237; Fri, 7 May 2004 13:52:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0CCFF91234 for ; Fri, 7 May 2004 13:52:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DED7258D7C; Fri, 7 May 2004 13:52:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 2F7B358D38 for ; Fri, 7 May 2004 13:52:13 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i47HqSFj023303 for ; Fri, 7 May 2004 10:52:28 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 10:52:12 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i47HptxU014596 for ; Fri, 7 May 2004 10:51:56 -0700 (PDT) Message-Id: <200405071751.i47HptxU014596@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes Date: Fri, 7 May 2004 10:51:55 -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 >several appear to be pedantic filibusters! These are not filibusters, pedantic or otherwise. The authors of the document are entitled -- required even -- to exercise sound judgment about typographical issues in the document. Questions of spelling errors, simple grammatical errors, etc., trivial mistakes (e.g. "169.254.255" where it should have said "169.254.255.255") can and should be fixed without a lot of protracted debate. In the interest of transparency Erik Guttman chose to list even all these minor changes for the benefit of the working group. The filibuster here, if any, is the attitude, "There's nothing wrong with this edit and it would improve the document, but I'm going to oppose it anyway." If we want this process to conclude, we need to sincerely work towards agreement. If we seek every opportunity for disagreement, the process could continue indefinitely. Lets please try to find agreement here. If you find factual or technical errors in the proposed edits then by all means point them out, otherwise, lets just agree and publish the document. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 13:52:40 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08763 for ; Fri, 7 May 2004 13:52:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BDC4991238; Fri, 7 May 2004 13:52:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86F8491237; Fri, 7 May 2004 13:52:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C78DC91238 for ; Fri, 7 May 2004 13:52:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADE8E58D95; Fri, 7 May 2004 13:52:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 3EF9858D28 for ; Fri, 7 May 2004 13:52:25 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i47Hqeen023411 for ; Fri, 7 May 2004 10:52:40 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 10:52:24 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i47HqMJv011664 for ; Fri, 7 May 2004 10:52:23 -0700 (PDT) Message-Id: <200405071752.i47HqMJv011664@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Fri, 7 May 2004 10:52:22 -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 > Field experience has shown that modifying the DHCP state machine > in an attempt to make IPv4 Link-Local more reliable does not work > - reliability of DHCP service is significantly reduced. I have no objection to giving our best known advice: > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate My objection is to inventing fictitious "early implementations" or "field experience" to apparently back up our advice. This is strangely topical -- the US president and the US and UK governments are taking a lot of criticism right now for the alleged fabrication of supporting evidence to justify their chosen course of action. What is this claimed "field experience"? Is it a pure fiction? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 13:53:22 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08840 for ; Fri, 7 May 2004 13:53:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7589912EF; Fri, 7 May 2004 13:53:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 746E9912F0; Fri, 7 May 2004 13:53:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99A08912EF for ; Fri, 7 May 2004 13:53:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FB6458D44; Fri, 7 May 2004 13:53:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id 112BC58A5C for ; Fri, 7 May 2004 13:53:12 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i47HrRGL023627 for ; Fri, 7 May 2004 10:53:27 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 10:53:11 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i47Hr9Ew015381 for ; Fri, 7 May 2004 10:53:10 -0700 (PDT) Message-Id: <200405071753.i47Hr9Ew015381@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL68] Stress constants are not user configurable Date: Fri, 7 May 2004 10:53:09 -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 is a protocol specification, not a guide for dummies. This argument -- "this would make the document clearer and easier to understand, therefore it is a bad thing" -- is not one that convinces me. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 15:31:26 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15838 for ; Fri, 7 May 2004 15:31:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01B4591236; Fri, 7 May 2004 15:31:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD68591238; Fri, 7 May 2004 15:31:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9BC291236 for ; Fri, 7 May 2004 15:31:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A399D58B4C; Fri, 7 May 2004 15:31:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 2143058DD7 for ; Fri, 7 May 2004 15:31:11 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i47JV7020000 for ; Sat, 8 May 2004 02:31:07 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i47JV6DD013126 for ; Sat, 8 May 2004 02:31:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i47JD5Xi007959; Sat, 8 May 2004 02:13:06 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL55] 'Prevent' is too strong In-Reply-To: <200405070546.i475kvdg011950@relay4.apple.com> References: <200405070546.i475kvdg011950@relay4.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 02:13:05 +0700 Message-ID: <29182.1083957185@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 May 2004 22:47:02 -0700 From: Stuart Cheshire Message-ID: <200405070546.i475kvdg011950@relay4.apple.com> | The word "use" in this context means "place it in a packet that goes | off-link". Yes, but it has to be there as an address, in a context where using it as an address would make sense. Beyond that the restriction would be absurd - it would prohibit particular bit patterns in jpeg files (or compressed data) for example... Anyone reading this who can't work that out for themselves is beyond hope. kre From owner-zeroconf@merit.edu Fri May 7 15:31:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15856 for ; Fri, 7 May 2004 15:31:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8DD091238; Fri, 7 May 2004 15:31:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AF91912EF; Fri, 7 May 2004 15:31:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6FFF891238 for ; Fri, 7 May 2004 15:31:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E5F458C0D; Fri, 7 May 2004 15:31:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id BB9D758B7C for ; Fri, 7 May 2004 15:31:15 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i47JV7019999 for ; Sat, 8 May 2004 02:31:07 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i47JV6DB013126 for ; Sat, 8 May 2004 02:31:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i47JOFXi000415; Sat, 8 May 2004 02:24:15 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL60] Forward reference style In-Reply-To: <200405070552.i475q4DX014218@relay1.apple.com> References: <200405070552.i475q4DX014218@relay1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 02:24:15 +0700 Message-ID: <13365.1083957855@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 May 2004 22:52:08 -0700 From: Stuart Cheshire Message-ID: <200405070552.i475q4DX014218@relay1.apple.com> | What possible reason would we have to NOT make an RFC as clear and | understandable as possible? None. And if you had raised some of you points when the doc was being debated, I'd be agreeing with more of them - even if it had been done during the last call. But that isn't what happened. Now it just looks like an attempt to delay a doc that you don't really like for as long as possible in the hopes that it will end up being so late as to be useless. Much better to publish what we have now. If necessary after experience with it, a clearer doc can be made part of advancing this from PS to DS (or whatever the standards process migrates into, assuming that it may eventually alter). That said, I actually don't agree that putting const definitions at the front makes the text easier to understand. For me, it makes it harder. When I see a bunch of definitions like that, I immediately find myself jumping to conclusions about how they're going to be used, and inventing my own imaginary protocol to use the things as I have dreamed them. That then makes actually understanding what is written harder, as I'm constantly prejudiced by my earlier imaginings about how the whole thing is going to work. So, even if there was some desire to make things better, and some text was going to be changed, the very most I'd want would be a forward reference in the introduction - something along the lines of "Symbolic constants will be used throughout this document, to determine the values of those constants, refer to section 9". And then, when I read the doc, initially (not actually doing an implementation) I avoid looking forward at the values, as 99% of the time, knowing the actual numbers helps with nothing (short of implementing it). But at this stage in the processing of this doc, I don't want even that. kre From owner-zeroconf@merit.edu Fri May 7 16:27:38 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18473 for ; Fri, 7 May 2004 16:27:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B0F191236; Fri, 7 May 2004 16:27:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CD5891238; Fri, 7 May 2004 16:27:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7553391236 for ; Fri, 7 May 2004 16:27:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 546C758B7C; Fri, 7 May 2004 16:27:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CC09D58DC9 for ; Fri, 7 May 2004 16:27:27 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i47KRH020818; Sat, 8 May 2004 03:27:17 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i47KRGDB006236; Sat, 8 May 2004 03:27:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i47KLNEO000713; Sat, 8 May 2004 03:21:24 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly In-Reply-To: <200405071746.i47HkdQp007221@relay4.apple.com> References: <200405071746.i47HkdQp007221@relay4.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 03:21:23 +0700 Message-ID: <5363.1083961283@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 7 May 2004 10:46:39 -0700 From: Stuart Cheshire Message-ID: <200405071746.i47HkdQp007221@relay4.apple.com> | Collisions do not cause loss on Ethernet. They did not on thick coax, | thin coax, or on UTP. Of course they don't - that was never the issue, once again, you're raising and dismissing a strawman. The problem is packet arrival and the ability of *every* host on the LAN to handle a packet train of length N - every host because they're all broadcast packets. And the same train in the same order every time. Typically there's at least one host on a LAN that has a fairly small threshold for N, before packets are dropped - and usually the same packets every time. If that host just happens to be the one that has the same address as the one being probed by the packet that is lost (on reception, not on the wire) every time, then the protocol fails. As Christian said, the implementation already has some kind of RNG (or PRNG), it has to to calculate the first random interval. Thus there's essentially no cost in using it every time (a few extra calculations, a multiply & modulus usually). There's a clear benefit, you don't get the same packet train every time, different packets get lost each retransmit. That allows the protocol to work. Get off this hobby horse, fine a better one. kre From owner-zeroconf@merit.edu Fri May 7 16:29:55 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18667 for ; Fri, 7 May 2004 16:29:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7293691238; Fri, 7 May 2004 16:29:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44335912F4; Fri, 7 May 2004 16:29:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60DC391238 for ; Fri, 7 May 2004 16:29:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CC9458EA7; Fri, 7 May 2004 16:29:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id C642658E4D for ; Fri, 7 May 2004 16:29:44 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i47KTb020862; Sat, 8 May 2004 03:29:37 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i47KTaDB012014; Sat, 8 May 2004 03:29:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i47KNgEO001561; Sat, 8 May 2004 03:23:42 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes In-Reply-To: <200405071751.i47HptxU014596@relay2.apple.com> References: <200405071751.i47HptxU014596@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 03:23:41 +0700 Message-ID: <2090.1083961421@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 7 May 2004 10:51:55 -0700 From: Stuart Cheshire Message-ID: <200405071751.i47HptxU014596@relay2.apple.com> | If we want this process to conclude, we need to sincerely work towards | agreement. If we seek every opportunity for disagreement, the process | could continue indefinitely. Somehow, you seem to have missed the process steps where we already had agreement, including a successful IETF last call. It was *done*. I don't mind fixing the bad grammar, and obvious typos, but would have hoped the RFC Editor would have found & corrected most of those anyway. More than that is just too late now. kre From owner-zeroconf@merit.edu Fri May 7 16:50:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19873 for ; Fri, 7 May 2004 16:50:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 47E6F912F4; Fri, 7 May 2004 16:50:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19244912F5; Fri, 7 May 2004 16:50:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15BBB912F4 for ; Fri, 7 May 2004 16:50:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE8B258AA9; Fri, 7 May 2004 16:50:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by segue.merit.edu (Postfix) with ESMTP id 7D59C58F37 for ; Fri, 7 May 2004 16:50:09 -0400 (EDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 13:50:14 -0700 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 May 2004 13:50:08 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 13:50:21 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 13:50:07 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 7 May 2004 13:50:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 13:50:06 -0700 Message-ID: Thread-Topic: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Thread-Index: AcQ0cfOyO28s4NG9QHOWmOlaoeL1bAAAPXvA From: "Christian Huitema" To: "Robert Elz" , "Stuart Cheshire" Cc: X-OriginalArrivalTime: 07 May 2004 20:50:06.0663 (UTC) FILETIME=[E0DCBD70:01C43474] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Stuart makes the point that throwing dices several times in sequence makes the sum more predictable. That is however not entirely true. The law of big numbers predicts that the standard deviation of the average is inversely proportional to the square root of the number of trials. However, we are not concerned here with the value of the average, but rather with the value of the sum. According to the law of big numbers, the standard deviation of the sum does not decrease: it increases proportionally to the square root of the number of trials.=20 In the case of N trials between 0 and 1 (first trial) or between 0.5 and 1.5 (successive trials) the average total delay will be 0.5*(N-1)+0.5*N =3D (N-1)+0.5; the average variance of this total delay will be N/4; the standard deviation of the last trial will be sqrt(N)/2. In the case of N trials where the first one is randomized between 0 and 1 and the later ones repeated 1 second after the 1st one, the average total delay will be 0.5 + (N-1); the average variance of the delay will be 1/4; the standard deviation will be 1/2. That is, a sum of multiple random picks does indeed result in more randomization than a single random pick.=20 -- Christian Huitema From owner-zeroconf@merit.edu Fri May 7 17:15:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21344 for ; Fri, 7 May 2004 17:15:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE63E912FC; Fri, 7 May 2004 17:12:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D698912FD; Fri, 7 May 2004 17:12:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77AC8912FC for ; Fri, 7 May 2004 17:12:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6697758F49; Fri, 7 May 2004 17:12:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 0861758C0C for ; Fri, 7 May 2004 17:12:15 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 0AAA81BB489 for ; Fri, 7 May 2004 22:12:17 +0100 (BST) Message-ID: <02f301c43477$f8fb2e20$131010ac@aldebaran> From: "Philip Nye" To: References: <200405071746.i47HkdQp007221@relay4.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 21:12:15 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Collisions do not cause loss on Ethernet. They did not on thick coax,=20 > thin coax, or on UTP. I quite thought Ethernet collisions were a thing of the past! it = certainly never occurred to me that they would give rise to higher layer = packet loss - what has this to do with IPv4LL? Large numbers of packets arriving simultaneously - or just a few in some = of the lightweight devices likely to use IPv4LL - can and does cause = packets to be dropped. If the same sequence of packets arrives each time = then the same ones are likely to be dropped each time. Philip From owner-zeroconf@merit.edu Fri May 7 17:25:19 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21771 for ; Fri, 7 May 2004 17:25:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5869F91236; Fri, 7 May 2004 17:25:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 260A9912F8; Fri, 7 May 2004 17:25:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03AD191236 for ; Fri, 7 May 2004 17:25:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0FDA58E1A; Fri, 7 May 2004 17:25:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 6AAA958C90 for ; Fri, 7 May 2004 17:25:09 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 07 May 2004 13:28:40 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i47LP6Su000274; Fri, 7 May 2004 14:25:07 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-103.cisco.com [10.86.240.103]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF94210; Fri, 7 May 2004 17:25:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20040507171835.0284b2d0@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 May 2004 17:21:27 -0400 To: Stuart Cheshire From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Cc: In-Reply-To: <200405071746.i47HkdQp007221@relay4.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart - can you explain which "collision myth" is referred to in the second paragraph. I think there are several. And, of course, you're right about my statement concerning multiple probes and randomization. The randomization of subsequent probes desynchronizes just the probe traffic... - Ralph At 10:46 AM 5/7/2004 -0700, Stuart Cheshire wrote: >Philip Nye wrote: > > >the chance we need to avoid is that you and I > >both agree on ALL FOUR values in our series. > >This is statement is asserted without any supporting evidence, and it is >false. > >This is NOT what we need to avoid. > >In order to be a good network citizen, we want to minimize the aggregate >peak load that a large number of hosts may impose on network >infrastructure, since peak load is what causes loss. This issue only >arises when there are a large number of hosts probing simultaneously. Two >hosts, or three, or four or even ten host probing at *exactly* the same >time is NOT a problem. > >The Ethernet collision loss myth has existed for decades. University >computer science lecturers teach students that it's a myth, but still the >myth persists in the larger population. > >Collisions do not cause loss on Ethernet. They did not on thick coax, >thin coax, or on UTP. > >Pay particular attention to the second paragraph below. > > > > > >What Vernon says is quite right and I'll only add that Collision sensing > >and recovery happens in times on the order of 200 uS to a few mS, on > >even extremely highly contended Ethernet segments (many stations ready > >with pkts to send all the time). This is far faster than Token passing > >(many mS), in any of its forms, as a very pertinent graph from the > >original IEEE 802 standarization simulations shows (it can be faxed to > >anyone who wishes a copy). This graph is particularly telling in that > >CSMA/CD become better in relation to Token as the number of contending > >nodes increases -- yes, better. > > > >One reason for trying to rid the world of 'collision' myths is that they > >serve as an alarm for how easily misinformation can arise and how hard > >it is to gather peoples' intellects together to stamp the myths out. > >Confining ourselves to networking, we must be aware that this applies in > >the TCP/IP realm as well. Back to the LAN realm, which the original IP > >world had no cognizance of, the collision myth, that started as an IBM > >marketing weapon, matured into a switch vendors' scare tactic to sell at > >first cut-through (a bad idea now in disrepute) and later "a segment for > >every node", so that "collisions would no longer occur" -- just pushing > >the problem into provisioning of the switch fabric. "Caveat emptor" is > >as necessary today as it has ever been. > >Ralph Droms wrote: > > >If there is no randomization of subsequent probes, there is no point in > >specifying multiple probes. > >No, this is false. > >We don't assume the ARP probes are the ONLY traffic on the network. > >The reason for trying three times is that there may be OTHER brief bursts >of traffic on the link that overflow the switch buffers (or cause CSMA/CD >breakdown, etc.) resulting in one or more probes being lost. > >In reality, the amount of traffic generated by ARP probing is too low by >itself to cause switch buffer overflow -- PROVIDING that it is >distributed over several seconds. Should all the probes be sent in a >tight bunch, then the chance of switch buffer overflow could become >non-zero, which is why the initial random delay is useful to eliminate >that. > >Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 17:33:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22118 for ; Fri, 7 May 2004 17:33:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2B7991238; Fri, 7 May 2004 17:32:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E67C912F4; Fri, 7 May 2004 17:32:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E06591238 for ; Fri, 7 May 2004 17:32:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 620A258DFD; Fri, 7 May 2004 17:32:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by segue.merit.edu (Postfix) with ESMTP id DADA858DEA for ; Fri, 7 May 2004 17:32:52 -0400 (EDT) Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47LWoC1019792 for ; Fri, 7 May 2004 14:32:50 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (che-vpn-cluster-1-103.cisco.com [10.86.240.103]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF94649; Fri, 7 May 2004 17:32:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20040507173106.00c78958@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 May 2004 17:32:30 -0400 To: From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL66] Additional statistical example In-Reply-To: <01f001c4342e$aa7c9d90$131010ac@aldebaran> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with Philip - and the concrete example can easily lead to interminable debate about the assumptions and details of the computation. I do not support making this change. - Ralph At 12:27 PM 5/7/2004 +0000, Philip Nye wrote: >I see no compelling need for an example here and it's too late in the day. > >Philip >----- Original Message ----- >From: "Erik Guttman" >To: >Sent: Tuesday, May 04, 2004 11:20 PM >Subject: WG ACTION: 2 weeks to discuss [LL66] Additional statistical example > > > > Please post discussion of this issue to the mailing list over the > > next two weeks > > ending May 18, 2004. In order to accept this issued, we will need a > strong WG > > consensus given that this is very late in the process. > > > > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of > > current issues and their status. > > > > [LL66] > > > > Description of Issue: Additional statistical example > > Submitter Name: Stuart Cheshire > > Submitter Email Address: cheshire@apple.com > > Date first submitted: 04 May 04 > > Reference: > > Comment Type ['t'ech|'e'dit]: t > > Prio ['S' Must|1 should|2 may]: 1 > > Section: 1.3 > > Rationale/Explanation: > > Lengthy Description: > > > > > When these address conflicts are detected, the subsequent forced > > > reconfiguration may be disruptive, causing TCP connections to be > > > broken. However, it is expected that such disruptions will be rare. > > > It should be relatively uncommon for networks to be joined while > > > hosts on those networks are active. Also, 65024 addresses are > > > available for IPv4 Link-Local use, so even when two small networks > > > are joined, the chance of collision for any given host is fairly > > > small. > > > > A specific example with numbers: If two 100-host networks are joined, > > there's still a better than 75% chance that not a single host on either > > network will have to select a new address. > > > > [Erik] > > > > There has been no demand in successive reviews for further example. > > > > [Stuart] > > > > I calculated specific numbers to substantiate the previously vague > > assertion. > > > > I believe concrete facts are more informative than vagueness. > > > > [Erik] > > > > Thanks for the numbers. My point is that we need to publish this > > document with as few changes as possible. This is not an editorial > > change. In my opinion 'fact' assertions generate a lot of debate. > > > > Requested Change: > > > > Add to section 1.3 > > > > This specification is intended for use with small ad-hoc networks - a > > single link containing only a few hosts. Although 65024 IPv4 Link- > > Local addresses are available in principle, attempting to use all > > those addresses on a single link would result a high probability of > > an address conflict, requiring a host to take an inordinate amount of > > time to find an available address. > > > > becomes > > > > This specification is intended for use with small ad-hoc networks - a > > single link containing only a few hosts. Although 65024 IPv4 Link- > > Local addresses are available in principle, attempting to use all > > those addresses on a single link would result a high probability of > > an address conflict, requiring a host to take an inordinate amount of > > time to find an available address. > > > > If two 100-host networks are joined, > > there's still a better than 75% chance that not a single host on either > > network will have to select a new address. > > From owner-zeroconf@merit.edu Fri May 7 17:33:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22139 for ; Fri, 7 May 2004 17:33:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 180CA912F4; Fri, 7 May 2004 17:33:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9565912F8; Fri, 7 May 2004 17:33:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E82A5912F4 for ; Fri, 7 May 2004 17:33:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D58C758DEA; Fri, 7 May 2004 17:33:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 98C5E58DB6 for ; Fri, 7 May 2004 17:33:27 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id D1F611BB443; Fri, 7 May 2004 22:33:29 +0100 (BST) Message-ID: <02f801c4347a$efa10c20$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405071751.i47HptxU014596@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL57] Straightforward editorial fixes Date: Fri, 7 May 2004 21:33:28 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > >several appear to be pedantic filibusters! >=20 > These are not filibusters, pedantic or otherwise. I apologise for any offence but having got the document through last = call and IESG approval and having thought that it had been "shipped" I = found it rather frustrating to be called back to debate the merits of = calling a section "Unintentional Autoimmune Response" rather than = "Unintentional Autoimmunity". > The filibuster here, if any, is the attitude, "There's nothing wrong = with=20 > this edit and it would improve the document, but I'm going to oppose = it=20 > anyway." It is quite correct to point out typographic mistakes such as the = "169.254.255" example you spotted. However, it is insulting to the group = on this list who have patiently debated through this document over = months and months and after the process is closed to attempt to reopen = debate over whether a different way to express something is "better" = than the way which has been agreed. There was a time for this and many = issues were debated to the satisfaction of all - that time has gone. There will always be scope in a document of this complexity to improve = readability or clarity - at least for some readers - but the test at = this point should not be "does this make it clearer?" but "is the = existing text wrong, imprecise or sufficiently confusing that a person = with reasonable experience of implementing protocols from specifications = will get it wrong". In my experience the current draft is more clear and = readable than a number of protocol specs I have had to follow. Philip From owner-zeroconf@merit.edu Fri May 7 17:50:13 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22833 for ; Fri, 7 May 2004 17:50:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5235912F8; Fri, 7 May 2004 17:50:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8657C912FF; Fri, 7 May 2004 17:50:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F3290912F8 for ; Fri, 7 May 2004 17:50:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9C1D58E08; Fri, 7 May 2004 17:50:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 8F1FF58DA7 for ; Fri, 7 May 2004 17:50:02 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id D123E1BB48C; Fri, 7 May 2004 22:50:04 +0100 (BST) Message-ID: <030501c4347d$40ad92d0$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405071752.i47HqMJv011664@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Fri, 7 May 2004 21:50:03 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Stuart Cheshire" > > > Field experience has shown that modifying the DHCP state machine > > in an attempt to make IPv4 Link-Local more reliable does not work > > - reliability of DHCP service is significantly reduced. >=20 > I have no objection to giving our best known advice: >=20 > > A device that implements both IPv4 Link-Local and a DHCPv4 client > > should not alter the behavior of the DHCPv4 client to = accommodate >=20 > My objection is to inventing fictitious "early implementations" or = "field=20 > experience" to apparently back up our advice. I had taken it on good faith in the original authors that it was the = case that this was based on experience - it has been there since before = I joined in. My experience with some Windows implementations certainly = suggests that the IPv4LL and DHCP are entangled but this is purely = anecdotal and could be caused by other things - I have no access to the = Windows code to confirm this or otherwise and would not want to. If you = are correct that it is fiction then I agree that this assertion could be = removed. However, why wasn't it weeded out at draft 2 or 3? > This is strangely topical -- the US president and the US and UK=20 > governments are taking a lot of criticism right now for the alleged=20 > fabrication of supporting evidence to justify their chosen course of=20 > action. So Stuart which side are you on? - are you with Dubya or are you with = the terrorists? (no you shouldn't answer!) Philip From owner-zeroconf@merit.edu Fri May 7 18:57:21 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26657 for ; Fri, 7 May 2004 18:57:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0708B912F8; Fri, 7 May 2004 18:57:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C43B2912FF; Fri, 7 May 2004 18:57:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E568E912F8 for ; Fri, 7 May 2004 18:57:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D161B58EFE; Fri, 7 May 2004 18:57:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 57A3558F60 for ; Fri, 7 May 2004 18:57:13 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i47MvCwb005860 for ; Fri, 7 May 2004 15:57:12 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 15:57:11 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i47MvAOQ005987 for ; Fri, 7 May 2004 15:57:10 -0700 (PDT) Message-Id: <200405072257.i47MvAOQ005987@relay2.apple.com> Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 15:57:10 -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 >Stuart makes the point that throwing dices several times in sequence >makes the sum more predictable. That is however not entirely true. Christian, we can answer this very simply. I gave a little picture showing the probability density function for the simple scheme as we had it two years ago: p| | | | ---------------- | | | | | | | | | |----|----|----|----|----|----| -1 0 1 2 3 4 time (seconds) Can you send us a little picture showing the probability density function for the scheme you're proposing? It has to be: (a) wider (takes longer to complete), or (b) taller (peak traffic burst is higher), or (c) both Which is it? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 18:58:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26679 for ; Fri, 7 May 2004 18:58:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CCB7912FF; Fri, 7 May 2004 18:57:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39F8E91300; Fri, 7 May 2004 18:57:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52ED0912FF for ; Fri, 7 May 2004 18:57:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F68E58F7E; Fri, 7 May 2004 18:57:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id C776C58F93 for ; Fri, 7 May 2004 18:57:53 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i47MvrTP006044 for ; Fri, 7 May 2004 15:57:53 -0700 (PDT) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 15:57:53 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay2.apple.com (8.12.11/8.12.11) with SMTP id i47Mvprn006104 for ; Fri, 7 May 2004 15:57:51 -0700 (PDT) Message-Id: <200405072257.i47Mvprn006104@relay2.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 15:57:52 -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 >Stuart - can you explain which "collision myth" is referred to >in the second paragraph. I think there are several. The unstated unconscious assumption in so much of the discussion on this mailing list that, if two machines send packets at the same time, then inevitably one or both get lost. If you re-read past discussion you'll see that it's never stated, but almost always assumed. To pick one recent example: >the chance we need to avoid is that >you and I both agree on ALL FOUR values in our series Why do we "need" to avoid this? The assumption behind that statement, and so many like it, is that it would be a catastrophe if two machines were to send at the same time, and consequently the protocol needs extra mechanisms to avoid this catastrophe. This assumption is felt to be so self-evident that it is never stated explicitly, just assumed as a universally accepted axiom. The fact is that spreading the first packet uniformly over a one-second interval offers a dramatic benefit by eliminating a potentially large synchronized burst. The faulty logic is to conclude from this, "If some randomness is good, then more randomness must be better, right?" Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 19:05:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27144 for ; Fri, 7 May 2004 19:05:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A56F91238; Fri, 7 May 2004 19:05:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63E7C91300; Fri, 7 May 2004 19:05:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A68591238 for ; Fri, 7 May 2004 19:04:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 679D758ED5; Fri, 7 May 2004 19:04:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by segue.merit.edu (Postfix) with ESMTP id 290A758E93 for ; Fri, 7 May 2004 19:04:59 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id i47N4wLR007082 for ; Fri, 7 May 2004 16:04:58 -0700 (PDT) Received: from relay4.apple.com (relay4.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 16:04:58 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay4.apple.com (8.12.11/8.12.11) with SMTP id i47N4uTb007213 for ; Fri, 7 May 2004 16:04:57 -0700 (PDT) Message-Id: <200405072304.i47N4uTb007213@relay4.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 16:04:57 -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 >If that host just happens to be the one that >has the same address as the one being probed by the packet that is >lost (on reception, not on the wire) every time, then the protocol >fails. Complete nonsense. Of course it doesn't fail. All this posturing ignores the fact that WE'VE BEEN SHIPPING PRODUCTS FOR SIX YEARS. This claimed failure is pure invention. In the vanishingly unlikely event of repeating identical packet loss, the conflict is subsequently detected and resolved a few seconds later when subsequent ARP packets are sent, and the hosts then pick new addresses and immediately re-probe. The real point is that increased randomness buys us nothing worthwhile, and has a cost, in the form of increased variability in total address acquisition time, which which impacts the layers below and above: Below: When a switch vendor asks, "How quickly do I have to bring port on line to be sure I don't miss all the ARP probes?" that answer becomes *shorter* than it would otherwise be. This tighter constraint may make the switch design harder. Above: When an application writer asks, "How long should I expect address acquisition to take, before concluding that there may be some unusual error condition?" that answer becomes *longer* than it would otherwise be. This longer timeout results in degraded user experience. These costs are paid by *every* host using IPv4LL, *every* time it has to acquire an address. And for what? To protect against an event that never happens, and wouldn't really matter even if it did. There's a famous old quote from Antoine de Saint-Exupery which applies to protocol design: >A designer knows he has achieved perfection not when there is >nothing left to add, but when there is nothing left to take away. I'm not trying to propose any radical new things here. I thought draft-07 was pretty good. My concerns are all the weird stuff that's appeared since then that no one can really justify, except with answers like, "I think someone else wanted it." Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 19:31:28 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28288 for ; Fri, 7 May 2004 19:31:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E73491301; Fri, 7 May 2004 19:30:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1351F91304; Fri, 7 May 2004 19:30:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1FB1291301 for ; Fri, 7 May 2004 19:30:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0336E58C90; Fri, 7 May 2004 19:30:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by segue.merit.edu (Postfix) with ESMTP id CBD4C58C6A for ; Fri, 7 May 2004 19:30:49 -0400 (EDT) Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id i47NV5xh016865 for ; Fri, 7 May 2004 16:31:05 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 7 May 2004 16:30:49 -0700 Received: from [17.219.196.100] ([17.219.196.100]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id i47NUjQ2012270 for ; Fri, 7 May 2004 16:30:46 -0700 (PDT) Message-Id: <200405072330.i47NUjQ2012270@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Fri, 7 May 2004 16:30:46 -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 >If you are correct that it is fiction then I agree that this assertion >could be removed. However, why wasn't it weeded out at draft 2 or 3? It was never in the early drafts. It seems to have appeared in draft-11, in January this year. >it is insulting to the group on this list who have patiently debated >through this document over months and months and after the process is >closed to attempt to reopen debate over whether a different way to >express something is "better" than the way which has been agreed. Please remember that I've been doing as long as anyone. I did the Mac OS 8.5 implementation, back in 1998, and I co-chaired the first NITS bof in 1999. If you're tired of this, think how I feel. At the end of the day, this is something I've been working on for six years now. That's a long time for a document that can basically be summed up as, "Pick an address and ARP to see if someone else is already using it." What I'd like to avoid is a Bay-of-Pigs type situation where someone points to a sentence or paragraph in the document and says, "What does that mean?" and none of us knows the answer. LL46 is a good example. The WG chair announced, "1 week to discuss [LL46]". Philip Nye wrote: >Personally, I don't think any of these changes are necessary - this >clearly appears in an "examples include" section and the next line >mentions wireless networking. Daniel Senie wrote: >In general I agree with you. Final resolution: "Action: Accept this change." Huh? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 7 20:21:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00097 for ; Fri, 7 May 2004 20:21:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7952912FC; Fri, 7 May 2004 20:21:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E646912FF; Fri, 7 May 2004 20:21:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C61E2912FC for ; Fri, 7 May 2004 20:21:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A449858F68; Fri, 7 May 2004 20:21:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id 4FBCC58F3D for ; Fri, 7 May 2004 20:21:37 -0400 (EDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 7 May 2004 17:21:11 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 7 May 2004 17:21:07 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 May 2004 17:21:35 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 7 May 2004 17:21:36 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 7 May 2004 17:21:35 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 7 May 2004 17:21:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Date: Fri, 7 May 2004 17:21:05 -0700 Message-ID: Thread-Topic: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly Thread-Index: AcQ0htBDn1XZxAWxSu6KiXIucscbgAACECww From: "Christian Huitema" To: "Stuart Cheshire" , X-OriginalArrivalTime: 08 May 2004 00:21:35.0271 (UTC) FILETIME=[6BDCAB70:01C43492] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Christian, we can answer this very simply. I gave a little picture > showing the probability density function for the simple scheme as we had > it two years ago: >=20 >=20 > p| > | > | > | ---------------- > | | | > | | | > | | | > |----|----|----|----|----|----| > -1 0 1 2 3 4 time (seconds) If I understand correctly, the scheme that you describe here assumes an initial spacing over 1 second, followed by two repetitions spaced one second apart. You measure the probability that a packet be sent on any given second. Since in your scheme each second is a perfect repeat of the previous one, the scheme is indeed flat. However, having each second be a perfect repeat of the previous one is not a very desirable characteristic. The scheme that I described would indeed have a different curve -- just as wide, but taller. It will however minimize the probability of collisions. If you do want a scheme that is also flat but random, then you can do the following: Wait R1 =3D random(0..1) before the 1st try; Wait R2 =3D 1+random(0..1)-R1 before the second try; Wait R3 =3D 2+random(0..1)-R2 before the third try. It produces the same flat distribution that you find desirable, without the correlation between the consecutive intervals. -- Christian Huitema From owner-zeroconf@merit.edu Fri May 7 21:35:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03374 for ; Fri, 7 May 2004 21:35:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32D9791307; Fri, 7 May 2004 21:34:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFF8E91306; Fri, 7 May 2004 21:34:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8939E91307 for ; Fri, 7 May 2004 21:34:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7437658C09; Fri, 7 May 2004 21:34:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id F09BB58D67 for ; Fri, 7 May 2004 21:34:53 -0400 (EDT) Received: from fuchsia.home (jade.coe.psu.ac.th [172.30.0.21]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i481Yg026594; Sat, 8 May 2004 08:34:42 +0700 (ICT) Received: from delta.noi.kre.to (delta.wi0.home [192.168.192.31]) by fuchsia.home with ESMTP id i481YfDB003716; Sat, 8 May 2004 08:34:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i481OBEO000629; Sat, 8 May 2004 08:24:11 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL62] Do not space probes randomly In-Reply-To: <200405072257.i47Mvprn006104@relay2.apple.com> References: <200405072257.i47Mvprn006104@relay2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 May 2004 08:24:11 +0700 Message-ID: <13769.1083979451@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 7 May 2004 15:57:52 -0700 From: Stuart Cheshire Message-ID: <200405072257.i47Mvprn006104@relay2.apple.com> | The unstated unconscious assumption in so much of the discussion on this | mailing list that, if two machines send packets at the same time, then | inevitably one or both get lost. Not two, two packets at the same time will almost never be "lost". Three on the other hand is a different issue entirely. Have three packets sent "at once" and some recipients I can guarantee you will fail to receive the one of them. | The fact is that spreading the first packet uniformly over a one-second | interval offers a dramatic benefit by eliminating a potentially large | synchronized burst. It changes one huge burst into a bunch of smaller bursts. The problem only goes away if you can somehow guarantee that the smaller bursts will be small enough (< 3 packets) or won't be repeated (so it does no real harm if the 2nd or 4rd packet of a burst is always lost). [From another message] | Complete nonsense. Of course it doesn't fail. All this posturing ignores | the fact that WE'VE BEEN SHIPPING PRODUCTS FOR SIX YEARS. On exactly how many crappy ancient ISA ethernet controllers? And on networks with such hosts and how many thousand nodes, all powering up at the same time? And tested how often? And now you're resorting to proof by "I haven't seen it fail" ? And ignoring other people who are telling you they have seen these kinds of failures? | In the vanishingly unlikely event of repeating | identical packet loss, the conflict is subsequently detected and resolved | a few seconds later when subsequent ARP packets are sent, and the hosts | then pick new addresses and immediately re-probe. And you know that subsequent ARP packets will be sent that soon just how? You're presuming that (at least) one of the hosts is going to want to send packets (soon) - what if they're both passive receivers? Then people trying to talk to them notice the conflict, when they arp for the address and get two replies, but just how do the hosts in question ever notice anything untoward? They each get all the ARP info they ever need in the ARP queries that seek their MAC addresses. | I'm not trying to propose any radical new things here. I thought draft-07 | was pretty good. My concerns are all the weird stuff that's appeared | since then that no one can really justify, except with answers like, "I | think someone else wanted it." Whatever you might have thought about draft-07, that isn't the one that went through IETF last call, and was approved by the IETF. You might have liked it, but clearly lots of other people didn't. 07 was a LONG time ago now. There has been lots of debate over lots of these issues in the intervening period - much of whioch you participated in. Some of those ended in outcomes that you obviously don't agree with. Live with it. The "I think..." is an incorrect summary of what was said about one particular issue, which was really "requested by the IESG". That text was basically noise as best I could tell, we could delete it, then the IESG would just say to put it in again. If your objective is to delay this doc forever, going round and round that circle would certainly do it. Most of us would prefer to have the thing published, and if the price of that is to include one meaningless noise sentence, to pacify some part of the IESG, then I think we can survive - that's much less that some other WG's have to do to get some docs past the IESG approval process. kre From owner-zeroconf@merit.edu Mon May 10 04:40:26 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17501 for ; Mon, 10 May 2004 04:40:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70B5E91243; Mon, 10 May 2004 04:40:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4451E91244; Mon, 10 May 2004 04:40:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B06291243 for ; Mon, 10 May 2004 04:40:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4826459185; Mon, 10 May 2004 04:40:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id C0B8F59179 for ; Mon, 10 May 2004 04:40:18 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 801481BB4A0; Mon, 10 May 2004 09:40:13 +0100 (BST) Message-ID: <02bb01c4366a$6ab50ce0$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405072330.i47NUjQ2012270@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Mon, 10 May 2004 08:40:15 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Stuart Cheshire" > > >If you are correct that it is fiction then I agree that this = assertion=20 > >could be removed. However, why wasn't it weeded out at draft 2 or 3? >=20 > It was never in the early drafts. >=20 > It seems to have appeared in draft-11, in January this year. You are correct here - sorry. You questioned the truth of the assertion in clause 2.11 that "early = implementations of IPv4 link-local have modified the DHCP state = machine...". The answer is in the document already - the latest draft = states in appendix A.3: "When in INIT state, the Windows 98/98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When no response is received after all 4 packets (24 seconds), it will autoconfigure an address." Windows at this point abandons its DHCP address whether or not it has a = valid lease. This is one of the things which Clause 2.11 is specifically = warning against and is a modifcation of the DHCP state machine to = accomodate IPv4LL autoconfiguration. The details for the Mac OS 8 and 9 also suggest that no attempt is made = to use a valid existing lease if a DHCP server is not found - favouring = IPv4LL. Philip From owner-zeroconf@merit.edu Mon May 10 04:44:26 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17587 for ; Mon, 10 May 2004 04:44:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73DF091244; Mon, 10 May 2004 04:44:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F4CF91246; Mon, 10 May 2004 04:44:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D9E991244 for ; Mon, 10 May 2004 04:44:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B3B759176; Mon, 10 May 2004 04:44:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id D31C15918E for ; Mon, 10 May 2004 04:44:17 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 8B9481BB4AA; Mon, 10 May 2004 09:44:18 +0100 (BST) Message-ID: <02c401c4366a$fcc070c0$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , References: <200405072330.i47NUjQ2012270@relay3.apple.com> Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific Date: Mon, 10 May 2004 08:44:20 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Stuart Cheshire" >=20 > What I'd like to avoid is a Bay-of-Pigs type situation where someone=20 > points to a sentence or paragraph in the document and says, "What does = > that mean?" and none of us knows the answer. >=20 > LL46 is a good example. >=20 > The WG chair announced, "1 week to discuss [LL46]". >=20 > Philip Nye wrote: >=20 > >Personally, I don't think any of these changes are necessary - this=20 > >clearly appears in an "examples include" section and the next line=20 > >mentions wireless networking. >=20 > Daniel Senie wrote: >=20 > >In general I agree with you. >=20 > Final resolution: "Action: Accept this change." >=20 > Huh? > What I'd like to avoid is a Bay-of-Pigs type situation where someone=20 > points to a sentence or paragraph in the document and says, "What does = > that mean?" and none of us knows the answer. >=20 > LL46 is a good example. >=20 > The WG chair announced, "1 week to discuss [LL46]". >=20 > Philip Nye wrote: >=20 > >Personally, I don't think any of these changes are necessary - this=20 > >clearly appears in an "examples include" section and the next line=20 > >mentions wireless networking. >=20 > Daniel Senie wrote: >=20 > >In general I agree with you. >=20 > Final resolution: "Action: Accept this change." I stand by my comment then and later. The extra phrase was added at the = request of the IESG. We could have pointed out to the person concerned = that the very next example mentioned wireless networks and asked whether = they thought their text was still necessary. For all I know this was = done? We could have spent an extra week or two (or three or four) = batting it around to get a better form of words, but in fact the meaning = of the text in question is clear enough and is not wrong. It does not = affect the protocol in any way - it is merely redundant in the opinion = of some (myself included). In these circumstances I was happy to see it = go through in the interests of closure - given that somebody else = thought it important. My frustration now is not with your argument over this text, it is with = your timing - LL46 was discussed and you had as much opportunity to = argue the point then as anyone else. The issue was closed and should not = be reopened unless the text is incorrect or likely to cause erroneous = implementations. This test definitely applies to some of the issues = which you have recently raised and I have supported them. Philip From owner-zeroconf@merit.edu Mon May 10 10:40:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08625 for ; Mon, 10 May 2004 10:40:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C3C569120A; Mon, 10 May 2004 10:40:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9784291235; Mon, 10 May 2004 10:40:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 919529120A for ; Mon, 10 May 2004 10:40:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7682A59194; Mon, 10 May 2004 10:40:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 254EA591C5 for ; Mon, 10 May 2004 10:40:02 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4AEdc6b006759; Mon, 10 May 2004 07:39:38 -0700 (PDT) Received: from suncc41 (suncc41 [129.157.142.41]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i4AEdbx7015053; Mon, 10 May 2004 16:39:37 +0200 (MEST) Date: Mon, 10 May 2004 16:40:06 +0200 (MEST) From: Erik Guttman X-Sender: erikg@suncc41 Reply-To: Erik Guttman To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL63] Text could be more specific In-Reply-To: <200405072330.i47NUjQ2012270@relay3.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, You left out the context of LL46. 1) I presented the IESG concerns to the WG for discussion 2) We worked with the IESG members and had an opportunity to dissent 3) We closed the discussion What is important in an IETF working group effort is to achieve at least a rough consensus in a timely manner. The process has been open, fair and must be binding. I am sure that if you had raised the point regarding the utility of the text in March, you could have worked something out with Russ. The point is, it is now too late for this unless you have strong support from the WG. We will make any changes needed to correct errors in the document that would prevent it from serving its intended purpose. *All* changes at this point must be passed with a strong WG consensus. The existing document with the agreed upon changes will be what is provided to the IESG as the WG's recommendation to publish as an RFC. If you feel that this process has not been correct according to the IETF procedures and policies you may of course appeal the output of the WG. Erik From owner-zeroconf@merit.edu Mon May 10 10:47:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08866 for ; Mon, 10 May 2004 10:47:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00D0391235; Mon, 10 May 2004 10:47:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8AB491243; Mon, 10 May 2004 10:47:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8D0591235 for ; Mon, 10 May 2004 10:47:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B263559151; Mon, 10 May 2004 10:47:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 3612C5911B for ; Mon, 10 May 2004 10:47:16 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4AElE6b010672 for ; Mon, 10 May 2004 07:47:15 -0700 (PDT) Received: from suncc41 (suncc41 [129.157.142.41]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with SMTP id i4AElDx7015329; Mon, 10 May 2004 16:47:13 +0200 (MEST) Date: Mon, 10 May 2004 16:47:42 +0200 (MEST) From: Erik Guttman X-Sender: erikg@suncc41 Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Erik Guttman Subject: Please comment on [LL67] and [LL61] Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The two most important changes in my mind are LL61 and LL67. These call for changes to the protocol to correct errors which entered the specification due to the change process. We have broad agreement so far that LL61 should be accepted, but only Philip Nye, myself and Stuart supporting LL67. Please take a good look at these issues and respond in the next week. Best regards and thanks for your assistance, Erik From owner-zeroconf@merit.edu Tue May 11 14:47:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15613 for ; Tue, 11 May 2004 14:47:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D4F429121D; Tue, 11 May 2004 14:47:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E84D91257; Tue, 11 May 2004 14:47:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E3849121D for ; Tue, 11 May 2004 14:47:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6AAA258E4D; Tue, 11 May 2004 14:47:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 1C83458DEF for ; Tue, 11 May 2004 14:47:14 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 10:53:08 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4BIlBW9000319 for ; Tue, 11 May 2004 11:47:12 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ39063; Tue, 11 May 2004 14:47:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20040511143937.02f143e8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 May 2004 14:42:58 -0400 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I don't think the new text correctly captures either of the behaviors we've discussed - I don't see where an initial delay is specified. I think this text is correct: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range 0 to INITIAL_DELAY seconds, and should then send NUM_PROBES probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. where INITIAL_DELAY is defined somewhere to be 1. - Ralph At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL61] > >Description of Issue: Remove initial wait >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: LL12 >Comment Type ['t'ech|'e'dit]: t >Prio ['S' Must|1 should|2 may]: S >Section: 2.2.1 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> When ready to begin probing, the host should then wait for a random >> time interval selected uniformly in the range PROBE_MIN 0 >> seconds, and should then send NUM_PROBES probe packets, spaced >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > >Why "wait for a random time interval selected uniformly in the range >PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial >one-second delay? It just slows things down. > >[Erik] > >This delay was intended to stop a set of hosts from beginning at the >same time in a 'LAN power up' situation. This text has passed all >reviews and numerous WG issues to revise and hone it. > >[Stuart] > >I was not asking about the [0,1] random interval. That's been there since >draft-05. > >I was asking about why it is now 1 + [0,1]. What's the extra fixed >one-second delay for? What is achieved by making the process uniformly >take a second longer than it should? > >[Erik] > > Hmm. Reviewing all records, I can't see how this entered the doc. > I don't have time for archeology to find out when it entered. I > don't see why waiting an extra second helps, except to wait for > network infrastructure to come up (see ll12). > >Requested Change: > >Text was: > > When ready to begin probing, the host should then wait for a random > time interval selected uniformly in the range PROBE_MIN to PROBE_MAX > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. > >Text becomes: > > When ready to begin probing, the host should send NUM_PROBES probe > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. From owner-zeroconf@merit.edu Tue May 11 14:47:37 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15650 for ; Tue, 11 May 2004 14:47:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93D9491257; Tue, 11 May 2004 14:47:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B15191258; Tue, 11 May 2004 14:47:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 066A491257 for ; Tue, 11 May 2004 14:47:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E3FBD58E50; Tue, 11 May 2004 14:47:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id A41B758E4D for ; Tue, 11 May 2004 14:47:17 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 11 May 2004 10:53:12 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4BIlBWD000319 for ; Tue, 11 May 2004 11:47:16 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ39067; Tue, 11 May 2004 14:47:10 -0400 (EDT) Message-Id: <4.3.2.7.2.20040511144652.02ee5c28@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 May 2004 14:47:07 -0400 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: WG ACTION: 2 weeks to discuss [LL67] Fix clause which forbids routable to LL communication In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I support the proposed change. - Ralph At 01:22 AM 5/5/2004 +0200, Erik Guttman wrote: >Please post discussion of this issue to the mailing list over the next two >weeks >ending May 18, 2004. In order to accept this issued, we will need a strong WG >consensus given that this is very late in the process. > >Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of >current issues and their status. > >[LL67] > >Description of Issue: Fix clause which forbids routable to LL >communication >Submitter Name: Stuart Cheshire >Submitter Email Address: cheshire@apple.com >Date first submitted: 04 May 04 >Reference: >Comment Type ['t'ech|'e'dit]: t >Prio ['S' Must|1 should|2 may]: S >Section: 6.2 >Rationale/Explanation: >Lengthy Description: > >[Stuart] > >> IPv4 Link-Local addresses MUST NOT be forwarded via an application >> protocol (for example in a URL), to a destination which is not Link- >> Local, on the same link. This is discussed further in Section 2.9 >> and 3. > >How about: >> IPv4 Link-Local addresses MUST NOT be forwarded via an application >> protocol (for example in a URL), to a destination which is not >> on the same link. This is discussed further in Section 2.9 and 3. > >[Erik] > >Your sentence means something entirely different than what is in the >document. In your text host A with LL address a could send 'a' in an >application protocol to host B with a routable address. In the current >document, this would not be allowed. We want proper interaction >between hosts A and B with as few restrictions as possible without >disruptive consequences. That is the fine line we've had to walk for >the past 5 years. I personally prefer your wording (and its meaning) to >what the document currently says. To open this up would require us to >go back to discussion, last calls, etc. however. > >[Stuart] > >As written, other places in the draft allow routable-to-LL communication, >but this "MUST NOT" prohibits that. A routable device can't send packets >to an LL device unless it knows the LL device's LL address, but how can a >routable device learn the LL device's LL address, if sending an LL >address to a non-LL destination address is prohibited? > >[Erik] > >This is clearly a technical revision we need to consider. I agree >that we should make this change. > >Requested Change: > >Section 6.2, From: > >> IPv4 Link-Local addresses MUST NOT be forwarded via an application >> protocol (for example in a URL), to a destination which is not Link- >> Local, on the same link. This is discussed further in Section 2.9 >> and 3. > >To: > >> IPv4 Link-Local addresses MUST NOT be forwarded via an application >> protocol (for example in a URL), to a destination which is not >> on the same link. This is discussed further in Section 2.9 and 3. From owner-zeroconf@merit.edu Tue May 11 15:43:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20629 for ; Tue, 11 May 2004 15:43:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E30529125C; Tue, 11 May 2004 15:43:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B08289125D; Tue, 11 May 2004 15:43:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75E639125C for ; Tue, 11 May 2004 15:43:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FC6E58FDE; Tue, 11 May 2004 15:43:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic.adaptec.com [216.52.22.17]) by segue.merit.edu (Postfix) with ESMTP id F07E259061 for ; Tue, 11 May 2004 15:43:02 -0400 (EDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id i4BHh1g31341; Tue, 11 May 2004 10:43:01 -0700 Received: from aime2k01.adaptec.com (aime2k01.adaptec.com [10.25.8.41]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id i4BJh2i10069; Tue, 11 May 2004 12:43:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Date: Tue, 11 May 2004 12:43:02 -0700 Message-ID: <70D0D0CAB1117740B92ABC760349069C01117576@aime2k01.adaptec.com> Thread-Topic: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait Thread-Index: AcQ3iGMn0nxsS4+RTdqQJ3MkY2OuxwAB+wtw From: "Elder, Alex" To: "Ralph Droms" , Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I concur with Ralph's wording. Caveat: The second half of it assumes no change to the random spacing between probes, which seems less than 100% settled. Assuming the random delays stand, this wording is good. -Alex > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > Behalf Of Ralph Droms > Sent: Tuesday, May 11, 2004 1:43 PM > To: zeroconf@merit.edu > Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait >=20 >=20 > I don't think the new text correctly captures either of the=20 > behaviors we've=20 > discussed - I don't see where an initial delay is specified. >=20 > I think this text is correct: >=20 > When ready to begin probing, the host should then wait=20 > for a random > time interval selected uniformly in the range 0 to INITIAL_DELAY > seconds, and should then send NUM_PROBES probe packets, spaced > randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 > where INITIAL_DELAY is defined somewhere to be 1. >=20 > - Ralph >=20 > At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote: > >Please post discussion of this issue to the mailing list=20 > over the next two=20 > >weeks > >ending May 18, 2004. In order to accept this issued, we=20 > will need a strong WG > >consensus given that this is very late in the process. > > > >Please see=20 > http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of > >current issues and their status. > > > >[LL61] > > > >Description of Issue: Remove initial wait > >Submitter Name: Stuart Cheshire > >Submitter Email Address: cheshire@apple.com > >Date first submitted: 04 May 04 > >Reference: LL12 > >Comment Type ['t'ech|'e'dit]: t > >Prio ['S' Must|1 should|2 may]: S > >Section: 2.2.1 > >Rationale/Explanation: > >Lengthy Description: > > > >[Stuart] > > > >> When ready to begin probing, the host should then wait=20 > for a random > >> time interval selected uniformly in the range PROBE_MIN 0 > >> seconds, and should then send NUM_PROBES probe packets, spaced > >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > >Why "wait for a random time interval selected uniformly in the range > >PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial > >one-second delay? It just slows things down. > > > >[Erik] > > > >This delay was intended to stop a set of hosts from beginning at the > >same time in a 'LAN power up' situation. This text has passed all > >reviews and numerous WG issues to revise and hone it. > > > >[Stuart] > > > >I was not asking about the [0,1] random interval. That's=20 > been there since > >draft-05. > > > >I was asking about why it is now 1 + [0,1]. What's the extra fixed > >one-second delay for? What is achieved by making the process=20 > uniformly > >take a second longer than it should? > > > >[Erik] > > > > Hmm. Reviewing all records, I can't see how this=20 > entered the doc. > > I don't have time for archeology to find out when it entered. I > > don't see why waiting an extra second helps, except to wait for > > network infrastructure to come up (see ll12). > > > >Requested Change: > > > >Text was: > > > > When ready to begin probing, the host should then wait=20 > for a random > > time interval selected uniformly in the range PROBE_MIN=20 > to PROBE_MAX > > seconds, and should then send NUM_PROBES probe packets, spaced > > randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > >Text becomes: > > > > When ready to begin probing, the host should send=20 > NUM_PROBES probe > > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. >=20 >=20 From owner-zeroconf@merit.edu Tue May 11 16:00:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21477 for ; Tue, 11 May 2004 16:00:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 731DD9125D; Tue, 11 May 2004 16:00:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E300291261; Tue, 11 May 2004 16:00:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 604C29125D for ; Tue, 11 May 2004 16:00:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 876C65909F; Tue, 11 May 2004 16:00:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by segue.merit.edu (Postfix) with ESMTP id 49C3F59089 for ; Tue, 11 May 2004 16:00:04 -0400 (EDT) Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4BJxtSw007430 for ; Tue, 11 May 2004 12:59:59 -0700 (PDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ46312; Tue, 11 May 2004 15:59:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20040511155322.02fa3428@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 May 2004 15:54:20 -0400 To: From: Ralph Droms Subject: RE: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait In-Reply-To: <70D0D0CAB1117740B92ABC760349069C01117576@aime2k01.adaptec. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Alex is correct - the second part of the text depends on the outcome of issue LL62, I guess... - Ralph At 12:43 PM 5/11/2004 -0700, Elder, Alex wrote: >I concur with Ralph's wording. > >Caveat: The second half of it assumes >no change to the random spacing between >probes, which seems less than 100% settled. >Assuming the random delays stand, this wording >is good. > > -Alex > > > -----Original Message----- > > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu]On > > Behalf Of Ralph Droms > > Sent: Tuesday, May 11, 2004 1:43 PM > > To: zeroconf@merit.edu > > Subject: Re: WG ACTION: 2 weeks to discuss [LL61] Remove initial wait > > > > > > I don't think the new text correctly captures either of the > > behaviors we've > > discussed - I don't see where an initial delay is specified. > > > > I think this text is correct: > > > > When ready to begin probing, the host should then wait > > for a random > > time interval selected uniformly in the range 0 to INITIAL_DELAY > > seconds, and should then send NUM_PROBES probe packets, spaced > > randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > where INITIAL_DELAY is defined somewhere to be 1. > > > > - Ralph > > > > At 01:07 AM 5/5/2004 +0200, Erik Guttman wrote: > > >Please post discussion of this issue to the mailing list > > over the next two > > >weeks > > >ending May 18, 2004. In order to accept this issued, we > > will need a strong WG > > >consensus given that this is very late in the process. > > > > > >Please see > > http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of > > >current issues and their status. > > > > > >[LL61] > > > > > >Description of Issue: Remove initial wait > > >Submitter Name: Stuart Cheshire > > >Submitter Email Address: cheshire@apple.com > > >Date first submitted: 04 May 04 > > >Reference: LL12 > > >Comment Type ['t'ech|'e'dit]: t > > >Prio ['S' Must|1 should|2 may]: S > > >Section: 2.2.1 > > >Rationale/Explanation: > > >Lengthy Description: > > > > > >[Stuart] > > > > > >> When ready to begin probing, the host should then wait > > for a random > > >> time interval selected uniformly in the range PROBE_MIN 0 > > >> seconds, and should then send NUM_PROBES probe packets, spaced > > >> randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > > >Why "wait for a random time interval selected uniformly in the range > > >PROBE_MIN to PROBE_MAX"? What's the benefit of enforcing an initial > > >one-second delay? It just slows things down. > > > > > >[Erik] > > > > > >This delay was intended to stop a set of hosts from beginning at the > > >same time in a 'LAN power up' situation. This text has passed all > > >reviews and numerous WG issues to revise and hone it. > > > > > >[Stuart] > > > > > >I was not asking about the [0,1] random interval. That's > > been there since > > >draft-05. > > > > > >I was asking about why it is now 1 + [0,1]. What's the extra fixed > > >one-second delay for? What is achieved by making the process > > uniformly > > >take a second longer than it should? > > > > > >[Erik] > > > > > > Hmm. Reviewing all records, I can't see how this > > entered the doc. > > > I don't have time for archeology to find out when it entered. I > > > don't see why waiting an extra second helps, except to wait for > > > network infrastructure to come up (see ll12). > > > > > >Requested Change: > > > > > >Text was: > > > > > > When ready to begin probing, the host should then wait > > for a random > > > time interval selected uniformly in the range PROBE_MIN > > to PROBE_MAX > > > seconds, and should then send NUM_PROBES probe packets, spaced > > > randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > > >Text becomes: > > > > > > When ready to begin probing, the host should send > > NUM_PROBES probe > > > packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. > > > > From owner-zeroconf@merit.edu Sun May 16 17:54:31 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23414 for ; Sun, 16 May 2004 17:54:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67B4291222; Sun, 16 May 2004 17:54:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B72591243; Sun, 16 May 2004 17:54:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41B2D91222 for ; Sun, 16 May 2004 17:54:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F610593EC; Sun, 16 May 2004 17:54:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8C6FB59353 for ; Sun, 16 May 2004 17:54:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GLvnN32379 for ; Sun, 16 May 2004 14:57:50 -0700 Date: Sun, 16 May 2004 14:57:49 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL52 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Agree with Ralph's suggested text: " The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]." From owner-zeroconf@merit.edu Sun May 16 17:54:55 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23432 for ; Sun, 16 May 2004 17:54:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87CD791243; Sun, 16 May 2004 17:54:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5763B91244; Sun, 16 May 2004 17:54:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FBD091243 for ; Sun, 16 May 2004 17:54:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 02BC7593EC; Sun, 16 May 2004 17:54:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 81D84593E9 for ; Sun, 16 May 2004 17:54:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GLwEY32417 for ; Sun, 16 May 2004 14:58:14 -0700 Date: Sun, 16 May 2004 14:58:14 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL53 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with proposed change B). From owner-zeroconf@merit.edu Sun May 16 17:55:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23456 for ; Sun, 16 May 2004 17:55:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 720EF91244; Sun, 16 May 2004 17:55:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F99991247; Sun, 16 May 2004 17:55:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47F6E91244 for ; Sun, 16 May 2004 17:55:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31ACB593F5; Sun, 16 May 2004 17:55:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id AF4A2593F8 for ; Sun, 16 May 2004 17:55:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GLwtc32452 for ; Sun, 16 May 2004 14:58:55 -0700 Date: Sun, 16 May 2004 14:58:55 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL54 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Agree with the proposed change. "Outside the scope of this document" is fine with me. From owner-zeroconf@merit.edu Sun May 16 17:55:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23474 for ; Sun, 16 May 2004 17:55:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D99AA91247; Sun, 16 May 2004 17:55:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A71DB91248; Sun, 16 May 2004 17:55:52 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B78F391247 for ; Sun, 16 May 2004 17:55:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6767593B0; Sun, 16 May 2004 17:55:51 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 31004593F8 for ; Sun, 16 May 2004 17:55:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GLxI732484 for ; Sun, 16 May 2004 14:59:18 -0700 Date: Sun, 16 May 2004 14:59:18 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL55 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the proposed change. From owner-zeroconf@merit.edu Sun May 16 17:56:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23499 for ; Sun, 16 May 2004 17:56:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 777EE91248; Sun, 16 May 2004 17:56:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4919291249; Sun, 16 May 2004 17:56:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5589B91248 for ; Sun, 16 May 2004 17:56:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F503593F4; Sun, 16 May 2004 17:56:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id B6603593B0 for ; Sun, 16 May 2004 17:56:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GLxkV32514 for ; Sun, 16 May 2004 14:59:46 -0700 Date: Sun, 16 May 2004 14:59:46 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL56 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with Stuart's proposed change: " IPv4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded to destinations outside the local link." From owner-zeroconf@merit.edu Sun May 16 17:56:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23517 for ; Sun, 16 May 2004 17:56:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C7BC91249; Sun, 16 May 2004 17:56:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE1D99124A; Sun, 16 May 2004 17:56:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A83491249 for ; Sun, 16 May 2004 17:56:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECA15593F5; Sun, 16 May 2004 17:56:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 77BDB593F8 for ; Sun, 16 May 2004 17:56:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GM05232559 for ; Sun, 16 May 2004 15:00:05 -0700 Date: Sun, 16 May 2004 15:00:05 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL57 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Agree with the proposed editorial changes. From owner-zeroconf@merit.edu Sun May 16 17:57:20 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23552 for ; Sun, 16 May 2004 17:57:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2612A9124A; Sun, 16 May 2004 17:57:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3AA89124B; Sun, 16 May 2004 17:57:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E7FDE9124A for ; Sun, 16 May 2004 17:57:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4996593F0; Sun, 16 May 2004 17:57:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 4759359407 for ; Sun, 16 May 2004 17:57:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GM0dn32713 for ; Sun, 16 May 2004 15:00:40 -0700 Date: Sun, 16 May 2004 15:00:39 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL58 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the proposed change as well as the terminology change proposed by Stuart: Replace This document uses the term "routable address" to refer to all unicast IPv4 addresses outside the 169.254/16 prefix, including global addresses and private addresses such as Net 10/8 [RFC1918], all of which may be forwarded via routers. with This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1 From owner-zeroconf@merit.edu Sun May 16 17:57:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23602 for ; Sun, 16 May 2004 17:57:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3ABF9124B; Sun, 16 May 2004 17:57:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B17A9124C; Sun, 16 May 2004 17:57:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A16289124B for ; Sun, 16 May 2004 17:57:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90A1F59402; Sun, 16 May 2004 17:57:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 1A929593F0 for ; Sun, 16 May 2004 17:57:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GM11j32722 for ; Sun, 16 May 2004 15:01:01 -0700 Date: Sun, 16 May 2004 15:01:01 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL59 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Agree with deleting the sentence. IEEE 802 technology includes wireless technologies such as 802.11, 802.15, 802.16, etc. so that the IESG concern is unfounded. From owner-zeroconf@merit.edu Sun May 16 17:58:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23620 for ; Sun, 16 May 2004 17:58:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 781C29124D; Sun, 16 May 2004 17:58:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49B719124E; Sun, 16 May 2004 17:58:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 540A39124D for ; Sun, 16 May 2004 17:58:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2CA35593F0; Sun, 16 May 2004 17:58:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 99CD559403 for ; Sun, 16 May 2004 17:58:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GM1WX32761 for ; Sun, 16 May 2004 15:01:32 -0700 Date: Sun, 16 May 2004 15:01:32 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL60 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I disagree with this change. There is no place that Section 9 could be moved within Section 1 that would not result in renumbering of the rest of Section 1. This would require changing references within the document which could introduce errors, requiring yet more changes and review. Given how far we are at this point, this kind of change is inappropriate. From owner-zeroconf@merit.edu Sun May 16 19:01:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27234 for ; Sun, 16 May 2004 19:01:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1003A91226; Sun, 16 May 2004 19:00:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFCE691229; Sun, 16 May 2004 19:00:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D2D891226 for ; Sun, 16 May 2004 19:00:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 62BD858CB0; Sun, 16 May 2004 19:00:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 88E52593B9 for ; Sun, 16 May 2004 19:00:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GN3pv03976 for ; Sun, 16 May 2004 16:03:51 -0700 Date: Sun, 16 May 2004 16:03:51 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL63 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk It is true that the additional paragraph doesn't make much sense: " Several early implementations of IPv4 Link-Local have modified the DHCP state machine in an attempt to make IPv4 Link-Local more reliable, and the field experience we have gained from this has shown that it does not work - reliability of DHCP service is significantly reduced. If increased reliability of IPv4 Link-Local is desired, we recommend that the IPv4 Link-Local state machine track the DHCP client state machine and, in cases where it is not certain that the DHCP-assigned address is correct, the IPv4 Link-Local state machine acquire an IPv4 Link-Local address without causing the DHCP state machine to relinquish its address." Appendix A provides several examples of behavior that is not conformant with RFC 2131 in *both* MacOS and Windows. So saying that the DHCP state machine was modified is correct, although it seems somewhat odd to attribute this to an "attempt to make IPv4 Link-Local more reliable"; more likely it came out of a desire to reduce address assignment delays. Advising that the IPv4 Link-Local state machine track the DHCP state machine seems strange at best. It does make sense to assign an IPv4 Link-Local address early on (which addresses the assignment time issue), but there is more to this than is described here, so it's best to leave it out. Here is a proposed fix: "As documented in Appendix A, early implementations of IPv4 Link-Local have modified the DHCP state machine. Field experience shows that these modifications reduce the reliability of the DHCP service. A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. Further discussion of this issue is provided in [DNAv4]." ------------------------------------------------------------------------- Examples of non-conformance to RFC 2131: A.1: " Mac OS sends nine DHCPDISCOVER packets, with an interval of two seconds between packets. If no response is received from any of these requests (18 seconds), it will autoconfigure." " Autoconfigured Mac OS systems check for the presence of a DHCP server every five minutes. If a DHCP server is found but Mac OS is not successful in obtaining a new lease, it keeps the existing autoconfigured IP address. " A.2: "DHCP sends two packets, with timeouts of one and two seconds. If no response is received (three seconds), it begins autoconfiguration. DHCP continues sending packets in parallel for a total time of 60 seconds." " If DHCP is not successful, it waits five minutes before starting over again. " A.3: " When in INIT state, the Windows 98/98SE DHCP Client sends out a total of 4 DHCPDISCOVERs, with an inter-packet interval of 6 seconds. When no response is received after all 4 packets (24 seconds), it will autoconfigure an address." " Autoconfigured Windows 98/98SE systems check for the presence of a DHCP server every five minutes." A.4: From owner-zeroconf@merit.edu Sun May 16 19:03:51 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27408 for ; Sun, 16 May 2004 19:03:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 873DF91229; Sun, 16 May 2004 19:03:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 366969122A; Sun, 16 May 2004 19:03:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 368A391229 for ; Sun, 16 May 2004 19:03:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20848593B6; Sun, 16 May 2004 19:03:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 9E90B5938B for ; Sun, 16 May 2004 19:03:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GN79s04164 for ; Sun, 16 May 2004 16:07:09 -0700 Date: Sun, 16 May 2004 16:07:08 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL64 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I'm ok with this proposed change. From owner-zeroconf@merit.edu Sun May 16 19:16:19 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27909 for ; Sun, 16 May 2004 19:16:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7948E9122A; Sun, 16 May 2004 19:15:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D0719122C; Sun, 16 May 2004 19:15:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 471799122A for ; Sun, 16 May 2004 19:15:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31FEF58FBA; Sun, 16 May 2004 19:15:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 92FEB5924C for ; Sun, 16 May 2004 19:15:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GNJJ204899 for ; Sun, 16 May 2004 16:19:20 -0700 Date: Sun, 16 May 2004 16:19:19 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL70 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I do not believe that [DNAv4] should be a normative reference. However, the text in question does seem to mandate the DNAv4 reachability test: " For these reasons, a host SHOULD NOT have both a valid routable address and an IPv4 Link-Local address configured on the same interface. A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]." In this text, it does not seem to me to make any difference whether the routable address has passed a reachability test or not. For example, would it be ok for the host to have a routable address and an IPv4 Link-Local address configured on the same interface if the routable address did *not* pass the reachability test? Since that doesn't make sense either, the use of the term "valid" (and it's definition, which by the way is not the same as in [DNAv4]) is not required. Suggest this be changed to: "For these reasons, a host SHOULD NOT have both a routable address and an IPv4 Link-Local address configured on the same interface." Keep the [DNAv4] reference informative. From owner-zeroconf@merit.edu Sun May 16 19:19:41 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28082 for ; Sun, 16 May 2004 19:19:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1EF59122C; Sun, 16 May 2004 19:19:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93AC89124E; Sun, 16 May 2004 19:19:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A40829122C for ; Sun, 16 May 2004 19:19:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C3AB593CE; Sun, 16 May 2004 19:19:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 087FF593B9 for ; Sun, 16 May 2004 19:19:32 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GNMxg05080 for ; Sun, 16 May 2004 16:22:59 -0700 Date: Sun, 16 May 2004 16:22:58 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL65 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I don't support the proposed change. Running claim and defend independently will address the issue. The specification need not mandate more. From owner-zeroconf@merit.edu Sun May 16 19:25:32 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28467 for ; Sun, 16 May 2004 19:25:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E4869124E; Sun, 16 May 2004 19:25:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49C409124F; Sun, 16 May 2004 19:25:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C5BE9124E for ; Sun, 16 May 2004 19:25:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 476F3593D4; Sun, 16 May 2004 19:25:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id BD2D9593EB for ; Sun, 16 May 2004 19:25:21 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4GNSn905402 for ; Sun, 16 May 2004 16:28:49 -0700 Date: Sun, 16 May 2004 16:28:48 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL67 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the proposed change. Other places in the document allow LL to Routable communication. From owner-zeroconf@merit.edu Tue May 18 05:54:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29459 for ; Tue, 18 May 2004 05:54:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C50691214; Tue, 18 May 2004 05:54:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35E8991261; Tue, 18 May 2004 05:54:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D6FE91214 for ; Tue, 18 May 2004 05:54:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC056593CE; Tue, 18 May 2004 05:54:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from muse.localhost (c211-30-41-6.randw1.nsw.optusnet.com.au [211.30.41.6]) by segue.merit.edu (Postfix) with ESMTP id D355058EAA for ; Tue, 18 May 2004 05:54:13 -0400 (EDT) Received: from nicta.com.au (localhost [127.0.0.1]) by muse.localhost (Postfix) with ESMTP id 01E8E999FC; Mon, 17 May 2004 12:17:02 +1000 (EST) Message-ID: <40A8209E.6070606@nicta.com.au> Date: Mon, 17 May 2004 12:17:02 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 2 weeks to discuss [LL67] Fix clause which forbids routable to LL communication References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I support the proposed change. - aidan Erik Guttman wrote: > Please post discussion of this issue to the mailing list over the > next two weeks > ending May 18, 2004. In order to accept this issued, we will need a strong WG > consensus given that this is very late in the process. > > Please see http://www.drizzle.org/~aboba/ZEROCONF/issues.html for a list of > current issues and their status. > > [LL67] > > Description of Issue: Fix clause which forbids routable to > LL communication > Submitter Name: Stuart Cheshire > Submitter Email Address: cheshire@apple.com > Date first submitted: 04 May 04 > Reference: > Comment Type ['t'ech|'e'dit]: t > Prio ['S' Must|1 should|2 may]: S > Section: 6.2 > Rationale/Explanation: > Lengthy Description: > > [Stuart] > > > IPv4 Link-Local addresses MUST NOT be forwarded via an application > > protocol (for example in a URL), to a destination which is not Link- > > Local, on the same link. This is discussed further in Section 2.9 > > and 3. > > How about: > > IPv4 Link-Local addresses MUST NOT be forwarded via an application > > protocol (for example in a URL), to a destination which is not > > on the same link. This is discussed further in Section 2.9 and 3. > > [Erik] > > Your sentence means something entirely different than what is in the > document. In your text host A with LL address a could send 'a' in an > application protocol to host B with a routable address. In the current > document, this would not be allowed. We want proper interaction > between hosts A and B with as few restrictions as possible without > disruptive consequences. That is the fine line we've had to walk for > the past 5 years. I personally prefer your wording (and its meaning) to > what the document currently says. To open this up would require us to > go back to discussion, last calls, etc. however. > > [Stuart] > > As written, other places in the draft allow routable-to-LL communication, > but this "MUST NOT" prohibits that. A routable device can't send packets > to an LL device unless it knows the LL device's LL address, but how can a > routable device learn the LL device's LL address, if sending an LL > address to a non-LL destination address is prohibited? > > [Erik] > > This is clearly a technical revision we need to consider. I agree > that we should make this change. > > Requested Change: > > Section 6.2, From: > > > IPv4 Link-Local addresses MUST NOT be forwarded via an application > > protocol (for example in a URL), to a destination which is not Link- > > Local, on the same link. This is discussed further in Section 2.9 > > and 3. > > To: > > > IPv4 Link-Local addresses MUST NOT be forwarded via an application > > protocol (for example in a URL), to a destination which is not > > on the same link. This is discussed further in Section 2.9 and 3. > From owner-zeroconf@merit.edu Tue May 18 12:44:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26565 for ; Tue, 18 May 2004 12:44:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E199F9123D; Tue, 18 May 2004 12:44:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF5099123E; Tue, 18 May 2004 12:44:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86C7E9123D for ; Tue, 18 May 2004 12:44:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74B8F592F1; Tue, 18 May 2004 12:44:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8A1305924C for ; Tue, 18 May 2004 12:44:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4IGlNW24481 for ; Tue, 18 May 2004 09:47:23 -0700 Date: Tue, 18 May 2004 09:47:23 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: LL70: Use of the term "valid" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk In looking over Issue LL70, I've come to the conclusion that the term "valid" is used gratuitously in several places, and that in several cases the term can be removed without doing damage. If this is done, I think that a normative reference to [DNAv4] will not be required. Section 1.9: "For these reasons, a host SHOULD NOT have both a valid routable address and a Link-Local IPv4 address configured on the same interface." I don't think the term "valid" is useful here. If the routable address is invalid then it should not be configured. The term can be deleted without changing the meaning. " A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]." This definition belongs in the terminology section, not here and in any case it differs from the definition used in [DNAv4]. Recommend adding the following definition to Section 1.2: "A "valid routable address" is a routable address which is either statically assigned or whose lease has not expired and that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]." " When an interface has a valid routable address configured on an interface, the host SHOULD NOT also assign a Link-Local IPv4 address to that interface." Again, the term "valid" is not helpful. A host shouldn't have an invalid address assigned on an interface, so the term "valid" has no use here either. " If a host finds that an interface that was previous configured with a Link-Local IPv4 address is now configured with a valid routable address, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the Link-Local IPv4 address through whatever mechanisms that address had been made known to others." Again, the term "valid" is not needed here -- if the host has a routable address configured, that's enough. "Ways in which a valid routable address might be configured for the interface include: * Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which a routable address assigned to the interface is valid If a host finds that an interface that was previously configured with a valid routable address no longer has a valid routable address, the host MAY identify a usable Link-Local IPv4 address (as described in section 2) and assign that address to the interface. Ways in which a valid routable address might no longer be assigned to an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid." Here several uses of the term "valid" are not helpful. Recommend changing to: " Ways in which a routable address might be configured for the interface include: * Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which the host has a valid routable address If a host finds that a routable address is no longer assigned to an interface, the host MAY identify a usable Link-Local IPv4 address (as described in section 2) and assign that address to the interface. Ways in which a routable address might no longer be assigned to an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid." From owner-zeroconf@merit.edu Tue May 18 13:15:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28364 for ; Tue, 18 May 2004 13:15:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A89D9126A; Tue, 18 May 2004 13:12:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 239B091273; Tue, 18 May 2004 13:12:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8467F9126A for ; Tue, 18 May 2004 13:12:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6912D59169; Tue, 18 May 2004 13:12:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from smtp804.mail.sc5.yahoo.com (smtp804.mail.sc5.yahoo.com [66.163.168.183]) by segue.merit.edu (Postfix) with SMTP id 3C00D593BF for ; Tue, 18 May 2004 13:12:37 -0400 (EDT) Received: from unknown (HELO SERVER.PacBell.net) (Celeborn@PacBell.net@63.199.7.253 with login) by smtp804.mail.sc5.yahoo.com with SMTP; 18 May 2004 17:12:12 -0000 Message-Id: <6.1.0.6.2.20040518095929.028e1860@POP.PacBell.Yahoo.com> X-Sender: Celeborn@PacBell.net@POP.PacBell.Yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 18 May 2004 10:12:11 -0700 To: Zero Configuration From: Peter Johansson Subject: Re: LL70: Use of the term "valid" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:47 AM 5/18/2004 -0700, Bernard Aboba wrote: >"A "valid routable address" is a routable address which is either >statically assigned or whose lease has not expired and that passes the >reachability test described in section 2 of "Detection of Network >Attachment (DNA) in IPv4" [DNAv4]." I would go the extra step and say: "A routable address is an address that is either statically assigned or whose lease has not expired and that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]." Please also note the grammatical correction, "which" to "that". Is there any risk that some readers will parse "(static or unexpired) and reachable" as "static or (unexpired and reachable)"? If so, you might consider reordering: "A routable address is an address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4] and is either statically assigned or one whose lease is unexpired." 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 Tue May 18 16:34:37 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14884 for ; Tue, 18 May 2004 16:34:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4AF8991277; Tue, 18 May 2004 16:34:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2163D91278; Tue, 18 May 2004 16:34:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6432591277 for ; Tue, 18 May 2004 16:34:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CF1E59326; Tue, 18 May 2004 16:34:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id AC6AE5929A for ; Tue, 18 May 2004 16:34:08 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 1DB241BB4CD for ; Tue, 18 May 2004 21:34:07 +0100 (BST) Message-ID: <001c01c43d17$86e456b0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <6.1.0.6.2.20040518095929.028e1860@POP.PacBell.Yahoo.com> Subject: Re: LL70: Use of the term "valid" Date: Tue, 18 May 2004 21:34:32 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Peter Johansson" > At 09:47 AM 5/18/2004 -0700, Bernard Aboba wrote: >=20 > >"A "valid routable address" is a routable address which is either=20 > >statically assigned or whose lease has not expired and that passes = the > >reachability test described in section 2 of "Detection of Network=20 > >Attachment (DNA) in IPv4" [DNAv4]." >=20 > I would go the extra step and say: "A routable address is an address = that=20 > is either statically assigned or whose lease has not expired and that=20 > passes the reachability test described in section 2 of "Detection of=20 > Network Attachment (DNA) in IPv4" [DNAv4]." If this change is made, we are back to square one - the protocol depends = on the definition of a routable address and that definition depends on = the reference [DNAv4] which is therefore normative - and is problematic = because it is an unapproved draft. I think that the use of "valid" conveys meaning because it helps people = grasp the idea that a host may have been configured with an address = which was previously valid but although still configured, is no longer = useable because the network has changed (e.g. the host moved to a new = network). This is a common case and there is often good reason not to = simply unconfigure that address because the host may soon be moved back = to a context in which it is valid - meanwhile assigning an IPv4LL = address provides some connectivity. The validity of a configured address is difficult to establish because = the context in which it is intended to operate or becomes invalid can = vary. Therefore I think that all we can do is explain the concept and = present the DNAv4 reachability test as a useful example (informative) = rather than a definition (normative) of validity. I suggested alternative text in an earlier email. > Please also note the grammatical correction, "which" to "that". I would dispute that English grammar is so clear cut. In this context = "that" or "which" both seem acceptable and either conveys the meaning = well so I can happily accept your ammendment - or not. Philip From owner-zeroconf@merit.edu Tue May 18 17:44:46 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20966 for ; Tue, 18 May 2004 17:44:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01A009127E; Tue, 18 May 2004 17:44:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF4819127F; Tue, 18 May 2004 17:44:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A10DC9127E for ; Tue, 18 May 2004 17:44:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C56B5942E; Tue, 18 May 2004 17:44:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by segue.merit.edu (Postfix) with ESMTP id 2D9F55930D for ; Tue, 18 May 2004 17:44:32 -0400 (EDT) Received: from JenEric (adsl-63-202-21-141.dsl.snfc21.pacbell.net [63.202.21.141]) by mta4.rcsntx.swbell.net (8.12.10/8.12.10) with ESMTP id i4ILiVsR001002 for ; Tue, 18 May 2004 16:44:31 -0500 (CDT) Message-ID: <00af01c43d21$dfd35280$6d01a8c0@JenEric> Reply-To: "Jim Busse" From: "Jim Busse" To: "Zeroconf Working Group" References: <6.1.0.6.2.20040518095929.028e1860@POP.PacBell.Yahoo.com> <001c01c43d17$86e456b0$131010ac@aldebaran> Subject: Re: LL70: Use of the term "valid" Date: Tue, 18 May 2004 14:48:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Because of the lack of subordination betweeen the "and" and the "or" conjuctions, a programmer may interpret the text differently from a marketeer. And I'm not sure which version is "right", so wording clarification I believe is necessary. Philip's change removes this issue but doesn't fix my implementation question. Just to clarify my understanding, If the reachability test described in DNAv4 is skipped, or fails, then IPv4LL can't have a "valid" address, simply it will have a "routable" address. In that event, I may assign an IPv4LL address additionally on that interface, right? Best regards Jim Busse ----- Original Message ----- From: "Philip Nye" To: "Zeroconf Working Group" Sent: Tuesday, May 18, 2004 1:34 PM Subject: Re: LL70: Use of the term "valid" > From: "Peter Johansson" > At 09:47 AM 5/18/2004 -0700, Bernard Aboba wrote: > > >"A "valid routable address" is a routable address which is either > >statically assigned or whose lease has not expired and that passes the > >reachability test described in section 2 of "Detection of Network > >Attachment (DNA) in IPv4" [DNAv4]." > > I would go the extra step and say: "A routable address is an address that > is either statically assigned or whose lease has not expired and that > passes the reachability test described in section 2 of "Detection of > Network Attachment (DNA) in IPv4" [DNAv4]." If this change is made, we are back to square one - the protocol depends on the definition of a routable address and that definition depends on the reference [DNAv4] which is therefore normative - and is problematic because it is an unapproved draft. I think that the use of "valid" conveys meaning because it helps people grasp the idea that a host may have been configured with an address which was previously valid but although still configured, is no longer useable because the network has changed (e.g. the host moved to a new network). This is a common case and there is often good reason not to simply unconfigure that address because the host may soon be moved back to a context in which it is valid - meanwhile assigning an IPv4LL address provides some connectivity. The validity of a configured address is difficult to establish because the context in which it is intended to operate or becomes invalid can vary. Therefore I think that all we can do is explain the concept and present the DNAv4 reachability test as a useful example (informative) rather than a definition (normative) of validity. I suggested alternative text in an earlier email. > Please also note the grammatical correction, "which" to "that". I would dispute that English grammar is so clear cut. In this context "that" or "which" both seem acceptable and either conveys the meaning well so I can happily accept your ammendment - or not. Philip From owner-zeroconf@merit.edu Tue May 18 17:55:47 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21322 for ; Tue, 18 May 2004 17:55:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8901C9127F; Tue, 18 May 2004 17:55:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5276591280; Tue, 18 May 2004 17:55:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7132E9127F for ; Tue, 18 May 2004 17:55:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E2555940B; Tue, 18 May 2004 17:55:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from smtp810.mail.sc5.yahoo.com (smtp810.mail.sc5.yahoo.com [66.163.170.80]) by segue.merit.edu (Postfix) with SMTP id D3CDE59262 for ; Tue, 18 May 2004 17:55:35 -0400 (EDT) Received: from unknown (HELO SERVER.PacBell.net) (Celeborn@PacBell.net@63.199.7.253 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 18 May 2004 20:51:40 -0000 Message-Id: <6.1.0.6.2.20040518134454.02cf55b0@POP.PacBell.Yahoo.com> X-Sender: Celeborn@PacBell.net@POP.PacBell.Yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.0.6 Date: Tue, 18 May 2004 13:51:39 -0700 To: Zero Configuration From: Peter Johansson Subject: Re: LL70: Use of the term "valid" In-Reply-To: <001c01c43d17$86e456b0$131010ac@aldebaran> References: <6.1.0.6.2.20040518095929.028e1860@POP.PacBell.Yahoo.com> <001c01c43d17$86e456b0$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:34 PM 5/18/2004 +0100, Philip Nye wrote: >I think that the use of "valid" conveys meaning because it helps people >grasp the idea that a host may have been configured with an address which >was previously valid but although still configured, is no longer useable >because the network has changed (e.g. the host moved to a new network). >This is a common case and there is often good reason not to simply >unconfigure that address because the host may soon be moved back to a >context in which it is valid - meanwhile assigning an IPv4LL address >provides some connectivity.paragraph I most emphatically do NOT wish to impede progress (in particular, since I have been an interested observer and not a contributor), but "valid" does not convey any meaning beyond what "routable" conveys. I understand your example and the difficulty caused by lack of normative text to reference---but I suggest you improve matters by adequately explaining what "routable" means in the context of your draft. I agree with Bernard that "valid" is white noise. >The validity of a configured address is difficult to establish because the >context in which it is intended to operate or becomes invalid can vary. >Therefore I think that all we can do is explain the concept and present >the DNAv4 reachability test as a useful example (informative) rather than >a definition (normative) of validity. Sounds like a good idea to me---but do it in the context of "routable" rather than "valid". 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 Tue May 18 18:23:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24637 for ; Tue, 18 May 2004 18:23:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5085E91292; Tue, 18 May 2004 18:22:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2263D912C1; Tue, 18 May 2004 18:22:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92A4891292 for ; Tue, 18 May 2004 18:22:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CC9559404; Tue, 18 May 2004 18:22:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id AC811591EF for ; Tue, 18 May 2004 18:22:16 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4IMPWQ12160 for ; Tue, 18 May 2004 15:25:32 -0700 Date: Tue, 18 May 2004 15:25:32 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL70: Use of the term "valid" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Philip Nye said: >I think that the use of "valid" conveys meaning because it helps people >grasp the idea that a host may have been configured with an address which >was previously valid but although still configured, is no longer useable >because the network has changed (e.g. the host moved to a new network). >This is a common case and there is often good reason not to simply >unconfigure that address because the host may soon be moved back to a >context in which it is valid - meanwhile assigning an IPv4LL address >provides some connectivity. I think there is a distinction between "configured" and "useable". I'm not entirely clear what "useable" means here -- is this an address that is configured, but might be only useable for receiving but not sending packets? If so, then it might make more sense to talk about "active" or "deprecated" addresses than "valid" ones. >The validity of a configured address is difficult to establish because >the context in which it is intended to operate or becomes invalid can >vary. Therefore I think that all we can do is explain the concept and >present the DNAv4 reachability test as a useful example (informative) rather than >a definition (normative) of validity. [DNAv4] uses the reachability test to determine whether to do DHCPv4 or not, not to decide "validity" as discussed here. It could be that a configured IPv4 routable address fails the reachability test, because the default gateway failed, but then a subsequent DHCPDISCOVER obtains the same IP address, but a different default gateway. In this case configuring an IPv4 LL address in between the reachability test and the DHCP conversation would be a bad idea. I'm somewhat uncomfortable with where the spec is going with some of these considerations because while it is citing [DNAv4], the implied behavior is not in sync with that document. From owner-zeroconf@merit.edu Tue May 18 18:31:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25161 for ; Tue, 18 May 2004 18:31:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76EC99123F; Tue, 18 May 2004 18:30:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A7CB91276; Tue, 18 May 2004 18:30:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A9039123F for ; Tue, 18 May 2004 18:30:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 218AE590C1; Tue, 18 May 2004 18:30:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8826C59007 for ; Tue, 18 May 2004 18:30:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4IMY9e12720 for ; Tue, 18 May 2004 15:34:09 -0700 Date: Tue, 18 May 2004 15:34:09 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL70: Use of the term "valid" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Jim Busse said: "Just to clarify my understanding, If the reachability test described in DNAv4 is skipped, or fails, then IPv4LL can't have a "valid" address, simply it will have a "routable" address. In that event, I may assign an IPv4LL address additionally on that interface, right?" This might not be a good idea if it's likely that a routable address will eventually be assigned, since it will cause excessive address changes. For example in IEEE 802.11, it could be that the reachability test failed because of packet loss and a subsequent DHCPDISCOVER would succeed. Is it helpful to have an IPv4LL address assigned so as to cause existing connections to go down? Not necessarily. In general, the recommended practice is for the host to only assign an IPV4LL address when it is "likely" that no routable address will be assigned. This could occur for example when 802.11 adhoc or Bluetooth PAN is in use. From owner-zeroconf@merit.edu Wed May 19 04:48:07 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21993 for ; Wed, 19 May 2004 04:48:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F33BA91240; Wed, 19 May 2004 04:47:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEB9791284; Wed, 19 May 2004 04:47:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB35E91240 for ; Wed, 19 May 2004 04:47:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA85E5940C; Wed, 19 May 2004 04:47:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 26B3B5931B for ; Wed, 19 May 2004 04:47:52 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 8D9231BB3C1; Wed, 19 May 2004 09:47:52 +0100 (BST) Message-ID: <00a101c43d7e$0948b4f0$131010ac@aldebaran> From: "Philip Nye" To: "Zero Configuration" , "Peter Johansson" References: <6.1.0.6.2.20040518095929.028e1860@POP.PacBell.Yahoo.com> <001c01c43d17$86e456b0$131010ac@aldebaran> <6.1.0.6.2.20040518134454.02cf55b0@POP.PacBell.Yahoo.com> Subject: Re: LL70: Use of the term "valid" Date: Wed, 19 May 2004 09:48:20 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Peter Johansson" >=20 > >The validity of a configured address is difficult to establish = because the=20 > >context in which it is intended to operate or becomes invalid can = vary.=20 > >Therefore I think that all we can do is explain the concept and = present=20 > >the DNAv4 reachability test as a useful example (informative) rather = than=20 > >a definition (normative) of validity. >=20 > Sounds like a good idea to me---but do it in the context of "routable" = > rather than "valid". >=20 The term "routable" is clearly defined: "This document uses the term "routable address" to refer to all unicast IPv4 addresses outside the 169.254/16 prefix, including global addresses and private addresses such as Net 10/8 [RFC1918], all of which may be forwarded via routers." "configured" is not explicitly defined but I would assume that if I type = "ifconfig eth0 5.6.7.8" then I have "configured" that address. = Similarly, if DHCP has handed me the address 5.6.7.8 and my lease is = still valid then that address is configured and because it conforms to = the definition above it is a "configured routable address". This tells me nothing about whether the address can be successfully used = in any way. The useability of an address depends largely on the routing = tables of other hosts on the same link and/or on the accessibility of = routers which will recognise the presence of the address and route = traffic to and from it. The reachability test of DNAv4 is a quick but = rough test of the second part of this. As Bernard pointed out - if the default router is down it doesn't mean = that an address is totally unuseable - it may still work fine for = communications which are on-link or via other routers. On the other hand, if I have the "configured routable address" 5.6.7.8 = but am sitting on a network 200.0.0.x many hops away from my default = router and with no other local hosts aware of my presence then 5.6.7.8 = will not be useable and for now I would be better off with a LL address. The term "valid" could possibly be replaced with "useable" or "working" = but is not redundant. Philip From owner-zeroconf@merit.edu Wed May 19 05:05:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22587 for ; Wed, 19 May 2004 05:05:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B49EB91284; Wed, 19 May 2004 05:05:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81FAB9128F; Wed, 19 May 2004 05:05:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 909A191284 for ; Wed, 19 May 2004 05:04:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7829A593B9; Wed, 19 May 2004 05:04:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 1EAA85931B for ; Wed, 19 May 2004 05:04:59 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id A61C91BB3E1; Wed, 19 May 2004 10:04:59 +0100 (BST) Message-ID: <00aa01c43d80$6d76b1a0$131010ac@aldebaran> From: "Philip Nye" To: "Bernard Aboba" , References: Subject: Re: LL70: Use of the term "valid" Date: Wed, 19 May 2004 10:05:27 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > From: "Bernard Aboba" > Jim Busse said: >=20 > "Just to clarify my understanding, If the reachability test described = in > DNAv4 is skipped, or fails, then IPv4LL can't have a "valid" address, > simply it will have a "routable" address. In that event, I may assign = an > IPv4LL address additionally on that interface, right?" >=20 > This might not be a good idea if it's likely that a routable address = will > eventually be assigned, since it will cause excessive address changes. > For example in IEEE 802.11, it could be that the reachability test = failed > because of packet loss and a subsequent DHCPDISCOVER would succeed. = Is it > helpful to have an IPv4LL address assigned so as to cause existing > connections to go down? Not necessarily. >=20 > In general, the recommended practice is for the host to only assign an > IPV4LL address when it is "likely" that no routable address will be > assigned. This could occur for example when 802.11 adhoc or Bluetooth = PAN > is in use. Bernard is right - the DNAv4 reachability test is only a rough guide to = the appropriateness of an address configuration. It can even give a = false positive - e.g. when I have the address 10.x.y.z configured, I can = move to another network where the 10/8 range is in use and where the = reachability test is passed yet my address is not at all appropriate and = may actually conlict. As humans we can envisage lots of scenarios and because we can generally = know something of the state of the whole network, we can usually decide = quite clearly whether and when it is appropriate to assign an IPv4LL = address. From inside the host looking out, it is far less easy to know what is = going on and come up with an algorithm which does the right thing in all = cases. What we are trying to achieve is that implementers will = understand the issues and devise algorithms which will do the right = thing in the most common cases that they encounter. The common cases encountered by a PDA with WiFi connectivity are likely = to be different from a desktop computer with a wired interface, and = different again from a small embedded device such as a scanner with a = minimal user interface. Philip From owner-zeroconf@merit.edu Wed May 19 09:47:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11175 for ; Wed, 19 May 2004 09:47:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE0B79128F; Wed, 19 May 2004 09:46:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D74B91290; Wed, 19 May 2004 09:46:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87C7A9128F for ; Wed, 19 May 2004 09:46:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 628E259410; Wed, 19 May 2004 09:46:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id A70515926C for ; Wed, 19 May 2004 09:46:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4JDnNP02375; Wed, 19 May 2004 06:50:02 -0700 Date: Wed, 19 May 2004 06:49:23 -0700 (PDT) From: Bernard Aboba To: Philip Nye Cc: zeroconf@merit.edu Subject: Re: LL70: Use of the term "valid" In-Reply-To: <00aa01c43d80$6d76b1a0$131010ac@aldebaran> Message-ID: References: <00aa01c43d80$6d76b1a0$131010ac@aldebaran> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Bernard is right - the DNAv4 reachability test is only a rough guide to the appropriateness > of an address configuration. It can even give a false positive - e.g. > when I have the address 10.x.y.z configured, I can move to another > network where the 10/8 range is in use and where the reachability test > is passed yet my address is not at all appropriate and may actually conlict. The reachability test includes determination that the MAC address of the gateway is unchanged, so I think that case is covered. From owner-zeroconf@merit.edu Thu May 20 16:03:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17266 for ; Thu, 20 May 2004 16:03:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3317B912CB; Thu, 20 May 2004 16:02:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1B90912D0; Thu, 20 May 2004 16:02:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 648E8912CB for ; Thu, 20 May 2004 16:02:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 364E45946C; Thu, 20 May 2004 16:02:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from venus.cs.uml.edu (venus.cs.uml.edu [129.63.8.51]) by segue.merit.edu (Postfix) with ESMTP id A5FE059304 for ; Thu, 20 May 2004 16:02:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by venus.cs.uml.edu (8.12.9/8.12.9) with ESMTP id i4KK20tq094657 for ; Thu, 20 May 2004 16:02:00 -0400 (EDT) Date: Thu, 20 May 2004 16:02:00 -0400 (EDT) From: Mark C Wishneusky To: zeroconf@merit.edu Subject: remove In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk remove ----------------------------------------------------------------------- Mark Wishneusky System / Network Administator (Home) 781-273-1736 (Comm) 508-647-6970 (Fax) 508-647-6971 E-Mail: mwishneu@cs.uml.edu wishneum@stiusa.com ----------------------------------------------------------------------- From owner-zeroconf@merit.edu Thu May 20 16:06:53 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17594 for ; Thu, 20 May 2004 16:06:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F4C491209; Thu, 20 May 2004 16:06:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC87E912C2; Thu, 20 May 2004 16:06:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D06B791209 for ; Thu, 20 May 2004 16:06:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB96B59517; Thu, 20 May 2004 16:06:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from venus.cs.uml.edu (venus.cs.uml.edu [129.63.8.51]) by segue.merit.edu (Postfix) with ESMTP id 3AA33594F9 for ; Thu, 20 May 2004 16:06:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by venus.cs.uml.edu (8.12.9/8.12.9) with ESMTP id i4KK6btq094669 for ; Thu, 20 May 2004 16:06:37 -0400 (EDT) Date: Thu, 20 May 2004 16:06:37 -0400 (EDT) From: Mark C Wishneusky To: zeroconf@merit.edu Subject: Re: remove In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Sorry to all, I used the wrong e-mail addy. Please disregard the previous e-mail. Thank you, Mark ----------------------------------------------------------------------- Mark Wishneusky System / Network Administator (Home) 781-273-1736 (Comm) 508-647-6970 (Fax) 508-647-6971 E-Mail: mwishneu@cs.uml.edu wishneum@stiusa.com ----------------------------------------------------------------------- From owner-zeroconf@merit.edu Tue May 25 11:53:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21278 for ; Tue, 25 May 2004 11:53:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D27529126A; Tue, 25 May 2004 11:53:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95BC79126C; Tue, 25 May 2004 11:53:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D4AD9126A for ; Tue, 25 May 2004 11:53:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA26359662; Tue, 25 May 2004 11:53:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 7B13159440 for ; Tue, 25 May 2004 11:53:01 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i4PFqxtF026768 for ; Tue, 25 May 2004 08:53:00 -0700 (PDT) Received: from [80.139.187.133] (vpn-129-150-116-161.UK.Sun.COM [129.150.116.161]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4PFqsx7019929 for ; Tue, 25 May 2004 17:52:56 +0200 (MEST) Date: Tue, 25 May 2004 17:52:37 +0200 (CEST) From: Erik Guttman X-X-Sender: erik@slap.local Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: resolution of LL52 LL54 LL55 LL56 LL57 LL58 LL59 LL60 LL61 LL62 LL64 LL65 LL66 LL67 LL68 LL69 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk ----- ---------- ------------------------------- Issue Type Title Recommend ----- ---- -------------------------------------------------- --------- LL52 t Text surrounding RFC 2119 clause is poor Accept LL53 e Forward references requested Open LL54 e Consistent terminology for out of scope Accept LL55 e 'Prevent' is too strong Accept (?) LL56 t Contradictory text? Reject (?) LL57 e Straightforward editorial fixes Accept LL58 t Duplicate inconsistent routable address Accept definition LL59 e Wireless comment not needed Accept LL60 e Forward reference style Reject LL61 t Remove random wait Accept LL62 t Do not space probes randomly Reject LL63 e Text should be more explicit Open LL64 e Simplify some text Accept LL65 t need a requirement for multihomed hosts Reject LL66 t Additional statistical example Reject LL67 t Fix clause which forbids routable to LL commun- Accept ication LL68 e Stress constants are not user configurable Reject LL69 e Move constants to beginning of doc Reject LL70 t DNAv4 normative or informative? Open Remarks LL52 ACCEPT with strong consensus: Use RFC 2119 recommended text. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. LL53 OPEN - further discussion needed. Se separate email. LL54 ACCEPT - consensus was to use 'out of scope' consistently dissent: this is a trivial issue LL55 ACCEPT: Consensus was to use a slight variation of the suggested text. In 1.4 change In order to prevent use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised: To: To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised: LL56 REJECT: There is not strong consensus to make this change. LL57 ACCEPT: Make suggested edits. Dissent: some changes are too trivial to bother with at this stage One dissenting opinion was based on a mistaken reading of the suggested change: A constant changed from 'ten seconds' to WATCH_WAIT. Sorry being unclear in my presentation. Changes are not listed for sake of brevity - see the issue text. LL58 ACCEPT: Strong consensus supports the change. >1.9. When to configure a Link-Local IPv4 address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a valid routable address and a > Link-Local IPv4 address configured on the same interface. > > A routable address is any address that is: > > * a unicast address (see Section 1.2) > * not a loopback address > * not contained within the 169.254/16 prefix reserved for Link-Local > IPv4 addresses > >To > >1.9. When to configure an IPv4 Link-Local address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a valid routable address and an > IPv4 Link-Local address configured on the same interface. And - Replace This document uses the term "routable address" to refer to all unicast IPv4 addresses outside the 169.254/16 prefix, including global addresses and private addresses such as Net 10/8 [RFC1918], all of which may be forwarded via routers. with This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global IP addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1 LL59 ACCEPT: The only reason we can come up with to keep this text is to appease an IESG comment. No one supports the text. Remove it and work with the IESG to resolve the issue if it becomes a problem. Omit > (This example does > not imply that IPv4 Link-Local configuration is inapplicable > to wireless interfaces). LL60 REJECT. The change was too large for most of the WG to accept at this phase. I share concern that references within the document would change and require extensive editorial checking. LL61 ACCEPT. The proposed solution is an amalgam of suggestions. section 2.2.1 Text was: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range PROBE_MIN to PROBE_MAX seconds, and should then send NUM_PROBES probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. Text becomes: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to START_WAIT seconds, and should then send PROBE_NUM probe packets. Each of these probe packets spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. Alex Eldar noted that we have to change our terminology for: Was: If during this period, from the beginning of the probing process until PROBE_MAX seconds after the last probe packet is sent, the host Becomes: If during this period, from the beginning of the probing process until DEFEND_INTERVAL seconds after the last probe packet is sent, the host And was: If, by PROBE_MAX seconds after the transmission of the last ARP probe no conflicting ARP Reply or ARP probe has been received, then the host has successfully claimed the desired IPv4 Link-Local address. Becomes: If, by DEFEND_INTERVAL seconds after the transmission of the last ARP probe no conflicting ARP Reply or ARP probe has been received, then the host has successfully claimed the desired IPv4 Link-Local address. LL62 REJECT: This was consensus to reject the issue, though not strong consensus. Dissent: More than one contributor felt that the additional random delays are unnecessary - that a fixed delay between probes is sufficient. Their arguments did not convince others in the WG. LL63 OPEN - further discussion needed LL64 ACCEPT Change The application knows the source address of the sender to whom the application will reply. The first scoped address problem is source address selection. ... to: The application knows the address of the sender to which the application will reply. The first scoped address problem is source address selection. LL65 REJECT: There was consensus to reject the issue. LL66 REJECT: There was consensus to reject the issue. LL67 ACCEPT: There was strong consensus support for this issue. Section 6.2, From: > IPv4 Link-Local addresses MUST NOT be forwarded via an application > protocol (for example in a URL), to a destination which is not Link- > Local, on the same link. This is discussed further in Section 2.9 > and 3. To: > IPv4 Link-Local addresses MUST NOT be forwarded via an application > protocol (for example in a URL), to a destination which is not > on the same link. This is discussed further in Section 2.9 and 3. LL68 REJECT: There was insufficient support to make this change. LL69 REJECT: There was insufficient support to make this change. Further, it would introduce the risk that references would no longer be accurate. LL70 OPEN - further discussion needed ------------- Erik Guttman ZEROCONF WG chair From owner-zeroconf@merit.edu Tue May 25 11:55:01 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21528 for ; Tue, 25 May 2004 11:55:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D5C669126C; Tue, 25 May 2004 11:54:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A33529126D; Tue, 25 May 2004 11:54:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CBAD9126C for ; Tue, 25 May 2004 11:54:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 518C3596B1; Tue, 25 May 2004 11:54:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id EF70C596AB for ; Tue, 25 May 2004 11:54:51 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4PFrIMP014349 for ; Tue, 25 May 2004 09:53:18 -0600 (MDT) Received: from [80.139.187.133] (vpn-129-150-116-161.UK.Sun.COM [129.150.116.161]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4PFslx7019991 for ; Tue, 25 May 2004 17:54:48 +0200 (MEST) Date: Tue, 25 May 2004 17:54:30 +0200 (CEST) From: Erik Guttman X-X-Sender: erik@slap.local Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG ACTION: continued 1 week discussion [LL53] Forward references requested Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk LL53: Several suggestions and comments had to be merged. Please respond by June 2 if there are any comments on this proposed resolution. If no comments are received, I will assume the change will be accepted as stated, below. -------------------------------------------- I received 3 direct emails supporting the suggested change of section 3.1 below and Bernard agreed. Those who responded supported the additional text for the constants, suggested by Stuart. Since LL69 was rejected, and there was no support for the additional text that Stuart suggested, most of the text added was dropped in the below proposed resolution. Please note that I left the text "Future standards documents..." which I think is excellent. It captures the thread which Mika and others championed. -------------------------------------------- Section 9, From: The following timing constants are used in this protocol; they are not intended to be user configurable. PROBE_MIN 1 second PROBE_MAX 2 seconds ANNOUNCE_INTERVAL 2 seconds PROBE_N 2 ANNOUNCE_N 2 NUM_PROBES 3 MAX_COLLISIONS 10 WATCH_WAIT 10 seconds RATE_LIMIT_INTERVAL 60 seconds To: The following timing constants are used in this protocol; they are not intended to be user configurable. START_WAIT 1 second (initial random delay) PROBE_MIN 1 second (minimum delay till repeated probe) PROBE_MAX 2 seconds (maximum delay till repeated probe) PROBE_NUM 3 (number of probe packets) PROBE_INTERVAL 1 second (time between probe packets) ANNOUNCE_NUM 2 (number of announcement packets) ANNOUNCE_INTERVAL 2 seconds (time between announcement packets) RATE_LIMIT_NUM 10 (max collisions before rate limiting) RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) DEFEND_INTERVAL 10 seconds (minimum time between defensive ARPs) Future standards documents, extending IPv4 Link-Local Addressing to media types other than those covered in this document, may specify different values for these constants. And: Sec. 3.1 from Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters described in Sections 2.2, 2.3 and 2.4: (a) the number of, and interval between, ARP probes, (b) the number of, and interval between, ARP announcements, (c) the maximum rate at which address claiming may be attempted, and (d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address. to Link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second may need to specify different values for the following parameters. (a) the number of, and interval between, ARP probes See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 (b) the number of, and interval between, ARP announcements, See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 (c) the maximum rate at which address claiming may be attempted See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section 2.2.1 (d) the time interval between conflicting ARPs below which a host MUST reconfigure instead of attempting to defend its address See WATCH_WAIT defined in section 2.5 Erik Guttman ZEROCONF WG Chair From owner-zeroconf@merit.edu Tue May 25 11:59:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22169 for ; Tue, 25 May 2004 11:59:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEBF791277; Tue, 25 May 2004 11:55:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1CA191276; Tue, 25 May 2004 11:55:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B2249126E for ; Tue, 25 May 2004 11:55:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1386B596A7; Tue, 25 May 2004 11:55:51 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 9328259690 for ; Tue, 25 May 2004 11:55:50 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4PFtmoK004348 for ; Tue, 25 May 2004 08:55:49 -0700 (PDT) Received: from [80.139.187.133] (vpn-129-150-116-161.UK.Sun.COM [129.150.116.161]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4PFtkx7020060 for ; Tue, 25 May 2004 17:55:47 +0200 (MEST) Date: Tue, 25 May 2004 17:55:28 +0200 (CEST) From: Erik Guttman X-X-Sender: erik@slap.local Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG ACTION: 1 week continued discussion [LL63] Text should be more explicit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk LL63: This issue remains open for discussion till June 2, 2004. Note that the text in this section was created as a result of collaboration with Ted Lemon and others in the DHC WG. We cannot view it as having been added erroneously or accidentally. Please indicate which of the following options you prefer. A) Leave the text as A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. Several early implementations of IPv4 Link-Local have modified the DHCP state machine in an attempt to make IPv4 Link-Local more reliable, and the field experience we have gained from this has shown that it does not work - reliability of DHCP service is significantly reduced. If increased reliability of IPv4 Link-Local is desired, we recommend that the IPv4 Link-Local state machine track the DHCP client state machine and, in cases where it is not certain that the DHCP-assigned address is correct, the IPv4 Link-Local state machine acquire an IPv4 Link-Local address without causing the DHCP state machine to relinquish its address. B) Replace the text in A) with A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. C) Replace the text in A) with A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. Field experience has shown that modifying the DHCP state machine in an attempt to make IPv4 Link-Local more reliable does not work - reliability of DHCP service is significantly reduced. If increased reliability of IPv4 Link-Local is desired, we recommend that the IPv4 Link-Local state machine track the DHCP client state machine and, in cases where it is not certain that the DHCP-assigned address is correct, the IPv4 Link-Local state machine acquire an IPv4 Link-Local address without causing the DHCP state machine to relinquish its address. D) Replace A) with As documented in Appendix A, early implementations of IPv4 Link-Local have modified the DHCP state machine. Field experience shows that these modifications reduce the reliability of the DHCP service. A device that implements both IPv4 Link-Local and a DHCPv4 client should not alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local configuration. In particular configuration of an IPv4 Link-Local address, whether or not a DHCP server is currently responding, is not sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP client from attempting to acquire a new IP address, to change DHCP timeouts or to change the behavior of the DHCP state machine in any other way. Further discussion of this issue is provided in [DNAv4]." Erik Guttman ZEROCONF WG Chair From owner-zeroconf@merit.edu Tue May 25 11:59:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22215 for ; Tue, 25 May 2004 11:59:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97D809127F; Tue, 25 May 2004 11:57:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F06C9127D; Tue, 25 May 2004 11:57:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7F2A9126E for ; Tue, 25 May 2004 11:56:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6ED32596BD; Tue, 25 May 2004 11:56:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id E3A87596C6 for ; Tue, 25 May 2004 11:56:57 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i4PFuuoK005048 for ; Tue, 25 May 2004 08:56:56 -0700 (PDT) Received: from [80.139.187.133] (vpn-129-150-116-161.UK.Sun.COM [129.150.116.161]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4PFupx7020130 for ; Tue, 25 May 2004 17:56:52 +0200 (MEST) Date: Tue, 25 May 2004 17:56:34 +0200 (CEST) From: Erik Guttman X-X-Sender: erik@slap.local Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk LL70 This issue will remain open for comment until June 2, 2004. After that point, if no comments are received, the issue will be resolved by making DNAv4 normative and leaving the text as it currently stands. Bernard suggests the following resolution, which should allow DNAv4 to remain an informative reference. Was: 1.9. When to configure a Link-Local IPv4 address Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a valid routable address and a Link-Local IPv4 address configured on the same interface. A routable address is any address that is: * a unicast address (see Section 1.2) * not a loopback address * not contained within the 169.254/16 prefix reserved for Link-Local IPv4 addresses A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. The assignment and use of a Link-Local IPv4 address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned a Link-Local IPv4 address to an interface. When an interface has a valid routable address configured on an interface, the host SHOULD NOT also assign a Link-Local IPv4 address to that interface. If a host finds that an interface that was previous configured with a Link-Local IPv4 address is now configured with a valid routable address, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the Link-Local IPv4 address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the Link-Local IPv4 address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the Link-Local IPv4 address. Ways in which a valid routable address might be configured for the interface include: * Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which a routable address assigned to the interface is valid If a host finds that an interface that was previously configured with a valid routable address no longer has a valid routable address, the host MAY identify a usable Link-Local IPv4 address (as described in section 2) and assign that address to the interface. Ways in which a valid routable address might no longer be assigned to an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid. Further discussion of the issues in detection of transient failures and the use of DHCP in response to network attachment failure is provided in "Detection of Network Attachment (DNA) in IPv4". [DNAv4] Becomes: 1.9. When to configure an IPv4 Link-Local address Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a routable address and an IPv4 Link-Local address configured on the same interface. The assignment and use of an IPv4 Link-Local address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned an IPv4 Link-Local address to an interface. When an interface has a routable address configured on an interface, is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned an IPv4 Link-Local address to an interface. When an interface has a routable address configured on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address to that interface. If a host finds that an interface that was previous configured with an IPv4 Link-Local address is now configured with a routable address, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the IPv4 Link-Local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the IPv4 Link-Local address. Ways in which a routable address might be configured for the interface include: * Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which the host has a valid routable address If a host finds that a routable address is no longer assigned to an interface, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and assign that address to the interface. Ways in which a routable address might no longer be assigned to an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid. Further discussion of address assignment and the detection of network attachment is provided in [DNAv4]. Erik Guttman ZEROCONF WG Chair From owner-zeroconf@merit.edu Tue May 25 12:01:57 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22465 for ; Tue, 25 May 2004 12:01:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 192349126E; Tue, 25 May 2004 12:01:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE3AD9126F; Tue, 25 May 2004 12:00:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 377E39126E for ; Tue, 25 May 2004 12:00:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1735F5927B; Tue, 25 May 2004 12:00:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 701A859268 for ; Tue, 25 May 2004 12:00:57 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i4PFxKMP017861 for ; Tue, 25 May 2004 09:59:20 -0600 (MDT) Received: from [80.139.187.133] (vpn-129-150-116-161.UK.Sun.COM [129.150.116.161]) by hs-ehdb03-01.Germany.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i4PG0mx7020386 for ; Tue, 25 May 2004 18:00:50 +0200 (MEST) Date: Tue, 25 May 2004 18:00:29 +0200 (CEST) From: Erik Guttman X-X-Sender: erik@slap.local Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: Re: resolution of LL52 LL54 LL55 LL56 LL57 LL58 LL59 LL60 LL61 LL62 LL64 LL65 LL66 LL67 LL68 LL69 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The resolutions which I included in this message are my reading of the discussion in the preceeding last call periods. If you believe that I have misread the consensus, please bring this up on the working group mailing list. I remind participants that a very high degree of agreement is needed to make a change at this late in the process. I will not be able to respond to the ensuing discussion until Monday 31 May. Best regards, Erik Guttman ZEROCONF WG Chair On Tue, 25 May 2004, Erik Guttman wrote: > > ----- ---------- ------------------------------- > > Issue Type Title Recommend > ----- ---- -------------------------------------------------- --------- > LL52 t Text surrounding RFC 2119 clause is poor Accept > LL53 e Forward references requested Open > LL54 e Consistent terminology for out of scope Accept > LL55 e 'Prevent' is too strong Accept > LL56 t Contradictory text? Reject > LL57 e Straightforward editorial fixes Accept > LL58 t Duplicate inconsistent routable address Accept > definition > LL59 e Wireless comment not needed Accept > LL60 e Forward reference style Reject > LL61 t Remove random wait Accept > LL62 t Do not space probes randomly Reject > LL63 e Text should be more explicit Open > LL64 e Simplify some text Accept > LL65 t need a requirement for multihomed hosts Reject > LL66 t Additional statistical example Reject > LL67 t Fix clause which forbids routable to LL commun- Accept > ication > LL68 e Stress constants are not user configurable Reject > LL69 e Move constants to beginning of doc Reject > LL70 t DNAv4 normative or informative? Open From owner-zeroconf@merit.edu Wed May 26 05:20:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02238 for ; Wed, 26 May 2004 05:20:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C42C91209; Wed, 26 May 2004 05:20:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37E469128A; Wed, 26 May 2004 05:20:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 443AF91209 for ; Wed, 26 May 2004 05:20:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2FE91596ED; Wed, 26 May 2004 05:20:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id A99BD59610 for ; Wed, 26 May 2004 05:20:25 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id D03181BB499; Wed, 26 May 2004 10:20:23 +0100 (BST) Message-ID: <020f01c44302$acf63a30$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , References: Subject: Re: resolution of LL57 Date: Wed, 26 May 2004 10:20:21 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I will reiterate my comment on one of the "editorial" changes of LL57 = since the comment semems to have got lost among the mass of changes = which were proposed under a single heading. I am not happy with simply = accepting the proposed change as is. > Section 2.5 >=20 > > (b) If a host currently has active TCP connections or other = reasons > > to prefer to keep the same IPv4 address, and it has not seen any > > other conflicting ARP packets recently (for IEEE 802, within the = last > > ten seconds) then it MAY elect to attempt to defend its address >=20 > becomes >=20 > If a host currently has active TCP connections or other reasons > to prefer to keep the same IPv4 address, and it has not seen any > other conflicting ARP packets recently (for IEEE 802, within the = last > | WATCH_WAIT seconds) then it MAY elect to attempt to defend its = address, by > recording the time that the conflicting ARP packet was received, = and > then broadcasting one single ARP announcement, giving its own IP = and > hardware addresses as the sender addresses of the ARP. Having = done > this, the host can then continue to use the address normally = without > any further special action. However, if this is not the first > conflicting ARP packet the host has seen, and the time recorded = for > the previous conflicting ARP packet is recent (within WATCH_WAIT > seconds for IEEE 802) then the host MUST immediately cease using = this > address and configure a new IPv4 Link-Local address as described > above. This is necessary to ensure that two hosts do not get = stuck > in an endless loop with both hosts trying to defend the same = address. >=20 I am in favour of parameterizing WATCH_WAIT but we should do it = properly. As proposed the *parameter* WATCH_WAIT is specific to IEEE802. = It should be the *value* of WATCH_WAIT that is IEE802 specific - other = transports may get different values for the same parameter. The text = should read: "...and it has not seen any other conflicting ARP packets within = WATCH_WAIT seconds then it MAY elect..." and add in section 9: WATCH_WAIT 10 seconds for IEEE 802 networks Philip Nye From owner-zeroconf@merit.edu Wed May 26 06:12:14 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05120 for ; Wed, 26 May 2004 06:12:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBB4E91209; Wed, 26 May 2004 06:12:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 854B091290; Wed, 26 May 2004 06:12:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7327491209 for ; Wed, 26 May 2004 06:12:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FE7A596DF; Wed, 26 May 2004 06:12:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id BABA75971E for ; Wed, 26 May 2004 06:12:05 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 5A4021BB4C6; Wed, 26 May 2004 11:12:06 +0100 (BST) Message-ID: <074901c44309$e4f2f1b0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , References: Subject: Re: WG ACTION: continued 1 week discussion [LL53] Forward references requested Date: Wed, 26 May 2004 11:12:04 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Erik, 1. WATCH_WAIT seems to have disappeared in the proposed change to = section 9. It should not have done. 2. You have got your knickers in a twist over PROBE_INTERVAL and = DEFEND_INTERVAL. Alex Elder proposed using PROBE_INTERVAL in a comment = on LL61. This has been accepted in your resolution to LL61 but you have = changed the name to DEFEND_INTERVAL. Now in the proposed parameter text = for LL53 you have both but with wildly different values! 3. PROBE_INTERVAL is not "time between probe packets". It is "wait time = after last probe packet" and I can find nothing in the discussion that = defines DEFEND_INTERVAL as "minimum time between defensive ARPs". 3. We now have 5 parameters for the probing process and there is clearly = confusion over their meaning. I would like to see clearer naming: = NUM_PROBES, PRE_PROBE_MAX, INTER_PROBE_MIN, INTER_PROBE_MAX, = POST_PROBE_WAIT. 4. The new text of 3.1(a) should name all 5 of the probing parameters = thus: (a) the number and timing of ARP probes See NUM_PROBES, PRE_PROBE_MAX, INTER_PROBE_MIN, INTER_PROBE_MAX, POST_PROBE_WAIT defined in section 2.2.1 regards, Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 25, 2004 4:54 PM Subject: WG ACTION: continued 1 week discussion [LL53] Forward = references requested >=20 > LL53: >=20 > Several suggestions and comments had to be merged. Please respond by > June 2 if there are any comments on this proposed resolution. If no > comments are received, I will assume the change will be accepted as > stated, below. >=20 > -------------------------------------------- >=20 > I received 3 direct emails supporting the suggested change of section = 3.1 > below and Bernard agreed. >=20 > Those who responded supported the additional text for the constants, > suggested by Stuart. >=20 > Since LL69 was rejected, and there was no support for the additional = text > that Stuart suggested, most of the text added was dropped in the below > proposed resolution. >=20 > Please note that I left the text "Future standards documents..." which > I think is excellent. It captures the thread which Mika and others > championed. >=20 > -------------------------------------------- >=20 > Section 9, From: >=20 > The following timing constants are used in this protocol; they are > not intended to be user configurable. >=20 > PROBE_MIN 1 second > PROBE_MAX 2 seconds > ANNOUNCE_INTERVAL 2 seconds > PROBE_N 2 > ANNOUNCE_N 2 > NUM_PROBES 3 > MAX_COLLISIONS 10 > WATCH_WAIT 10 seconds > RATE_LIMIT_INTERVAL 60 seconds >=20 > To: >=20 > The following timing constants are used in this protocol; they are > not intended to be user configurable. >=20 > START_WAIT 1 second (initial random delay) > PROBE_MIN 1 second (minimum delay till repeated probe) > PROBE_MAX 2 seconds (maximum delay till repeated probe) > PROBE_NUM 3 (number of probe packets) > PROBE_INTERVAL 1 second (time between probe packets) > ANNOUNCE_NUM 2 (number of announcement packets) > ANNOUNCE_INTERVAL 2 seconds (time between announcement packets) > RATE_LIMIT_NUM 10 (max collisions before rate = limiting) > RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts) > DEFEND_INTERVAL 10 seconds (minimum time between defensive = ARPs) >=20 > Future standards documents, extending IPv4 Link-Local Addressing to > media types other than those covered in this document, may specify > different values for these constants. >=20 > And: >=20 > Sec. 3.1 from >=20 > Link-layer technologies that support ARP but operate at rates = below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters described in Sections 2.2, 2.3 > and 2.4: >=20 > (a) the number of, and interval between, ARP probes, > (b) the number of, and interval between, ARP announcements, > (c) the maximum rate at which address claiming may be attempted, = and > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address. >=20 >=20 > to >=20 > Link-layer technologies that support ARP but operate at rates = below 1 > Mbps or latencies above one second may need to specify different > values for the following parameters. >=20 > (a) the number of, and interval between, ARP probes > See NUM_PROBES, PROBE_MIN, PROBE_MAX defined in section 2.2.1 >=20 > (b) the number of, and interval between, ARP announcements, > See ANNOUNCE_N and ANNOUNCE_INTERVAL defined in section 2.4 >=20 > (c) the maximum rate at which address claiming may be attempted > See RATE_LIMIT_INTERVAL and MAX_COLLISIONS defined in section = 2.2.1 >=20 > (d) the time interval between conflicting ARPs below which a host > MUST reconfigure instead of attempting to defend its address > See WATCH_WAIT defined in section 2.5 >=20 >=20 > Erik Guttman > ZEROCONF WG Chair > From owner-zeroconf@merit.edu Wed May 26 06:18:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05434 for ; Wed, 26 May 2004 06:18:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D77091290; Wed, 26 May 2004 06:18:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CE3A91291; Wed, 26 May 2004 06:18:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5735791290 for ; Wed, 26 May 2004 06:18:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4457B596FA; Wed, 26 May 2004 06:18:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 61A855923B for ; Wed, 26 May 2004 06:18:15 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id 075E21BB4C3; Wed, 26 May 2004 11:18:16 +0100 (BST) Message-ID: <075301c4430a$c148bc80$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , References: Subject: Re: WG ACTION: 1 week continued discussion [LL63] Text should be more explicit Date: Wed, 26 May 2004 11:18:14 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Please indicate which of the following options you prefer. First choice D, second C, third A, all are acceptable to me. B is not as = it loses useful advice. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 25, 2004 4:55 PM Subject: WG ACTION: 1 week continued discussion [LL63] Text should be = more explicit >=20 > LL63: >=20 > This issue remains open for discussion till June 2, 2004. >=20 > Note that the text in this section was created as a result of > collaboration with Ted Lemon and others in the DHC WG. We cannot view > it as having been added erroneously or accidentally. >=20 > Please indicate which of the following options you prefer. >=20 > A) Leave the text as >=20 > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate > IPv4 Link-Local configuration. In particular configuration of an > IPv4 Link-Local address, whether or not a DHCP server is currently > responding, is not sufficient reason to unconfigure a valid DHCP > lease, to stop the DHCP client from attempting to acquire a new IP > address, to change DHCP timeouts or to change the behavior of the > DHCP state machine in any other way. >=20 > Several early implementations of IPv4 Link-Local have modified the > DHCP state machine in an attempt to make IPv4 Link-Local more > reliable, and the field experience we have gained from this has > shown that it does not work - reliability of DHCP service is > significantly reduced. If increased reliability of IPv4 = Link-Local > is desired, we recommend that the IPv4 Link-Local state machine = track > the DHCP client state machine and, in cases where it is not certain > that the DHCP-assigned address is correct, the IPv4 Link-Local = state > machine acquire an IPv4 Link-Local address without causing the DHCP > state machine to relinquish its address. >=20 > B) Replace the text in A) with >=20 > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate > IPv4 Link-Local configuration. In particular configuration of an > IPv4 Link-Local address, whether or not a DHCP server is currently > responding, is not sufficient reason to unconfigure a valid DHCP > lease, to stop the DHCP client from attempting to acquire a new IP > address, to change DHCP timeouts or to change the behavior of the > DHCP state machine in any other way. >=20 > C) Replace the text in A) with >=20 > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate > IPv4 Link-Local configuration. In particular configuration of an > IPv4 Link-Local address, whether or not a DHCP server is currently > responding, is not sufficient reason to unconfigure a valid DHCP > lease, to stop the DHCP client from attempting to acquire a new IP > address, to change DHCP timeouts or to change the behavior of the > DHCP state machine in any other way. >=20 > Field experience has shown that modifying the DHCP state machine in > an attempt to make IPv4 Link-Local more reliable does not work - > reliability of DHCP service is significantly reduced. If increased > reliability of IPv4 Link-Local is desired, we recommend that the > IPv4 Link-Local state machine track the DHCP client state machine > and, in cases where it is not certain that the DHCP-assigned > address is correct, the IPv4 Link-Local state machine acquire an > IPv4 Link-Local address without causing the DHCP state machine to > relinquish its address. >=20 > D) Replace A) with >=20 > As documented in Appendix A, early implementations of IPv4 > Link-Local have modified the DHCP state machine. Field experience > shows that these modifications reduce the reliability of the DHCP > service. >=20 > A device that implements both IPv4 Link-Local and a DHCPv4 client > should not alter the behavior of the DHCPv4 client to accommodate > IPv4 Link-Local configuration. In particular configuration of an > IPv4 Link-Local address, whether or not a DHCP server is currently > responding, is not sufficient reason to unconfigure a valid DHCP > lease, to stop the DHCP client from attempting to acquire a new IP > address, to change DHCP timeouts or to change the behavior of the > DHCP state machine in any other way. >=20 > Further discussion of this issue is provided in [DNAv4]." >=20 > Erik Guttman > ZEROCONF WG Chair > From owner-zeroconf@merit.edu Wed May 26 06:42:30 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07223 for ; Wed, 26 May 2004 06:42:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D844591298; Wed, 26 May 2004 06:42:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FB4691297; Wed, 26 May 2004 06:42:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3778F91294 for ; Wed, 26 May 2004 06:42:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0752558E53; Wed, 26 May 2004 06:42:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from server30.ukservers.net (server30.ukservers.net [217.10.138.207]) by segue.merit.edu (Postfix) with ESMTP id 6DE965957B for ; Wed, 26 May 2004 06:42:21 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server30.ukservers.net (Postfix) with ESMTP id EB13B1BB404; Wed, 26 May 2004 11:42:21 +0100 (BST) Message-ID: <075c01c4430e$1f185cf0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , References: Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? Date: Wed, 26 May 2004 11:42:20 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I support the principle that DNAv4 should become informative rather than = normative - espescially as recent discussions here have shown that the = reachability test of DNAv4 is a guide rather than a final and decisive = test of the useability of an address. I do not support the resolution text as it stands for several reasons: 1. (editorial) an extra meaningless paragraph has appeared which is a = combination of two others: > When an interface has a routable address configured on an = interface, > is based solely on the state of the interface, and is independent = of > any other protocols such as DHCP. A host MUST NOT alter its = behavior > and use of other protocols such as DHCP because the host has = assigned > an IPv4 Link-Local address to an interface. 2. (editorial) "When an interface has a routable address configured on = an interface" needs to be changed. The paragraph should read: When a routable address is configured on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address to that interface. 3. (substantive) as I have said in previous discussion, the term "valid" = carries meaning that is lost when it is simply dropped as here. I would = rather keep the term "valid" (or "working" or "useable") and leave its = definition fuzzy if necessary. I don't believe the proposed text = adequately resolves this issue. If a host finds that an interface that was previous[ly] configured with an IPv4 Link-Local address is now configured with a routable=20 address, the host MUST use the routable address when initiating new=20 communications... I would interpret this text as a firm injunction preventing me from = using IPv4LL on any interface which has a routable address however wrong = and unuseable that address is. The only get out is weasle words about = the meaning of "configured". Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Tuesday, May 25, 2004 4:56 PM Subject: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative = or informative? > LL70 >=20 > This issue will remain open for comment until June 2, 2004. > After that point, if no comments are received, the issue will be > resolved by making DNAv4 normative and leaving the text as it = currently > stands. >=20 > Bernard suggests the following resolution, which should allow DNAv4 to > remain an informative reference. >=20 > Was: > 1.9. When to configure a Link-Local IPv4 address >=20 > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications = and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a valid routable address and a > Link-Local IPv4 address configured on the same interface. >=20 >=20 > A routable address is any address that is: >=20 > * a unicast address (see Section 1.2) > * not a loopback address > * not contained within the 169.254/16 prefix reserved for = Link-Local > IPv4 addresses >=20 > A "valid routable address" is a routable address that passes the > reachability test described in section 2 of "Detection of Network > Attachment (DNA) in IPv4" [DNAv4]. >=20 > The assignment and use of a Link-Local IPv4 address on an interface > is based solely on the state of the interface, and is independent = of > any other protocols such as DHCP. A host MUST NOT alter its = behavior > and use of other protocols such as DHCP because the host has = assigned > a Link-Local IPv4 address to an interface. >=20 > When an interface has a valid routable address configured on an > interface, the host SHOULD NOT also assign a Link-Local IPv4 = address > to that interface. >=20 > If a host finds that an interface that was previous configured with = a > Link-Local IPv4 address is now configured with a valid routable > address, the host MUST always use the routable address when > initiating new communications, and MUST cease advertising the > availability of the Link-Local IPv4 address through whatever > mechanisms that address had been made known to others. The host > SHOULD continue to use the Link-Local IPv4 address for = communications > underway when the routable address was configured, and MAY continue > to accept new communications addressed to the Link-Local IPv4 > address. Ways in which a valid routable address might be = configured > for the interface include: >=20 > * Manual configuration > * Address assignment through DHCP > * Roaming of the host to a network on which a routable address > assigned to the interface is valid >=20 > If a host finds that an interface that was previously configured = with > a valid routable address no longer has a valid routable address, = the > host MAY identify a usable Link-Local IPv4 address (as described in > section 2) and assign that address to the interface. Ways in which = a > valid routable address might no longer be assigned to an interface > include: >=20 > * Removal of the address from the interface through manual > configuration > * Expiration of the lease on the address assigned through DHCP > * Roaming of the host to a new network on which the address is no > longer valid. >=20 > Further discussion of the issues in detection of transient failures > and the use of DHCP in response to network attachment failure is > provided in "Detection of Network Attachment (DNA) in IPv4". = [DNAv4] >=20 >=20 >=20 > Becomes: >=20 > 1.9. When to configure an IPv4 Link-Local address >=20 > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications = and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a routable address and an IPv4 > Link-Local address configured on the same interface. >=20 > The assignment and use of an IPv4 Link-Local address on an = interface > is based solely on the state of the interface, and is independent = of > any other protocols such as DHCP. A host MUST NOT alter its = behavior > and use of other protocols such as DHCP because the host has = assigned > an IPv4 Link-Local address to an interface. >=20 > When an interface has a routable address configured on an = interface, > is based solely on the state of the interface, and is independent = of > any other protocols such as DHCP. A host MUST NOT alter its = behavior > and use of other protocols such as DHCP because the host has = assigned > an IPv4 Link-Local address to an interface. >=20 > When an interface has a routable address configured on an = interface, > the host SHOULD NOT also assign an IPv4 Link-Local address to that > interface. >=20 > If a host finds that an interface that was previous configured with > an IPv4 Link-Local address is now configured with a routable = address, > the host MUST use the routable address when initiating new > communications, and MUST cease advertising the availability of the > IPv4 Link-Local address through whatever mechanisms that address = had > been made known to others. The host SHOULD continue to use the = IPv4 > Link-Local address for communications underway when the routable > address was configured, and MAY continue to accept new = communications > addressed to the IPv4 Link-Local address. Ways in which a routable > address might be configured for the interface include: >=20 > * Manual configuration > * Address assignment through DHCP > * Roaming of the host to a network on which the host has a > valid routable address >=20 > If a host finds that a routable address is no longer assigned to an > interface, the host MAY identify a usable IPv4 Link-Local address = (as > described in section 2) and assign that address to the interface. > Ways in which a routable address might no longer be assigned to an > interface include: >=20 > * Removal of the address from the interface through manual > configuration > * Expiration of the lease on the address assigned through DHCP > * Roaming of the host to a new network on which the address is no > longer valid. >=20 > Further discussion of address assignment and the detection of = network > attachment is provided in [DNAv4]. >=20 > Erik Guttman > ZEROCONF WG Chair >=20 > From owner-zeroconf@merit.edu Wed May 26 14:43:26 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04556 for ; Wed, 26 May 2004 14:43:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 724EF912AB; Wed, 26 May 2004 14:43:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 356BB912A0; Wed, 26 May 2004 14:43:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6D3D912AD for ; Wed, 26 May 2004 14:43:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9255159647; Wed, 26 May 2004 14:43:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by segue.merit.edu (Postfix) with ESMTP id 5EB8B59718 for ; Wed, 26 May 2004 14:43:12 -0400 (EDT) Received: from JenEric (adsl-63-205-67-140.dsl.snfc21.pacbell.net [63.205.67.140]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id i4QHfb9G000824 for ; Wed, 26 May 2004 10:41:38 -0700 (PDT) Message-ID: <002801c44349$7ee49640$6d01a8c0@JenEric> Reply-To: "Jim Busse" From: "Jim Busse" To: References: <075c01c4430e$1f185cf0$131010ac@aldebaran> Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? Date: Wed, 26 May 2004 10:47:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I also support the principle that DNAv4 should become informative. I gave DNAv4 to a network apps developer, and he implemented the reachability test described in DNAv4 differently from the way I interpreted and implemented it. As has been pointed out before, the assignment of IP addresses to interfaces is primarily an operating systems issue. Since most net apps are sockets apps, most net applications won't be able to assign an IPv4LL address. So I think Apple, Microsoft, and Sun (alphabetically) should come up with the advisory wording. The issue was discussed a year ago. The thread was: "New issue: When to configure a LL address." Instead of flailing a dead horse, could the wording be taken from that thread? From Stuart (reproduced here without permission): "The one-and-only truly accurate way to determine whether operation A will succeed is to try doing operation A, and see if it succeeds. (Those with a formal computer science background will recognize this as a trivial re-statement of the halting problem.) Any attempt to determine whether operation A (e.g. connect to www.amazon.com) will succeed by first performing some different operation B (e.g. ping the DHCP server) is plagued by false positives and false negatives. False positive: Just because the DHCP server responds doesn't mean you have a path all the way to www.amazon.com and back. False negative: Just because the DHCP server doesn't respond doesn't mean you *don't* have a path all the way to www.amazon.com and back. Therefore, the best and simplest test to see whether a routable address will work is to try it, and if it does not work, to try an alternative instead." Jim ----- Original Message ----- From: "Philip Nye" To: "Erik Guttman" ; Sent: Wednesday, May 26, 2004 3:42 AM Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? I support the principle that DNAv4 should become informative rather than normative - espescially as recent discussions here have shown that the reachability test of DNAv4 is a guide rather than a final and decisive test of the useability of an address. I do not support the resolution text as it stands for several reasons: 1. (editorial) an extra meaningless paragraph has appeared which is a combination of two others: > When an interface has a routable address configured on an interface, > is based solely on the state of the interface, and is independent of > any other protocols such as DHCP. A host MUST NOT alter its behavior > and use of other protocols such as DHCP because the host has assigned > an IPv4 Link-Local address to an interface. 2. (editorial) "When an interface has a routable address configured on an interface" needs to be changed. The paragraph should read: When a routable address is configured on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address to that interface. 3. (substantive) as I have said in previous discussion, the term "valid" carries meaning that is lost when it is simply dropped as here. I would rather keep the term "valid" (or "working" or "useable") and leave its definition fuzzy if necessary. I don't believe the proposed text adequately resolves this issue. If a host finds that an interface that was previous[ly] configured with an IPv4 Link-Local address is now configured with a routable address, the host MUST use the routable address when initiating new communications... I would interpret this text as a firm injunction preventing me from using IPv4LL on any interface which has a routable address however wrong and unuseable that address is. The only get out is weasle words about the meaning of "configured". Philip ----- Original Message ----- From: "Erik Guttman" To: Sent: Tuesday, May 25, 2004 4:56 PM Subject: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? > LL70 > > This issue will remain open for comment until June 2, 2004. > After that point, if no comments are received, the issue will be > resolved by making DNAv4 normative and leaving the text as it currently > stands. > > Bernard suggests the following resolution, which should allow DNAv4 to > remain an informative reference. > > Was: > 1.9. When to configure a Link-Local IPv4 address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a valid routable address and a > Link-Local IPv4 address configured on the same interface. > > > A routable address is any address that is: > > * a unicast address (see Section 1.2) > * not a loopback address > * not contained within the 169.254/16 prefix reserved for Link-Local > IPv4 addresses > > A "valid routable address" is a routable address that passes the > reachability test described in section 2 of "Detection of Network > Attachment (DNA) in IPv4" [DNAv4]. > > The assignment and use of a Link-Local IPv4 address on an interface > is based solely on the state of the interface, and is independent of > any other protocols such as DHCP. A host MUST NOT alter its behavior > and use of other protocols such as DHCP because the host has assigned > a Link-Local IPv4 address to an interface. > > When an interface has a valid routable address configured on an > interface, the host SHOULD NOT also assign a Link-Local IPv4 address > to that interface. > > If a host finds that an interface that was previous configured with a > Link-Local IPv4 address is now configured with a valid routable > address, the host MUST always use the routable address when > initiating new communications, and MUST cease advertising the > availability of the Link-Local IPv4 address through whatever > mechanisms that address had been made known to others. The host > SHOULD continue to use the Link-Local IPv4 address for communications > underway when the routable address was configured, and MAY continue > to accept new communications addressed to the Link-Local IPv4 > address. Ways in which a valid routable address might be configured > for the interface include: > > * Manual configuration > * Address assignment through DHCP > * Roaming of the host to a network on which a routable address > assigned to the interface is valid > > If a host finds that an interface that was previously configured with > a valid routable address no longer has a valid routable address, the > host MAY identify a usable Link-Local IPv4 address (as described in > section 2) and assign that address to the interface. Ways in which a > valid routable address might no longer be assigned to an interface > include: > > * Removal of the address from the interface through manual > configuration > * Expiration of the lease on the address assigned through DHCP > * Roaming of the host to a new network on which the address is no > longer valid. > > Further discussion of the issues in detection of transient failures > and the use of DHCP in response to network attachment failure is > provided in "Detection of Network Attachment (DNA) in IPv4". [DNAv4] > > > > Becomes: > > 1.9. When to configure an IPv4 Link-Local address > > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications and > confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For these > reasons, a host SHOULD NOT have both a routable address and an IPv4 > Link-Local address configured on the same interface. > > The assignment and use of an IPv4 Link-Local address on an interface > is based solely on the state of the interface, and is independent of > any other protocols such as DHCP. A host MUST NOT alter its behavior > and use of other protocols such as DHCP because the host has assigned > an IPv4 Link-Local address to an interface. > > When an interface has a routable address configured on an interface, > is based solely on the state of the interface, and is independent of > any other protocols such as DHCP. A host MUST NOT alter its behavior > and use of other protocols such as DHCP because the host has assigned > an IPv4 Link-Local address to an interface. > > When an interface has a routable address configured on an interface, > the host SHOULD NOT also assign an IPv4 Link-Local address to that > interface. > > If a host finds that an interface that was previous configured with > an IPv4 Link-Local address is now configured with a routable address, > the host MUST use the routable address when initiating new > communications, and MUST cease advertising the availability of the > IPv4 Link-Local address through whatever mechanisms that address had > been made known to others. The host SHOULD continue to use the IPv4 > Link-Local address for communications underway when the routable > address was configured, and MAY continue to accept new communications > addressed to the IPv4 Link-Local address. Ways in which a routable > address might be configured for the interface include: > > * Manual configuration > * Address assignment through DHCP > * Roaming of the host to a network on which the host has a > valid routable address > > If a host finds that a routable address is no longer assigned to an > interface, the host MAY identify a usable IPv4 Link-Local address (as > described in section 2) and assign that address to the interface. > Ways in which a routable address might no longer be assigned to an > interface include: > > * Removal of the address from the interface through manual > configuration > * Expiration of the lease on the address assigned through DHCP > * Roaming of the host to a new network on which the address is no > longer valid. > > Further discussion of address assignment and the detection of network > attachment is provided in [DNAv4]. > > Erik Guttman > ZEROCONF WG Chair > > From owner-zeroconf@merit.edu Thu May 27 12:43:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06995 for ; Thu, 27 May 2004 12:43:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66D1B912B8; Thu, 27 May 2004 12:43:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E184912BA; Thu, 27 May 2004 12:43:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1FB2912B8 for ; Thu, 27 May 2004 12:43:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E0D5E5960B; Thu, 27 May 2004 12:43:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs180141.pp.htv.fi [213.243.180.141]) by segue.merit.edu (Postfix) with ESMTP id F20A659601 for ; Thu, 27 May 2004 12:43:31 -0400 (EDT) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-5) with ESMTP id i4RGjK25032630 for ; Thu, 27 May 2004 19:45:20 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.11/8.12.11/Debian-5) id i4RGjJ1K032629 for zeroconf@merit.edu; Thu, 27 May 2004 19:45:19 +0300 Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? From: Mika Liljeberg To: zeroconf@merit.edu In-Reply-To: <075c01c4430e$1f185cf0$131010ac@aldebaran> References: <075c01c4430e$1f185cf0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1085676319.3162.70.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 27 May 2004 19:45:19 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with Philip on every point. Thanks, MikaL On Wed, 2004-05-26 at 13:42, Philip Nye wrote: > I support the principle that DNAv4 should become informative rather than normative - espescially as recent discussions here have shown that the reachability test of DNAv4 is a guide rather than a final and decisive test of the useability of an address. > > I do not support the resolution text as it stands for several reasons: > > 1. (editorial) an extra meaningless paragraph has appeared which is a combination of two others: > > > When an interface has a routable address configured on an interface, > > is based solely on the state of the interface, and is independent of > > any other protocols such as DHCP. A host MUST NOT alter its behavior > > and use of other protocols such as DHCP because the host has assigned > > an IPv4 Link-Local address to an interface. > > 2. (editorial) "When an interface has a routable address configured on an interface" needs to be changed. The paragraph should read: > > When a routable address is configured on an interface, > the host SHOULD NOT also assign an IPv4 Link-Local address to that > interface. > > 3. (substantive) as I have said in previous discussion, the term "valid" carries meaning that is lost when it is simply dropped as here. I would rather keep the term "valid" (or "working" or "useable") and leave its definition fuzzy if necessary. I don't believe the proposed text adequately resolves this issue. > > If a host finds that an interface that was previous[ly] configured > with an IPv4 Link-Local address is now configured with a routable > address, the host MUST use the routable address when initiating new > communications... > > I would interpret this text as a firm injunction preventing me from using IPv4LL on any interface which has a routable address however wrong and unuseable that address is. The only get out is weasle words about the meaning of "configured". > > Philip > > > ----- Original Message ----- > From: "Erik Guttman" > To: > Sent: Tuesday, May 25, 2004 4:56 PM > Subject: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? > > > > LL70 > > > > This issue will remain open for comment until June 2, 2004. > > After that point, if no comments are received, the issue will be > > resolved by making DNAv4 normative and leaving the text as it currently > > stands. > > > > Bernard suggests the following resolution, which should allow DNAv4 to > > remain an informative reference. > > > > Was: > > 1.9. When to configure a Link-Local IPv4 address > > > > Having addresses of multiple different scopes assigned to an > > interface, with no adequate way to determine in what circumstances > > each address should be used, leads to complexity for applications and > > confusion for users. A host with an address on a link can > > communicate with all other devices on that link, whether those > > devices use Link-Local addresses, or routable addresses. For these > > reasons, a host SHOULD NOT have both a valid routable address and a > > Link-Local IPv4 address configured on the same interface. > > > > > > A routable address is any address that is: > > > > * a unicast address (see Section 1.2) > > * not a loopback address > > * not contained within the 169.254/16 prefix reserved for Link-Local > > IPv4 addresses > > > > A "valid routable address" is a routable address that passes the > > reachability test described in section 2 of "Detection of Network > > Attachment (DNA) in IPv4" [DNAv4]. > > > > The assignment and use of a Link-Local IPv4 address on an interface > > is based solely on the state of the interface, and is independent of > > any other protocols such as DHCP. A host MUST NOT alter its behavior > > and use of other protocols such as DHCP because the host has assigned > > a Link-Local IPv4 address to an interface. > > > > When an interface has a valid routable address configured on an > > interface, the host SHOULD NOT also assign a Link-Local IPv4 address > > to that interface. > > > > If a host finds that an interface that was previous configured with a > > Link-Local IPv4 address is now configured with a valid routable > > address, the host MUST always use the routable address when > > initiating new communications, and MUST cease advertising the > > availability of the Link-Local IPv4 address through whatever > > mechanisms that address had been made known to others. The host > > SHOULD continue to use the Link-Local IPv4 address for communications > > underway when the routable address was configured, and MAY continue > > to accept new communications addressed to the Link-Local IPv4 > > address. Ways in which a valid routable address might be configured > > for the interface include: > > > > * Manual configuration > > * Address assignment through DHCP > > * Roaming of the host to a network on which a routable address > > assigned to the interface is valid > > > > If a host finds that an interface that was previously configured with > > a valid routable address no longer has a valid routable address, the > > host MAY identify a usable Link-Local IPv4 address (as described in > > section 2) and assign that address to the interface. Ways in which a > > valid routable address might no longer be assigned to an interface > > include: > > > > * Removal of the address from the interface through manual > > configuration > > * Expiration of the lease on the address assigned through DHCP > > * Roaming of the host to a new network on which the address is no > > longer valid. > > > > Further discussion of the issues in detection of transient failures > > and the use of DHCP in response to network attachment failure is > > provided in "Detection of Network Attachment (DNA) in IPv4". [DNAv4] > > > > > > > > Becomes: > > > > 1.9. When to configure an IPv4 Link-Local address > > > > Having addresses of multiple different scopes assigned to an > > interface, with no adequate way to determine in what circumstances > > each address should be used, leads to complexity for applications and > > confusion for users. A host with an address on a link can > > communicate with all other devices on that link, whether those > > devices use Link-Local addresses, or routable addresses. For these > > reasons, a host SHOULD NOT have both a routable address and an IPv4 > > Link-Local address configured on the same interface. > > > > The assignment and use of an IPv4 Link-Local address on an interface > > is based solely on the state of the interface, and is independent of > > any other protocols such as DHCP. A host MUST NOT alter its behavior > > and use of other protocols such as DHCP because the host has assigned > > an IPv4 Link-Local address to an interface. > > > > When an interface has a routable address configured on an interface, > > is based solely on the state of the interface, and is independent of > > any other protocols such as DHCP. A host MUST NOT alter its behavior > > and use of other protocols such as DHCP because the host has assigned > > an IPv4 Link-Local address to an interface. > > > > When an interface has a routable address configured on an interface, > > the host SHOULD NOT also assign an IPv4 Link-Local address to that > > interface. > > > > If a host finds that an interface that was previous configured with > > an IPv4 Link-Local address is now configured with a routable address, > > the host MUST use the routable address when initiating new > > communications, and MUST cease advertising the availability of the > > IPv4 Link-Local address through whatever mechanisms that address had > > been made known to others. The host SHOULD continue to use the IPv4 > > Link-Local address for communications underway when the routable > > address was configured, and MAY continue to accept new communications > > addressed to the IPv4 Link-Local address. Ways in which a routable > > address might be configured for the interface include: > > > > * Manual configuration > > * Address assignment through DHCP > > * Roaming of the host to a network on which the host has a > > valid routable address > > > > If a host finds that a routable address is no longer assigned to an > > interface, the host MAY identify a usable IPv4 Link-Local address (as > > described in section 2) and assign that address to the interface. > > Ways in which a routable address might no longer be assigned to an > > interface include: > > > > * Removal of the address from the interface through manual > > configuration > > * Expiration of the lease on the address assigned through DHCP > > * Roaming of the host to a new network on which the address is no > > longer valid. > > > > Further discussion of address assignment and the detection of network > > attachment is provided in [DNAv4]. > > > > Erik Guttman > > ZEROCONF WG Chair > > > > From owner-zeroconf@merit.edu Thu May 27 17:37:14 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27938 for ; Thu, 27 May 2004 17:37:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90A22912C8; Thu, 27 May 2004 17:37:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BCCD912C9; Thu, 27 May 2004 17:37:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70D2A912C8 for ; Thu, 27 May 2004 17:37:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12EFF5927B; Thu, 27 May 2004 17:37:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 6798F590C0 for ; Thu, 27 May 2004 17:37:05 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4RLdUE18461 for ; Thu, 27 May 2004 14:39:30 -0700 Date: Thu, 27 May 2004 14:39:30 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: WG ACTION: 1 week continued discussion [LL63] Text should be more explicit Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk First choice D, second choice B. From owner-zeroconf@merit.edu Thu May 27 18:31:49 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01564 for ; Thu, 27 May 2004 18:31:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1C679912CC; Thu, 27 May 2004 18:28:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7200912CF; Thu, 27 May 2004 18:28:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DCFC912CC for ; Thu, 27 May 2004 18:28:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F38CA59418; Thu, 27 May 2004 18:28:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 49650591AE for ; Thu, 27 May 2004 18:28:40 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4RMV5g21461 for ; Thu, 27 May 2004 15:31:05 -0700 Date: Thu, 27 May 2004 15:31:05 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following paragraph (which Philip and others objected to) was not included in my original proposal, so I'd agree that it is meaningless and should be deleted: " When an interface has a routable address configured on an interface, is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned an IPv4 Link-Local address to an interface." I also agree with Philip's proposed editorial improvement: " When a routable address is configured on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address to that interface." In terms of the substantative issue, I agree with Philip that it makes no sense to prevent a host from using IPv4LL on an interface that has an incorrect or unuseable routable address. But I'm not clear that the term "valid" (at least in the DNAv4 usage) is helpful in making this clear. IMHO, the only thing that matters in a given situation is whether the host will use a given address to source packets or will accept packets destined to that address. This can differ between existing connections and new connections. Unfortunately, I think the text contradicts itself in places, using SHOULD and SHOULD NOT normative language to describe the same behavior. Here is the proposed text with Philip's two editorial comments incorporated. Comments/improvements/edits welcome. " Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a routable address and an IPv4 Link-Local address configured on the same interface. When a routable address is configured on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface. The assignment of an IPv4 Link-Local address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has assigned an IPv4 Link-Local address to an interface. If a host finds that an interface that was previously configured with an IPv4 Link-Local address is now configured with a routable address, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the IPv4 Link-Local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the IPv4 Link-Local address. Ways in which a routable address might be configured for the interface include: * Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which the host has a valid routable address If a host finds that a routable address is no longer configured on an interface, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and assign that address to the interface. Ways in which a routable address might no longer be configured on an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid. Further discussion of address assignment and the detection of network attachment is provided in [DNAv4]." From owner-zeroconf@merit.edu Mon May 31 11:29:28 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26506 for ; Mon, 31 May 2004 11:29:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BECC91217; Mon, 31 May 2004 11:29:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDB9291252; Mon, 31 May 2004 11:29:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B788891217 for ; Mon, 31 May 2004 11:29:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98A3E59439; Mon, 31 May 2004 11:29:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id CFD82596AF for ; Mon, 31 May 2004 11:29:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4VFVOL06429 for ; Mon, 31 May 2004 08:31:24 -0700 Date: Mon, 31 May 2004 08:31:24 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: Questions about LL70 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I've been reading the proposed text again, and as noted earlier, am not sure what it means. Some questions below: "For these reasons, a host SHOULD NOT have both a routable address and an IPv4 Link-Local address configured on the same interface. When a routable address is configured on an interface, the host SHOULD NOT also assign an IPv4 Link-Local address on that interface." What does it mean to have an address "configured" on an interface? Can a host send a packet with a source address if the address isn't configured, and can a host receive a packet destined to an address without it being configured? Does "assigning" an address to an interface mean that this address is "configured"? " If a host finds that an interface that was previously configured with an IPv4 Link-Local address is now configured with a routable address, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. " This paragraph appears to define what it means to "configure" an address: the address is used when initiating new connections and when advertising availability of an address. " The host SHOULD continue to use the IPv4 Link-Local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the IPv4 Link-Local address." According to this paragraph an address that is not "configured" can be used as the source address of packets (for connections that were already underway), and can be a destination address either for connections that were already underway or for new connections. " If a host finds that a routable address is no longer configured on an interface, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and assign that address to the interface." Does "assigning" a Link-Local address imply that this address is now "configured" as described above? I think the answer is yes -- this address will be used as the source address as new connections. Based on these observations, I'd recommend that the following definition be added to the terminology section: "Configured Address A configured address is an address that the host may use in initiating new connections, and also in advertising address availability. A configured address is also an address on which a host is willing to receive packets." Using this definition, the proposed text reads as follows: " Having addresses of multiple different scopes configured on an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a routable address and an IPv4 Link-Local address configured on the same interface. When a routable address is configured on an interface, the host SHOULD NOT also configure an IPv4 Link-Local address on that interface. The configuration of an IPv4 Link-Local address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP. A host MUST NOT alter its behavior and use of other protocols such as DHCP because the host has configured an IPv4 Link-Local address to an interface. If a host finds that an interface that was previously configured with an IPv4 Link-Local address is now configured with a routable address, the host MUST use the routable address when initiating new communications, and MUST cease advertising the availability of the IPv4 Link-Local address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the IPv4 Link-Local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the IPv4 Link-Local address. Ways in which a routable address might be configured for the interface include: * Manual configuration * Address assignment through DHCP * Roaming of the host to a network on which the host has a valid routable address If a host finds that a routable address is no longer configured on an interface, the host MAY identify a usable IPv4 Link-Local address (as described in section 2) and configure that address on the interface. Ways in which a routable address might no longer be configured on an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid. Further discussion of address configuration and the detection of network attachment is provided in [DNAv4]." From owner-zeroconf@merit.edu Mon May 31 12:22:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28936 for ; Mon, 31 May 2004 12:22:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 138EA9121A; Mon, 31 May 2004 12:22:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D544891257; Mon, 31 May 2004 12:22:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D585B9121A for ; Mon, 31 May 2004 12:22:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3568596BC; Mon, 31 May 2004 12:22:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 35ED2596AF for ; Mon, 31 May 2004 12:22:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4VGNvq09504 for ; Mon, 31 May 2004 09:23:57 -0700 Date: Mon, 31 May 2004 09:23:57 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I think the resolution of LL 58 re-introduces a normative dependency on [DNAv4]. The proposed resolution is: " This document uses the term "routable address" to refer to all valid unicast IPv4 addresses outside the 169.254/16 prefix that may be forwarded via routers. This includes all global addresses and private addresses such as Net 10/8 [RFC1918], but not loopback addresses such as 127.0.0.1." Yet the term "valid" is defined by reference to [DNAv4] in Section 1.9: " A valid routable address is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]." My recommendation would be to delete the term "valid" from the definition of "routable address", and also to delete the definition of valid in Section 1.9 and add the following definition to the terminology section: A "valid routable address" is a routable address which is either statically assigned or whose lease has not expired and that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. From owner-zeroconf@merit.edu Mon May 31 12:57:55 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00812 for ; Mon, 31 May 2004 12:57:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38A4B91258; Mon, 31 May 2004 12:57:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0841891259; Mon, 31 May 2004 12:57:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E9A891258 for ; Mon, 31 May 2004 12:57:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA292596B2; Mon, 31 May 2004 12:57:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 66E72596E1 for ; Mon, 31 May 2004 12:57:46 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4VGxow11576 for ; Mon, 31 May 2004 09:59:50 -0700 Date: Mon, 31 May 2004 09:59:50 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: resolution of LL52 LL54 LL55 LL56 LL57 LL58 LL59 LL60 LL61 LL62LL64 LL65 LL66 LL67 LL68 LL69 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk In looking over LL56, I think the debate disclosed that the text really was unclear. So while there may not have been consensus for Stuart's proposed change, I do think that the text needs to be clarified. For example, the text states: "IPv4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded, they SHOULD only be sent when a Link-Local address is used as the source address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply." This text really is unclear. It could be read (and was ready by Stuart and myself) as implying that an LLMNR Response (even one not including a Link-Local address in the RRs) SHOULD only be sent when a Link-Local address is used as the source address. The issue text appears to imply that in fact the following was meant: "IPv4 addresses and names which can only be resolved on the local link SHOULD NOT be forwarded beyond the local link. IPv4 Link-Local addresses SHOULD only be sent when a Link-Local address is used as the source address. This strong advice should hinder limited scope addresses and names from leaving the context in which they apply." From owner-zeroconf@merit.edu Mon May 31 13:12:25 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01715 for ; Mon, 31 May 2004 13:12:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDD6E91259; Mon, 31 May 2004 13:12:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF6BB9125B; Mon, 31 May 2004 13:12:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BBF9491259 for ; Mon, 31 May 2004 13:12:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A049B59723; Mon, 31 May 2004 13:12:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id C107D59665 for ; Mon, 31 May 2004 13:12:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4VHDol12443 for ; Mon, 31 May 2004 10:13:50 -0700 Date: Mon, 31 May 2004 10:13:49 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: LL61 resolution Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The LL61 proposed resolution defines PROBE_NUM and DEFEND_INTERVAL. However, values for these constants are not suggested in Section 9. We do have PROBE_N (defined as 2) and NUM_PROBES (defined as 3). From owner-zeroconf@merit.edu Mon May 31 21:27:17 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26893 for ; Mon, 31 May 2004 21:27:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4994191227; Mon, 31 May 2004 21:27:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B54291235; Mon, 31 May 2004 21:27:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3BE8591227 for ; Mon, 31 May 2004 21:27:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29BB2595FA; Mon, 31 May 2004 21:27:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id DAB0E596A7 for ; Mon, 31 May 2004 21:27:05 -0400 (EDT) Received: from delta.noi.kre.to (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id i511QRn05919; Tue, 1 Jun 2004 08:26:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.9/8.11.6) with ESMTP id i511PttO010350; Tue, 1 Jun 2004 08:25:57 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jun 2004 08:25:55 +0700 Message-ID: <28709.1086053155@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 31 May 2004 09:23:57 -0700 (PDT) From: Bernard Aboba Message-ID: | I think the resolution of LL 58 re-introduces a normative | dependency on [DNAv4]. Yes (that was always there), but ... | A "valid routable address" is a routable address which is either | statically assigned or whose lease has not expired and that passes | the reachability test described in section 2 of "Detection of Network | Attachment (DNA) in IPv4" [DNAv4]. does nothing to change that, it is still a normative reference. kre From owner-zeroconf@merit.edu Mon May 31 23:54:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03154 for ; Mon, 31 May 2004 23:54:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A11A91235; Mon, 31 May 2004 23:54:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09D189124C; Mon, 31 May 2004 23:54:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BFDE91235 for ; Mon, 31 May 2004 23:54:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EAF7559714; Mon, 31 May 2004 23:54:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 6848C59713 for ; Mon, 31 May 2004 23:54:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i513tcO16761; Mon, 31 May 2004 20:55:38 -0700 Date: Mon, 31 May 2004 20:55:38 -0700 (PDT) From: Bernard Aboba To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: WG ACTION: 1 week continued discussion [LL70] DNAv4 normative or informative? In-Reply-To: <28709.1086053155@munnari.OZ.AU> Message-ID: References: <28709.1086053155@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > | I think the resolution of LL 58 re-introduces a normative > | dependency on [DNAv4]. > > Yes (that was always there), but ... > > | A "valid routable address" is a routable address which is either > | statically assigned or whose lease has not expired and that passes > | the reachability test described in section 2 of "Detection of Network > | Attachment (DNA) in IPv4" [DNAv4]. > > does nothing to change that, it is still a normative reference. The proposal is to make this a definition in the terminology section, and remove all normative uses of the term "valid". With the changes, the only use of the term in the document is to describe ways in which an address *might* be configured.