From thomas@thomasclausen.org Thu Feb 4 04:43:36 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740573A6849 for ; Thu, 4 Feb 2010 04:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAYX80wUu0Aj for ; Thu, 4 Feb 2010 04:43:35 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8899C3A67D8 for ; Thu, 4 Feb 2010 04:43:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D2D0B430348; Thu, 4 Feb 2010 04:44:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id CE28343034E; Thu, 4 Feb 2010 04:44:20 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <00a601caa19e$7122c810$53685830$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Feb 2010 13:43:03 +0100 References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 12:43:36 -0000 On Jan 30, 2010, at 12:22 PM, Teco Boot wrote: > Charlie, > >>>>> My requirement is that L3 communication between nodes, that have >>>>> L2 >>>>> connectivity, must be possible in all conditions, including >> conditions >>>>> with a non-operational MANET protocol. >>>>> >>>>> >>>> I don't see that the addressing model prevents any such L3 >>>> communication. >>>> >>> How are packets forwarded? >>> The destination address (which is direct L2 neighbor in this case) >>> needs to be found in a forwarding table, normally the routing table. >>> Neighbor cache could be used also. >>> How to get this info in such a table? >>> >> >> Node A broadcasts a "Hello" message. >> Node B hears it, and puts node A in its forwarding table. >> >> The nodes may take subsequent actions to verify >> bidirectionality, exchange other table entries, etc. > > My point is that L3 communication becomes dependent on a L3 routing > protocol. We didn't have this in the IP stack before. Well.....L3 communication depends on a populated routing table, thus on something populating the routing table. L3 multi-hop communications depends on something clever (a routing protocol, a DHCP server, a human, for example and depending on the place) populating routing tables. I do not see what this document does that changes that? >> One should think of updating the IPv6 RFCs, since the link-local >> constructions contained therein were written _explicitly_ in >> disregard of the needs for wireless links of the sort familiar to >> practitioners in this group. > > I use link-locals on wireless links, and it works great. > What is your point? I am not Charlie, so I won't speak to what his point is.....but a point can be made that you have observed a particular and specific setup in which this holds true. That's good! This document aims at describing something that can hold in more than one particular and specific setup and, if respected, will allow unencumbered operation, outside of a particular and specific setup. Cheers, Thomas > Regards, Teco. > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Thomas@ThomasClausen.org Thu Feb 4 04:43:38 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C943A683D for ; Thu, 4 Feb 2010 04:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YMk9S2oFxIe for ; Thu, 4 Feb 2010 04:43:37 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id B019628C0D7 for ; Thu, 4 Feb 2010 04:43:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 30D1F430350; Thu, 4 Feb 2010 04:44:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 2330743034D; Thu, 4 Feb 2010 04:44:22 -0800 (PST) Message-Id: <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <008c01caa0fe$0eee3530$2cca9f90$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Feb 2010 13:43:08 +0100 References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 12:43:38 -0000 Dear Teco, Thanks for your review. See comments below. On Jan 29, 2010, at 17:13 PM, Teco Boot wrote: > Ryuji, Thomas, > > I commented on the document. > I don't see any reflection in the document, nor received questions > for clarification. > > I am quite uncomfortable with a large drawback of the proposed > addressing model, which makes it unacceptable for the deployed MANETs > I am involved in. > My requirement is that L3 communication between nodes, that have L2 > connectivity, must be possible in all conditions, including conditions > with a non-operational MANET protocol. I would wonder if you have a MANET if you are not running a MANET protocol? That said, I am not sure I understand what the drawbacks you identify are. The document takes the "most conservative" approach, i.e. a network in which interfaces are configured in accordance to this, should allow any operation. The document, as I read it, uses "should", which does not prohibit alternatives (with the usual caveat concerning a "should"). I believe that if you have no "MANET protocol", but still want L3 communication between identified interfaces (IP addresses), then you would want a mechanism/protocol assigning these addresses? For the reasons outlined in that document, those addresses should (to allow any operation / any protocol to operate) satisfy the suggested rules in the document. If you do deviate from the "should", the usual caveats for a "should" apply -- and it might be OK for your deployment? Cheers, Thomas > Maybe this drawback is overlooked or underestimated. > > And the text on link locals does not describe how IPv6 works. LLs are > used in MANETs for multiple purposes. We can't without. > > My other comments are textual or on incompleteness. Especially, the > document doesn't describe anything useful for assigning globals. > > Regards, Teco > > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] >> Namens >> Ryuji Wakikawa >> Verzonden: woensdag 27 januari 2010 9:00 >> Aan: Emmanuel Baccelli >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document >> >> Hi all, >> >> Emmanuel updated the document according to the WG last call. >> Please confirm the changes specially if you sent comments during >> WGLC. >> >> We will pass this document to Jari for the next stage soon. >> >> thanks, >> ryuji >> >> >> On 2010/01/26, at 4:09, Emmanuel Baccelli wrote: >> >>> Folks, >>> >>> here's an updated version of the ad hoc addressing model document, >> following the comments gathered during working group last call. We >> took >> as much as possible on board, as discussed on the mailing list. >> Please >> review this revision, and let us know if you have further comments. >>> >>> http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >>> >>> Regards, >>> >>> Emmanuel >>> >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From Thomas@ThomasClausen.org Thu Feb 4 04:43:40 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDE928C1A1 for ; Thu, 4 Feb 2010 04:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE2iu0rEYhqv for ; Thu, 4 Feb 2010 04:43:39 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id A3DE93A683D for ; Thu, 4 Feb 2010 04:43:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 25EA743034E; Thu, 4 Feb 2010 04:44:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4E5DA43034D; Thu, 4 Feb 2010 04:44:25 -0800 (PST) Message-Id: <83CA91EB-8805-44D6-AD0A-4F1288D11171@thomasclausen.org> From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <009001caa10d$8729a2a0$957ce7e0$@nl> Content-Type: multipart/alternative; boundary=Apple-Mail-70--782617295 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Feb 2010 13:43:11 +0100 References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 12:43:40 -0000 --Apple-Mail-70--782617295 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jan 29, 2010, at 19:04 PM, Teco Boot wrote: >> >> This isn't true. You can build MANETs without using link-local at >> all >> in any fashion. >> >> I'm not saying you have to ignore link-local. > > If LLs are configured, they are used for L2 address resolving. > Also for MANET protocols, if destination address is LL mcast. I do not think that this document speaks to multicast addresses at all. Thomas --Apple-Mail-70--782617295 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
On Jan 29, 2010, at 19:04 PM, Teco Boot wrote:

<SNIP>


This isn't true.  You can build MANETs without using link-local at all
in any fashion.

I'm not saying you have to ignore link-local.

If LLs are configured, they are used for L2 address resolving.
Also for MANET protocols, if destination address is LL mcast.

I do not think that this document speaks to multicast addresses at all.

Thomas
--Apple-Mail-70--782617295-- From zach@sensinode.com Thu Feb 4 05:22:06 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C483A6C1C for ; Thu, 4 Feb 2010 05:22:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBM8Cixujx08 for ; Thu, 4 Feb 2010 05:22:05 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E624E28C198 for ; Thu, 4 Feb 2010 05:22:04 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o14DMiJX007975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 4 Feb 2010 15:22:44 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> Date: Thu, 4 Feb 2010 15:22:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0AECC3F0-0712-4466-B216-5945DAE3E36C@sensinode.com> References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 13:22:06 -0000 On Feb 4, 2010, at 14:43 , Thomas Heide Clausen wrote: >=20 > On Jan 29, 2010, at 17:13 PM, Teco Boot wrote: >=20 >> Ryuji, Thomas, >>=20 >> I commented on the document. >> I don't see any reflection in the document, nor received questions >> for clarification. >>=20 >> I am quite uncomfortable with a large drawback of the proposed >> addressing model, which makes it unacceptable for the deployed MANETs >> I am involved in. >> My requirement is that L3 communication between nodes, that have L2 >> connectivity, must be possible in all conditions, including = conditions >> with a non-operational MANET protocol. >=20 > I would wonder if you have a MANET if you are not running a MANET = protocol? >=20 > That said, I am not sure I understand what the drawbacks you identify = are. The document takes the "most conservative" approach, i.e. a network = in which interfaces are configured in accordance to this, should allow = any operation. The document, as I read it, uses "should", which does not = prohibit alternatives (with the usual caveat concerning a "should"). >=20 > I believe that if you have no "MANET protocol", but still want L3 = communication between identified interfaces (IP addresses), then you = would want a mechanism/protocol assigning these addresses? For the = reasons outlined in that document, those addresses should (to allow any = operation / any protocol to operate) satisfy the suggested rules in the = document. If you do deviate from the "should", the usual caveats for a = "should" apply -- and it might be OK for your deployment? I agree with this interpretation. The autoconf addressing model doesn't = prevent you from applying another mechanism in addition to the (really = minimal) base it provides. At least this is what we are doing in = 6lowpan. The autoconf model provides a way to model these "links with = undetermined properties" in a pretty clean way (best I have seen so = far... it is a mind-boggling problem). On top of that we are defining a = mechanism to bootstrap nodes, configure addresses etc. which works = without a routing protocol, or with one (e.g. RPL or MANET). This = doesn't directly apply to your case, just an example. So to really make such a network work you have options like: autoconf + manet (all nodes must be routers) autoconf + something (no routing) autoconf + something + manet (maybe to also support hosts?) autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now) I guess autoconf as a WG will go on to define "something", or at least = identify "something(s)" at some point? At least it would be useful to = help people really apply this model in practice. Zach >=20 > Cheers, >=20 > Thomas >=20 >=20 >=20 >> Maybe this drawback is overlooked or underestimated. >>=20 >> And the text on link locals does not describe how IPv6 works. LLs are >> used in MANETs for multiple purposes. We can't without. >>=20 >> My other comments are textual or on incompleteness. Especially, the >> document doesn't describe anything useful for assigning globals. >>=20 >> Regards, Teco >>=20 >>=20 >>> -----Oorspronkelijk bericht----- >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens >>> Ryuji Wakikawa >>> Verzonden: woensdag 27 januari 2010 9:00 >>> Aan: Emmanuel Baccelli >>> CC: autoconf@ietf.org >>> Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document >>>=20 >>> Hi all, >>>=20 >>> Emmanuel updated the document according to the WG last call. >>> Please confirm the changes specially if you sent comments during = WGLC. >>>=20 >>> We will pass this document to Jari for the next stage soon. >>>=20 >>> thanks, >>> ryuji >>>=20 >>>=20 >>> On 2010/01/26, at 4:09, Emmanuel Baccelli wrote: >>>=20 >>>> Folks, >>>>=20 >>>> here's an updated version of the ad hoc addressing model document, >>> following the comments gathered during working group last call. We = took >>> as much as possible on board, as discussed on the mailing list. = Please >>> review this revision, and let us know if you have further comments. >>>>=20 >>>> http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt >>>>=20 >>>> Regards, >>>>=20 >>>> Emmanuel >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>>=20 >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From alexandru.petrescu@gmail.com Thu Feb 4 05:55:08 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C903A6D13 for ; Thu, 4 Feb 2010 05:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX9+RtzXSsqq for ; Thu, 4 Feb 2010 05:55:07 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2EA063A6915 for ; Thu, 4 Feb 2010 05:55:07 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o14DtpE8025438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 4 Feb 2010 14:55:51 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o14Dtplw030967 for ; Thu, 4 Feb 2010 14:55:51 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o14Dto46014148 for ; Thu, 4 Feb 2010 14:55:51 +0100 Message-ID: <4B6AD1E6.1050006@gmail.com> Date: Thu, 04 Feb 2010 14:55:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <83CA91EB-8805-44D6-AD0A-4F1288D11171@thomasclausen.org> In-Reply-To: <83CA91EB-8805-44D6-AD0A-4F1288D11171@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 13:55:08 -0000 Le 04/02/2010 13:43, Thomas Heide Clausen a écrit : > > On Jan 29, 2010, at 19:04 PM, Teco Boot wrote: > > > >>> >>> This isn't true. You can build MANETs without using link-local at all >>> in any fashion. >>> >>> I'm not saying you have to ignore link-local. >> >> If LLs are configured, they are used for L2 address resolving. >> Also for MANET protocols, if destination address is LL mcast. > > I do not think that this document speaks to multicast addresses at all. Well I think it should :-) Alex > > Thomas > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Thu Feb 4 06:22:47 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EB0B3A6C08 for ; Thu, 4 Feb 2010 06:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKqxVOhlgFT2 for ; Thu, 4 Feb 2010 06:22:45 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 566C63A6DA5 for ; Thu, 4 Feb 2010 06:22:40 -0800 (PST) Received: (qmail 18354 invoked from network); 4 Feb 2010 15:23:22 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 4 Feb 2010 15:23:22 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> In-Reply-To: Date: Thu, 4 Feb 2010 15:22:52 +0100 Message-ID: <005501caa5a5$9b0fc7d0$d12f5770$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqll8eMbXnOY+7uSXKX2Dq8OqOo7wACFMcg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 14:22:47 -0000 Hi Thomas, >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: donderdag 4 februari 2010 13:43 >Aan: Teco Boot >CC: 'Charles E. Perkins'; autoconf@ietf.org >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > > >On Jan 30, 2010, at 12:22 PM, Teco Boot wrote: > >> Charlie, >> >>>>>> My requirement is that L3 communication between nodes, that have >>>>>> L2 >>>>>> connectivity, must be possible in all conditions, including >>> conditions >>>>>> with a non-operational MANET protocol. >>>>>> >>>>>> >>>>> I don't see that the addressing model prevents any such L3 >>>>> communication. >>>>> >>>> How are packets forwarded? >>>> The destination address (which is direct L2 neighbor in this case) >>>> needs to be found in a forwarding table, normally the routing table. >>>> Neighbor cache could be used also. >>>> How to get this info in such a table? >>>> >>> >>> Node A broadcasts a "Hello" message. >>> Node B hears it, and puts node A in its forwarding table. >>> >>> The nodes may take subsequent actions to verify >>> bidirectionality, exchange other table entries, etc. >> >> My point is that L3 communication becomes dependent on a L3 routing >> protocol. We didn't have this in the IP stack before. > >Well.....L3 communication depends on a populated routing table, thus >on something populating the routing table. >L3 multi-hop communications depends on something clever (a routing >protocol, a DHCP server, a human, for example and depending on the >place) populating routing tables. > >I do not see what this document does that changes that? Up to now, all IP addressing models I am aware of provide 1-hop L3 communication between nodes that have L2 connectivity. The proposed addressing model for MANETs breaks this. Now there is a need for something clever. This clever thing could be stopped. >>> One should think of updating the IPv6 RFCs, since the link-local >>> constructions contained therein were written _explicitly_ in >>> disregard of the needs for wireless links of the sort familiar to >>> practitioners in this group. >> >> I use link-locals on wireless links, and it works great. >> What is your point? > >I am not Charlie, so I won't speak to what his point is.....but a >point can be made that you have observed a particular and specific >setup in which this holds true. That's good! > >This document aims at describing something that can hold in more than >one particular and specific setup and, if respected, will allow >unencumbered operation, outside of a particular and specific setup. There is no reason not using link-locals for 1-hop traffic. If you say this is a particular and specific setup, is this a qualification for IPv6? If not, what are you referring to? Regards, Teco. From thomas@thomasclausen.org Thu Feb 4 10:07:01 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E5D3A6D5B for ; Thu, 4 Feb 2010 10:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FevCmr9buAz1 for ; Thu, 4 Feb 2010 10:07:00 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 453D93A6C8A for ; Thu, 4 Feb 2010 10:07:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 7B7F532284BA; Thu, 4 Feb 2010 10:07:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.216.193.96] (unknown [80.10.46.32]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 2C68B322849F; Thu, 4 Feb 2010 10:07:45 -0800 (PST) References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> Message-Id: <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> From: Thomas Heide Clausen To: Teco Boot In-Reply-To: <005501caa5a5$9b0fc7d0$d12f5770$@nl> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Thu, 4 Feb 2010 19:08:05 +0100 Cc: "" Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 18:07:01 -0000 On 4 f=C3=A9vr. 2010, at 15:22, "Teco Boot" wrote: > Hi Thomas, > >> -----Oorspronkelijk bericht----- >> Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >> Verzonden: donderdag 4 februari 2010 13:43 >> Aan: Teco Boot >> CC: 'Charles E. Perkins'; autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document >> >> >> On Jan 30, 2010, at 12:22 PM, Teco Boot wrote: >> >>> Charlie, >>> >>>>>>> My requirement is that L3 communication between nodes, that have >>>>>>> L2 >>>>>>> connectivity, must be possible in all conditions, including >>>> conditions >>>>>>> with a non-operational MANET protocol. >>>>>>> >>>>>>> >>>>>> I don't see that the addressing model prevents any such L3 >>>>>> communication. >>>>>> >>>>> How are packets forwarded? >>>>> The destination address (which is direct L2 neighbor in this case) >>>>> needs to be found in a forwarding table, normally the routing =20 >>>>> table. >>>>> Neighbor cache could be used also. >>>>> How to get this info in such a table? >>>>> >>>> >>>> Node A broadcasts a "Hello" message. >>>> Node B hears it, and puts node A in its forwarding table. >>>> >>>> The nodes may take subsequent actions to verify >>>> bidirectionality, exchange other table entries, etc. >>> >>> My point is that L3 communication becomes dependent on a L3 routing >>> protocol. We didn't have this in the IP stack before. >> >> Well.....L3 communication depends on a populated routing table, thus >> on something populating the routing table. >> L3 multi-hop communications depends on something clever (a routing >> protocol, a DHCP server, a human, for example and depending on the >> place) populating routing tables. >> >> I do not see what this document does that changes that? > > Up to now, all IP addressing models I am aware of provide 1-hop L3 > communication between nodes that have L2 connectivity. > > The proposed addressing model for MANETs breaks this. Now there > is a need for something clever. This clever thing could be > stopped. > What makes the route to the 'local network' appear in the routing =20 table? In that case the 'something clever' is whatever enters that =20 route. Often, that 'something clever' is the same thing as what =20 configures the interface.... Thomas > > >>>> One should think of updating the IPv6 RFCs, since the link-local >>>> constructions contained therein were written _explicitly_ in >>>> disregard of the needs for wireless links of the sort familiar to >>>> practitioners in this group. >>> >>> I use link-locals on wireless links, and it works great. >>> What is your point? >> >> I am not Charlie, so I won't speak to what his point is.....but a >> point can be made that you have observed a particular and specific >> setup in which this holds true. That's good! >> >> This document aims at describing something that can hold in more than >> one particular and specific setup and, if respected, will allow >> unencumbered operation, outside of a particular and specific setup. > > There is no reason not using link-locals for 1-hop traffic. > If you say this is a particular and specific setup, is this a > qualification for IPv6? > If not, what are you referring to? > > > Regards, Teco. > > From charles.perkins@earthlink.net Thu Feb 4 10:13:51 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12E1728C0FA for ; Thu, 4 Feb 2010 10:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmKdhOBWSQS5 for ; Thu, 4 Feb 2010 10:13:50 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id F3F7D3A693E for ; Thu, 4 Feb 2010 10:13:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ojg77E/3HHPH21qplbeqq1VXxHHAZyTolhZPXGCFtf0rtthWbPlujvNdY7UXx48l; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.21]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Nd6Dq-0007rl-Ul; Thu, 04 Feb 2010 13:14:35 -0500 Message-ID: <4B6B0E85.5050101@earthlink.net> Date: Thu, 04 Feb 2010 10:14:29 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> In-Reply-To: <005501caa5a5$9b0fc7d0$d12f5770$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f521bd244cff9cf4200f298b096c3a7638b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2010 18:13:51 -0000 Hello Teco, On 2/4/2010 6:22 AM, Teco Boot wrote: > > Up to now, all IP addressing models I am aware of provide 1-hop L3 > communication between nodes that have L2 connectivity. > If I get your point, what you mean is that when two nodes share a link, they can use L3 protocols to communicate. As far as I understand it, the addressing model does not change this. IP supports point-to-point communication between such "adjacent" nodes. How adjacency is discovered is usually considered out of scope. Either subnet prefixes are "assigned" (suddenly, it doesn't look like a Manet anymore) or "discovered" (oops, we're running new protocols) or "assumed". In the latter case, you'd better make your assumptions minimal, or else (protocol-wise) you are moving back into traditional a fixed network model. I know it's nicer there and all. > The proposed addressing model for MANETs breaks this. Now there > is a need for something clever. This clever thing could be > stopped. > I do not agree with this. See above. I also do not agree that we must avoid being clever. However, I agree that simpler is better, all the while adhering to Einstein's famous dictum. > There is no reason not using link-locals for 1-hop traffic. > If you say this is a particular and specific setup, is this a > qualification for IPv6? > If not, what are you referring to? > I read this, and had to smile. Of course there's no reason to avoid link-locals for 1-hop traffic as long as you _know_ it's one hop. In fact, blast away. But for people who are running networks without such comforts, assurance of availability for a L2 communication channel is often necessary or at least highly desirable. Then suddenly your link-local address is potentially (a) invalid (b) unavailable or (c) ambiguous. These are normally considered poor indicators for IP-based communications. And that is the problem needing solution in the general case, which has motivated the current form of the addressing model document. Regards, Charlie P. From teco@inf-net.nl Fri Feb 5 00:08:16 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6573B28C0FB for ; Fri, 5 Feb 2010 00:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRxIka3BkrHS for ; Fri, 5 Feb 2010 00:08:15 -0800 (PST) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id F0E353A67C1 for ; Fri, 5 Feb 2010 00:08:14 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Feb 2010 09:09:03 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> In-Reply-To: <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> Date: Fri, 5 Feb 2010 09:09:03 +0100 Message-ID: <003501caa63a$7b15ca20$71415e60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlxPeeem995k3XReKEvIYlnIqOfwAc2mPw Content-Language: nl X-OriginalArrivalTime: 05 Feb 2010 08:09:03.0391 (UTC) FILETIME=[7AE962F0:01CAA63A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 08:08:16 -0000 Hi Thomas, >>>> My point is that L3 communication becomes dependent on a L3 routing >>>> protocol. We didn't have this in the IP stack before. >>> >>> Well.....L3 communication depends on a populated routing table, thus >>> on something populating the routing table. >>> L3 multi-hop communications depends on something clever (a routing >>> protocol, a DHCP server, a human, for example and depending on the >>> place) populating routing tables. >>> >>> I do not see what this document does that changes that? >> >> Up to now, all IP addressing models I am aware of provide 1-hop L3 >> communication between nodes that have L2 connectivity. >> >> The proposed addressing model for MANETs breaks this. Now there >> is a need for something clever. This clever thing could be >> stopped. > >What makes the route to the 'local network' appear in the routing >table? In that case the 'something clever' is whatever enters that >route. Often, that 'something clever' is the same thing as what >configures the interface.... The IP stack puts the configured prefixes on IP interfaces in the routing table. This provides L3 connectivity whenever there is a L2 link. The 'something clever' puts longer prefixes in the routing table. This could introduce multi-hop paths for 1-hop reachable nodes, for sure when link metrics are in place. And of course multi-hop paths to nodes that are in the MANET, but not 1-hop reachable. I strongly disagree with "that 'something clever' is the same thing as what configures the interface". Our old charter was clear the Autoconf mechanism shall be independent of MANET protocols. Regards, Teco. From teco@inf-net.nl Fri Feb 5 00:08:29 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6B5628C0FB for ; Fri, 5 Feb 2010 00:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPYxWvOOXwaF for ; Fri, 5 Feb 2010 00:08:29 -0800 (PST) Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id 7193E3A67A2 for ; Fri, 5 Feb 2010 00:08:28 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Feb 2010 09:09:17 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> In-Reply-To: <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> Date: Fri, 5 Feb 2010 09:09:17 +0100 Message-ID: <003601caa63a$83515560$89f40020$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqll8glP2djW/7nS6uhYzn7kRqkjgADcqEg Content-Language: nl X-OriginalArrivalTime: 05 Feb 2010 08:09:17.0060 (UTC) FILETIME=[830F1C40:01CAA63A] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 08:08:29 -0000 Hi Thomas, >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: donderdag 4 februari 2010 13:43 >Aan: Teco Boot >CC: 'Ryuji Wakikawa'; autoconf@ietf.org >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > >Dear Teco, > >Thanks for your review. See comments below. > >On Jan 29, 2010, at 17:13 PM, Teco Boot wrote: > >> Ryuji, Thomas, >> >> I commented on the document. >> I don't see any reflection in the document, nor received questions >> for clarification. >> >> I am quite uncomfortable with a large drawback of the proposed >> addressing model, which makes it unacceptable for the deployed MANETs >> I am involved in. >> My requirement is that L3 communication between nodes, that have L2 >> connectivity, must be possible in all conditions, including conditions >> with a non-operational MANET protocol. > >I would wonder if you have a MANET if you are not running a MANET >protocol? The MANET protocol could get stopped, e.g. maintenance. I am involved in MANETs in real world deployments. The requirement comes from operational needs. >That said, I am not sure I understand what the drawbacks you identify >are. The document takes the "most conservative" approach, i.e. a >network in which interfaces are configured in accordance to this, >should allow any operation. The document, as I read it, uses "should", >which does not prohibit alternatives (with the usual caveat concerning >a "should"). I thought we should work on a practical addressing model. In practice, it is useful to have IP access to nearby nodes, also when the MANET protocol is non-operational. >I believe that if you have no "MANET protocol", but still want L3 >communication between identified interfaces (IP addresses), then you >would want a mechanism/protocol assigning these addresses? I don't want "no MANET protocol". I want L3 connectivity when there is a L2 link, and the MANET protocol is non-operational. > For the >reasons outlined in that document, those addresses should (to allow >any operation / any protocol to operate) satisfy the suggested rules >in the document. If you do deviate from the "should", the usual >caveats for a "should" apply -- and it might be OK for your deployment? Yes, we all are free to ignore the document. But there were strong opinions that the defined addressing models shall work in all scenarios? The addressing model I use works great for all proactive MANET protocols I am aware of. For the reactive routing protocols, there are some implementation issues: The RREQ should be triggered after "address not reachable", i.e. interaction with ARP/ND. Regards, Teco From teco@inf-net.nl Fri Feb 5 00:38:11 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C28B28C10B for ; Fri, 5 Feb 2010 00:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4IQq+7dFBeW for ; Fri, 5 Feb 2010 00:38:10 -0800 (PST) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 0D44828C118 for ; Fri, 5 Feb 2010 00:38:09 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Feb 2010 09:38:58 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <4B6B0E85.5050101@earthlink.net> In-Reply-To: <4B6B0E85.5050101@earthlink.net> Date: Fri, 5 Feb 2010 09:38:58 +0100 Message-ID: <003e01caa63e$a8d190d0$fa74b270$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlxerOJgeU73BBS9S+xt0w9pPaWQAdMctA Content-Language: nl X-OriginalArrivalTime: 05 Feb 2010 08:38:58.0137 (UTC) FILETIME=[A8A9E490:01CAA63E] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 08:38:11 -0000 Hi Charlie, >> Up to now, all IP addressing models I am aware of provide 1-hop L3 >> communication between nodes that have L2 connectivity. >> > >If I get your point, what you mean is that when two nodes >share a link, they can use L3 protocols to communicate. > >As far as I understand it, the addressing model does not >change this. IP supports point-to-point communication >between such "adjacent" nodes. > >How adjacency is discovered is usually considered >out of scope. Either subnet prefixes are "assigned" >(suddenly, it doesn't look like a Manet anymore) >or "discovered" (oops, we're running new protocols) >or "assumed". In the latter case, you'd better make >your assumptions minimal, or else (protocol-wise) >you are moving back into traditional a fixed network >model. I know it's nicer there and all. Thanks for this analysis. >> The proposed addressing model for MANETs breaks this. Now there >> is a need for something clever. This clever thing could be >> stopped. >> > >I do not agree with this. See above. It is fact of life that the "clever thing could be stopped". And existing IP addressing models don't depend on such clever thing. Here, we have the "assumption". Right? > I also do not >agree that we must avoid being clever. Agreed. That is why I use an addressing model that is better resistant against failures. > However, >I agree that simpler is better, all the while adhering >to Einstein's famous dictum. > >> There is no reason not using link-locals for 1-hop traffic. >> If you say this is a particular and specific setup, is this a >> qualification for IPv6? >> If not, what are you referring to? >> > >I read this, and had to smile. Of course there's no reason >to avoid link-locals for 1-hop traffic as long as you _know_ >it's one hop. In fact, blast away. OK, now we are there. MANET protocols that use RFC5498 can perfectly use link-locals. Same for L2 address resolving, as ND does. >But for people who are running networks without such >comforts, assurance of availability for a L2 communication >channel is often necessary or at least highly desirable. >Then suddenly your link-local address is potentially >(a) invalid (b) unavailable or (c) ambiguous. These >are normally considered poor indicators for IP-based >communications. What happens if your ULA or global is (a) invalid, (b) unavailable or (c) ambiguous? I don't see a difference with link-locals. Link-locals are used for protocols that require 1-hop communication or when no other addresses are available. In the latter, it is also 1-hop only. >And that is the problem needing solution in the >general case, which has motivated the current form >of the addressing model document. With IPv6 in mind, the general case can easily include link-locals. Wouldn't it be nice to support IPv6 basics? Regards, Teco From teco@inf-net.nl Fri Feb 5 03:23:41 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F24853A6BED for ; Fri, 5 Feb 2010 03:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjPqUrEsRBMK for ; Fri, 5 Feb 2010 03:23:40 -0800 (PST) Received: from CPSMTPM-EML106.kpnxchange.com (Cpsmtpm-eml106.kpnxchange.com [195.121.3.10]) by core3.amsl.com (Postfix) with ESMTP id 96FF43A6BD4 for ; Fri, 5 Feb 2010 03:23:39 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Feb 2010 12:24:28 +0100 From: "Teco Boot" To: "'Zach Shelby'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> <0AECC3F0-0712-4466-B216-5945DAE3E36C@sensinode.com> In-Reply-To: <0AECC3F0-0712-4466-B216-5945DAE3E36C@sensinode.com> Date: Fri, 5 Feb 2010 12:24:28 +0100 Message-ID: <005b01caa655$c7dad9c0$57908d40$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqlnSo05R9XVVCzReqnlJwTEDY04QAtgdRA Content-Language: nl X-OriginalArrivalTime: 05 Feb 2010 11:24:29.0045 (UTC) FILETIME=[C7F23250:01CAA655] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 11:23:41 -0000 Hi Zach, >> That said, I am not sure I understand what the drawbacks you identify >are. The document takes the "most conservative" approach, i.e. a network >in which interfaces are configured in accordance to this, should allow >any operation. The document, as I read it, uses "should", which does not >prohibit alternatives (with the usual caveat concerning a "should"). >> >> I believe that if you have no "MANET protocol", but still want L3 >communication between identified interfaces (IP addresses), then you >would want a mechanism/protocol assigning these addresses? For the >reasons outlined in that document, those addresses should (to allow any >operation / any protocol to operate) satisfy the suggested rules in the >document. If you do deviate from the "should", the usual caveats for a >"should" apply -- and it might be OK for your deployment? > >I agree with this interpretation. The autoconf addressing model doesn't >prevent you from applying another mechanism in addition to the (really >minimal) base it provides. At least this is what we are doing in >6lowpan. The autoconf model provides a way to model these "links with >undetermined properties" in a pretty clean way (best I have seen so >far... it is a mind-boggling problem). On top of that we are defining a >mechanism to bootstrap nodes, configure addresses etc. which works >without a routing protocol, or with one (e.g. RPL or MANET). This >doesn't directly apply to your case, just an example. > >So to really make such a network work you have options like: > >autoconf + manet (all nodes must be routers) >autoconf + something (no routing) >autoconf + something + manet (maybe to also support hosts?) >autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now) > >I guess autoconf as a WG will go on to define "something", or at least >identify "something(s)" at some point? At least it would be useful to >help people really apply this model in practice. The first, "autoconf + manet" is not complete. We need L2 address resolving. To me, it is obvious to use ND (to stay on IPv6). This makes the list like this: autoconf + ND + manet (all nodes must be routers) (maybe to also support hosts?) autoconf + ND (no routing) autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now) rpl is member of MANET protocol family, 6lowpan-nd is ND extension. So the list is: autoconf + ND* + manet* (all nodes must be routers) (maybe to also support hosts?) autoconf + ND* (no routing) My BRDP autoconf proposal runs on ND. Then, we have: ND* + manet* (all nodes must be routers) (maybe to also support hosts?) ND* (no routing) BRDP is easy to integrate in rpl. I am open for other ideas. Good to know there are MANET protocols that support attached "satellite" hosts. Regards, Teco From thomas@thomasclausen.org Fri Feb 5 06:10:46 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC863A6EFB for ; Fri, 5 Feb 2010 06:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1vh-XmPGFbX for ; Fri, 5 Feb 2010 06:10:45 -0800 (PST) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id D620B3A6F06 for ; Fri, 5 Feb 2010 06:10:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 8559E32349BD; Fri, 5 Feb 2010 06:11:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-120-130.w92-140.abo.wanadoo.fr [92.140.63.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6977032342C5; Fri, 5 Feb 2010 06:10:47 -0800 (PST) Message-Id: <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <003501caa63a$7b15ca20$71415e60$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Feb 2010 15:10:45 +0100 References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 14:10:46 -0000 Dear Teco, On Feb 5, 2010, at 09:09 AM, Teco Boot wrote: > Hi Thomas, > >>>>> My point is that L3 communication becomes dependent on a L3 >>>>> routing >>>>> protocol. We didn't have this in the IP stack before. >>>> >>>> Well.....L3 communication depends on a populated routing table, >>>> thus >>>> on something populating the routing table. >>>> L3 multi-hop communications depends on something clever (a routing >>>> protocol, a DHCP server, a human, for example and depending on the >>>> place) populating routing tables. >>>> >>>> I do not see what this document does that changes that? >>> >>> Up to now, all IP addressing models I am aware of provide 1-hop L3 >>> communication between nodes that have L2 connectivity. >>> >>> The proposed addressing model for MANETs breaks this. Now there >>> is a need for something clever. This clever thing could be >>> stopped. >> >> What makes the route to the 'local network' appear in the routing >> table? In that case the 'something clever' is whatever enters that >> route. Often, that 'something clever' is the same thing as what >> configures the interface.... > > The IP stack puts the configured prefixes on IP interfaces in the > routing table. This provides L3 connectivity whenever there is a L2 > link. > The 'something clever' puts longer prefixes in the routing table. That's your idea of what constitutes "something clever".....I never said that. > This could introduce multi-hop paths for 1-hop reachable nodes, for > sure > when link metrics are in place. And of course multi-hop paths to nodes > that are in the MANET, but not 1-hop reachable. > > I strongly disagree with "that 'something clever' is the same thing as > what configures the interface". I think it is quite clever when (quoting you): "The IP stack puts the configured prefixes on IP interfaces in the routing table." > Our old charter was clear the Autoconf > mechanism shall be independent of MANET protocols. I do not see anything in this document which imposes a MANET protocol. Thomas > > > Regards, Teco. > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Fri Feb 5 08:35:47 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF5F3A6AD0 for ; Fri, 5 Feb 2010 08:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sr+zmzvGOUq for ; Fri, 5 Feb 2010 08:35:46 -0800 (PST) Received: from CPSMTPM-EML104.kpnxchange.com (cpsmtpm-eml104.kpnxchange.com [195.121.3.8]) by core3.amsl.com (Postfix) with ESMTP id 043A428C1C7 for ; Fri, 5 Feb 2010 08:35:45 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML104.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Feb 2010 17:36:35 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> In-Reply-To: <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> Date: Fri, 5 Feb 2010 17:36:34 +0100 Message-ID: <007401caa681$61506090$23f121b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqmbUv9ceca6nIcTdakubrOgyYX4AAEz8/A Content-Language: nl X-OriginalArrivalTime: 05 Feb 2010 16:36:35.0664 (UTC) FILETIME=[61E17D00:01CAA681] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 16:35:47 -0000 Thomas, Is this catching words? Agreed that standard "not that clever" behavior of the IP stack is putting prefixes, configured on interfaces, in the routing table? Agreed that putting other prefixes is 'something clever'? Agreed that with the proposed addressing model, under conditions that the 'something clever' is not functioning, L3 communication fails for links between two nodes that have L2 communication? If I am missing something, please come up with it. Regards, Teco >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: vrijdag 5 februari 2010 15:11 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > >Dear Teco, > >On Feb 5, 2010, at 09:09 AM, Teco Boot wrote: > >> Hi Thomas, >> >>>>>> My point is that L3 communication becomes dependent on a L3 >>>>>> routing >>>>>> protocol. We didn't have this in the IP stack before. >>>>> >>>>> Well.....L3 communication depends on a populated routing table, >>>>> thus >>>>> on something populating the routing table. >>>>> L3 multi-hop communications depends on something clever (a routing >>>>> protocol, a DHCP server, a human, for example and depending on the >>>>> place) populating routing tables. >>>>> >>>>> I do not see what this document does that changes that? >>>> >>>> Up to now, all IP addressing models I am aware of provide 1-hop L3 >>>> communication between nodes that have L2 connectivity. >>>> >>>> The proposed addressing model for MANETs breaks this. Now there >>>> is a need for something clever. This clever thing could be >>>> stopped. >>> >>> What makes the route to the 'local network' appear in the routing >>> table? In that case the 'something clever' is whatever enters that >>> route. Often, that 'something clever' is the same thing as what >>> configures the interface.... >> >> The IP stack puts the configured prefixes on IP interfaces in the >> routing table. This provides L3 connectivity whenever there is a L2 >> link. >> The 'something clever' puts longer prefixes in the routing table. > >That's your idea of what constitutes "something clever".....I never >said that. > >> This could introduce multi-hop paths for 1-hop reachable nodes, for >> sure >> when link metrics are in place. And of course multi-hop paths to nodes >> that are in the MANET, but not 1-hop reachable. >> >> I strongly disagree with "that 'something clever' is the same thing as >> what configures the interface". > >I think it is quite clever when (quoting you): "The IP stack puts the >configured prefixes on IP interfaces in the routing table." > >> Our old charter was clear the Autoconf >> mechanism shall be independent of MANET protocols. > >I do not see anything in this document which imposes a MANET protocol. > >Thomas > >> >> >> Regards, Teco. >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf From thomas@thomasclausen.org Fri Feb 5 09:47:51 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8776F3A68E3 for ; Fri, 5 Feb 2010 09:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruTPigYGCtR3 for ; Fri, 5 Feb 2010 09:47:50 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 9EED23A6801 for ; Fri, 5 Feb 2010 09:47:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E3936430311; Fri, 5 Feb 2010 09:48:41 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-120-130.w92-140.abo.wanadoo.fr [92.140.63.130]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9C3644302F2; Fri, 5 Feb 2010 09:48:40 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: "Teco Boot" In-Reply-To: <007401caa681$61506090$23f121b0$@nl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Feb 2010 18:48:37 +0100 References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> <007401caa681$61506090$23f121b0$@nl> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 17:47:51 -0000 Dear Teco, On Feb 5, 2010, at 17:36 PM, Teco Boot wrote: > Thomas, > > Is this catching words? Not at all. It was explaining what I meant by "something clever" -- you, incorrectly, read something into that phrase that wasn't intended. > > Agreed that standard "not that clever" behavior of the IP stack is > putting prefixes, configured on interfaces, in the routing table? > > Agreed that putting other prefixes is 'something clever'? > > Agreed that with the proposed addressing model, under conditions that > the 'something clever' is not functioning, L3 communication fails for > links between two nodes that have L2 communication? No, I do not agree with the above. > If I am missing something, please come up with it. That's not how it works. There's a document that has attained what appears to be relatively wide consensus. You state that there's something wrong with the document and that you have an "alternative model". That's fair enough, but then the onus is on you to explain what is wrong, lay out your "alternative model", and make sure that in doing so it addresses also the concerns which draft-ietf-autoconf-adhoc-addr-model raise. Absent that (and we have had since the Stockholm IETF), I propose that we move forward draft-ietf-autoconf-adhoc-addr-model. Sincerely, Thomas > Regards, Teco > > >> -----Oorspronkelijk bericht----- >> Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >> Verzonden: vrijdag 5 februari 2010 15:11 >> Aan: Teco Boot >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document >> >> Dear Teco, >> >> On Feb 5, 2010, at 09:09 AM, Teco Boot wrote: >> >>> Hi Thomas, >>> >>>>>>> My point is that L3 communication becomes dependent on a L3 >>>>>>> routing >>>>>>> protocol. We didn't have this in the IP stack before. >>>>>> >>>>>> Well.....L3 communication depends on a populated routing table, >>>>>> thus >>>>>> on something populating the routing table. >>>>>> L3 multi-hop communications depends on something clever (a >>>>>> routing >>>>>> protocol, a DHCP server, a human, for example and depending on >>>>>> the >>>>>> place) populating routing tables. >>>>>> >>>>>> I do not see what this document does that changes that? >>>>> >>>>> Up to now, all IP addressing models I am aware of provide 1-hop L3 >>>>> communication between nodes that have L2 connectivity. >>>>> >>>>> The proposed addressing model for MANETs breaks this. Now there >>>>> is a need for something clever. This clever thing could be >>>>> stopped. >>>> >>>> What makes the route to the 'local network' appear in the routing >>>> table? In that case the 'something clever' is whatever enters that >>>> route. Often, that 'something clever' is the same thing as what >>>> configures the interface.... >>> >>> The IP stack puts the configured prefixes on IP interfaces in the >>> routing table. This provides L3 connectivity whenever there is a L2 >>> link. >>> The 'something clever' puts longer prefixes in the routing table. >> >> That's your idea of what constitutes "something clever".....I never >> said that. >> >>> This could introduce multi-hop paths for 1-hop reachable nodes, for >>> sure >>> when link metrics are in place. And of course multi-hop paths to >>> nodes >>> that are in the MANET, but not 1-hop reachable. >>> >>> I strongly disagree with "that 'something clever' is the same >>> thing as >>> what configures the interface". >> >> I think it is quite clever when (quoting you): "The IP stack puts the >> configured prefixes on IP interfaces in the routing table." >> >>> Our old charter was clear the Autoconf >>> mechanism shall be independent of MANET protocols. >> >> I do not see anything in this document which imposes a MANET >> protocol. >> >> Thomas >> >>> >>> >>> Regards, Teco. >>> >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From charles.perkins@earthlink.net Fri Feb 5 10:18:32 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974193A6C14 for ; Fri, 5 Feb 2010 10:18:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM1-Y1-Sok-Q for ; Fri, 5 Feb 2010 10:18:31 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id C54343A6F6A for ; Fri, 5 Feb 2010 10:18:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BNzBU9CWy5ucelVwnWUNwaJLzvDPuz4so+qS4ookgBqByqjuN2845q4+XyFyxuWM; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.146]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NdSm1-0002dZ-1u; Fri, 05 Feb 2010 13:19:21 -0500 Message-ID: <4B6C6120.7000808@earthlink.net> Date: Fri, 05 Feb 2010 10:19:12 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> In-Reply-To: <003501caa63a$7b15ca20$71415e60$@nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ed5bd4d89443134cc42f1e374370bb89350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 18:18:32 -0000 Hello Teco, On 2/5/2010 12:09 AM, Teco Boot wrote: > > The IP stack puts the configured prefixes on IP interfaces in the > routing table. This provides L3 connectivity whenever there is a L2 > link. You used "configured" in a magic way. Where did the configuration arise? > The 'something clever' puts longer prefixes in the routing table. > This could introduce multi-hop paths for 1-hop reachable nodes, for sure > when link metrics are in place. And of course multi-hop paths to nodes > that are in the MANET, but not 1-hop reachable. O.K. > > I strongly disagree with "that 'something clever' is the same thing as > what configures the interface". Our old charter was clear the Autoconf > mechanism shall be independent of MANET protocols. I do not remember anyone claiming that they were the same. What am I missing? Regards, Charlie P. From charles.perkins@earthlink.net Fri Feb 5 10:23:35 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087AD3A6C7D for ; Fri, 5 Feb 2010 10:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uFRQDitvYfn for ; Fri, 5 Feb 2010 10:23:34 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 2D8D63A6C14 for ; Fri, 5 Feb 2010 10:23:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=k1jTJNV4rr+p2T0jWGfMBsKWKKE/uYP9y7s3/gYHYquWm4UwlzD4pyp4frBBK+Le; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.146]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NdSqu-0001Af-8O; Fri, 05 Feb 2010 13:24:24 -0500 Message-ID: <4B6C6250.4040800@earthlink.net> Date: Fri, 05 Feb 2010 10:24:16 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <0CD59086-0DBF-40A6-8EC4-3289E65054A1@thomasclausen.org> <003601caa63a$83515560$89f40020$@nl> In-Reply-To: <003601caa63a$83515560$89f40020$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52b05093eda0908c9d1541d58e9bf78e2b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 18:23:35 -0000 Hello Teco, On 2/5/2010 12:09 AM, Teco Boot wrote: > I thought we should work on a practical addressing model. > In practice, it is useful to have IP access to nearby nodes, > also when the MANET protocol is non-operational. Well, as far as I can tell, we have been doing just that, and in practice a node can have access to neighbors when the protocol isn't operational. > I don't want "no MANET protocol". > I want L3 connectivity when there is a L2 link, and the MANET protocol > is non-operational. Your wish is granted... >> For the >> reasons outlined in that document, those addresses should (to allow >> any operation / any protocol to operate) satisfy the suggested rules >> in the document. If you do deviate from the "should", the usual >> caveats for a "should" apply -- and it might be OK for your deployment? > > Yes, we all are free to ignore the document. > But there were strong opinions that the defined addressing models shall > work in all scenarios? Surely, the defined models _do_ work in all scenarios. Perhaps in some scenarios additional assumptions can be made for more scalable address aggregation to be maintained. Or, were you thinking of something else? > The addressing model I use works great for all proactive MANET protocols > I am aware of. So does the model in the document under discussion. > For the reactive routing protocols, there are some implementation issues: > The RREQ should be triggered after "address not reachable", i.e. interaction > with ARP/ND. I'm wondering about RREQ for link-local addresses. That seems almost like a contradiction in terms. I'd prefer to have routes composed of links, not the other way around. Regards, Charlie P. From teco@inf-net.nl Fri Feb 5 10:28:32 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDAE3A6C7E for ; Fri, 5 Feb 2010 10:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLWLooBy9+4y for ; Fri, 5 Feb 2010 10:28:31 -0800 (PST) Received: from CPSMTPM-EML106.kpnxchange.com (Cpsmtpm-eml106.kpnxchange.com [195.121.3.10]) by core3.amsl.com (Postfix) with ESMTP id 6660E3A69F9 for ; Fri, 5 Feb 2010 10:28:30 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Fri, 5 Feb 2010 19:29:21 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <4B6C6120.7000808@earthlink.net> In-Reply-To: <4B6C6120.7000808@earthlink.net> Date: Fri, 5 Feb 2010 19:29:19 +0100 Message-ID: <008b01caa691$21c24910$6546db30$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqmj7+wCahzQpFySUO8rI3Gc+UPoQAAGBNA Content-Language: nl X-OriginalArrivalTime: 05 Feb 2010 18:29:21.0217 (UTC) FILETIME=[2276F310:01CAA691] Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 18:28:32 -0000 Hi Charlie, The difference between configured "wide prefix per MANET segment" versus "longest / non-overlapping prefix prefix per MANET interface" is that the first is relatively static. The latter needs active neighborhood discovery. I say the first one is "less clever" and it is standard IP stack behavior. Prefix can be learned with ND. Another mechanism is needed for IPv4. Regards, Teco >-----Oorspronkelijk bericht----- >Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] >Verzonden: vrijdag 5 februari 2010 19:19 >Aan: Teco Boot >CC: 'Thomas Heide Clausen'; autoconf@ietf.org >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > >Hello Teco, > > >On 2/5/2010 12:09 AM, Teco Boot wrote: > >> >> The IP stack puts the configured prefixes on IP interfaces in the >> routing table. This provides L3 connectivity whenever there is a L2 >> link. > >You used "configured" in a magic way. >Where did the configuration arise? > >> The 'something clever' puts longer prefixes in the routing table. >> This could introduce multi-hop paths for 1-hop reachable nodes, for >sure >> when link metrics are in place. And of course multi-hop paths to nodes >> that are in the MANET, but not 1-hop reachable. > >O.K. > >> >> I strongly disagree with "that 'something clever' is the same thing as >> what configures the interface". Our old charter was clear the Autoconf >> mechanism shall be independent of MANET protocols. > >I do not remember anyone claiming that they were the same. >What am I missing? > >Regards, >Charlie P. From charles.perkins@earthlink.net Fri Feb 5 10:34:48 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2552A3A6D83 for ; Fri, 5 Feb 2010 10:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6D8JTpRECY4T for ; Fri, 5 Feb 2010 10:34:47 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id D2C1A3A6C7E for ; Fri, 5 Feb 2010 10:34:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=h5EGMVtuGyeZdASwxk1dkGupksYQknX+Jhl0ZiUgdMziHg33DnQ0CiCn8+Ck6u0n; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.146]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NdT1l-0000GB-6U; Fri, 05 Feb 2010 13:35:37 -0500 Message-ID: <4B6C64F6.9040807@earthlink.net> Date: Fri, 05 Feb 2010 10:35:34 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <4B6B0E85.5050101@earthlink.net> <003e01caa63e$a8d190d0$fa74b270$@nl> In-Reply-To: <003e01caa63e$a8d190d0$fa74b270$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52ec7017f710d14f75517b1c14f56ce553350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2010 18:34:48 -0000 Hello Teco, On 2/5/2010 12:38 AM, Teco Boot wrote: > > ... existing IP addressing models don't depend on such clever > thing. Here, we have the "assumption". Right? First, I do not understand what the "assumption" is that you mean here. Second, existing IP addressing models that you might be referring to, depend on a model of a link == communication medium that does not pertain to all ad hoc networks. >> I also do not >> agree that we must avoid being clever. > > Agreed. That is why I use an addressing model that is better resistant > against failures. I didn't see which model you meant. >> >> I read this, and had to smile. Of course there's no reason >> to avoid link-locals for 1-hop traffic as long as you _know_ >> it's one hop. In fact, blast away. > > OK, now we are there. > MANET protocols that use RFC5498 can perfectly use link-locals. > Same for L2 address resolving, as ND does. You can be very mysterious at times. I admit defeat, unable to meet the challenge of understanding your meaning. As you well know, ND works for nodes in range. As specified now, it does not work for nodes that are not in range, in case you wanted to tackle the onerous project of creating a wireless link that exceeds the transmission range of any node in the link. >> But for people who are running networks without such >> comforts, assurance of availability for a L2 communication >> channel is often necessary or at least highly desirable. >> Then suddenly your link-local address is potentially >> (a) invalid (b) unavailable or (c) ambiguous. These >> are normally considered poor indicators for IP-based >> communications. > > What happens if your ULA or global is (a) invalid, > (b) unavailable or (c) ambiguous? > I don't see a difference with link-locals. > Link-locals are used for protocols that require 1-hop > communication or when no other addresses are available. > In the latter, it is also 1-hop only. Teco, whenever you ask this question, please first revisit my explanation which I have offered perhaps a dozen times in the past: - determining link-local uniqueness should not require multi-hop protocol action - with ad hoc networks, you may not know if a node with a link-local address on a particular link is actually adjacent/neighboring/in-range/... On the positive side, you have asked the same question so many times that I have the answer instantly at the ready. >> And that is the problem needing solution in the >> general case, which has motivated the current form >> of the addressing model document. > > With IPv6 in mind, the general case can easily include > link-locals. Wouldn't it be nice to support IPv6 basics? I have IPv6 in mind. The general case does not easily include link-locals over wireless media. The particular specializations _may_ include link-locals. Wouldn't it be nicer to avoid requiring particular specializations when the general case is just waiting for us to quit delaying and standardize an already-known solution? Regards, Charlie P. From cjbc@it.uc3m.es Tue Feb 9 09:16:18 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24C1F28C162 for ; Tue, 9 Feb 2010 09:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpcqGSLNJiSm for ; Tue, 9 Feb 2010 09:16:16 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 538C128C15E for ; Tue, 9 Feb 2010 09:16:16 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id CC2446C696C; Tue, 9 Feb 2010 18:17:21 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <007401caa681$61506090$23f121b0$@nl> References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> <007401caa681$61506090$23f121b0$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-SJ+i4Pd1S3O95jiTpskD" Organization: Universidad Carlos III de Madrid Date: Tue, 09 Feb 2010 18:17:28 +0100 Message-ID: <1265735848.4511.97.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: autoconf@ietf.org, 'Thomas Heide Clausen' Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:16:18 -0000 --=-SJ+i4Pd1S3O95jiTpskD Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Fri, 2010-02-05 at 17:36 +0100, Teco Boot wrote: > Thomas, >=20 > Is this catching words? >=20 > Agreed that standard "not that clever" behavior of the IP stack is > putting prefixes, configured on interfaces, in the routing table? >=20 > Agreed that putting other prefixes is 'something clever'? >=20 > Agreed that with the proposed addressing model, under conditions that > the 'something clever' is not functioning, L3 communication fails for > links between two nodes that have L2 communication? I agree with this. Carlos >=20 > If I am missing something, please come up with it. >=20 > Regards, Teco >=20 >=20 > >-----Oorspronkelijk bericht----- > >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] > >Verzonden: vrijdag 5 februari 2010 15:11 > >Aan: Teco Boot > >CC: autoconf@ietf.org > >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > > > >Dear Teco, > > > >On Feb 5, 2010, at 09:09 AM, Teco Boot wrote: > > > >> Hi Thomas, > >> > >>>>>> My point is that L3 communication becomes dependent on a L3 > >>>>>> routing > >>>>>> protocol. We didn't have this in the IP stack before. > >>>>> > >>>>> Well.....L3 communication depends on a populated routing table, > >>>>> thus > >>>>> on something populating the routing table. > >>>>> L3 multi-hop communications depends on something clever (a routing > >>>>> protocol, a DHCP server, a human, for example and depending on the > >>>>> place) populating routing tables. > >>>>> > >>>>> I do not see what this document does that changes that? > >>>> > >>>> Up to now, all IP addressing models I am aware of provide 1-hop L3 > >>>> communication between nodes that have L2 connectivity. > >>>> > >>>> The proposed addressing model for MANETs breaks this. Now there > >>>> is a need for something clever. This clever thing could be > >>>> stopped. > >>> > >>> What makes the route to the 'local network' appear in the routing > >>> table? In that case the 'something clever' is whatever enters that > >>> route. Often, that 'something clever' is the same thing as what > >>> configures the interface.... > >> > >> The IP stack puts the configured prefixes on IP interfaces in the > >> routing table. This provides L3 connectivity whenever there is a L2 > >> link. > >> The 'something clever' puts longer prefixes in the routing table. > > > >That's your idea of what constitutes "something clever".....I never > >said that. > > > >> This could introduce multi-hop paths for 1-hop reachable nodes, for > >> sure > >> when link metrics are in place. And of course multi-hop paths to nodes > >> that are in the MANET, but not 1-hop reachable. > >> > >> I strongly disagree with "that 'something clever' is the same thing as > >> what configures the interface". > > > >I think it is quite clever when (quoting you): "The IP stack puts the > >configured prefixes on IP interfaces in the routing table." > > > >> Our old charter was clear the Autoconf > >> mechanism shall be independent of MANET protocols. > > > >I do not see anything in this document which imposes a MANET protocol. > > > >Thomas > > > >> > >> > >> Regards, Teco. > >> > >> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-SJ+i4Pd1S3O95jiTpskD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAktxmKcACgkQNdy6TdFwT2dvCACfXImNOzDvcr00rZgdk9qLj7OR LSMAn3+NF5XiLJ2VAmCi24G5wb19sV12 =glwB -----END PGP SIGNATURE----- --=-SJ+i4Pd1S3O95jiTpskD-- From charles.perkins@earthlink.net Tue Feb 9 09:50:14 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DB4528C250 for ; Tue, 9 Feb 2010 09:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JJmpcFrmG1z for ; Tue, 9 Feb 2010 09:50:13 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 4182028C16F for ; Tue, 9 Feb 2010 09:50:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Drq5AzbbQZxa5aZCcULm7dCHzWvmoHyPHhIPLbhRGLygpe1QsVkWFQhO0pebUMsQ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.144]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NeuF5-0000rW-El; Tue, 09 Feb 2010 12:51:19 -0500 Message-ID: <4B71A08F.9060904@earthlink.net> Date: Tue, 09 Feb 2010 09:51:11 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> <007401caa681$61506090$23f121b0$@nl> <1265735848.4511.97.camel@acorde.it.uc3m.es> In-Reply-To: <1265735848.4511.97.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52032205e802dcb077f639ddf4c1c2b0de350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:50:14 -0000 Hello Carlos, Questions/comments inline: On 2/9/2010 9:17 AM, Carlos Jesús Bernardos Cano wrote: >> Agreed that standard "not that clever" behavior of the IP stack is >> putting prefixes, configured on interfaces, in the routing table? What "not that clever" agent is putting them there? >> Agreed that putting other prefixes is 'something clever'? "other prefixes" == ??? >> Agreed that with the proposed addressing model, under conditions that >> the 'something clever' is not functioning, L3 communication fails for >> links between two nodes that have L2 communication? > > I agree with this. But the document says: => If L2 communication is enabled between a pair of interfaces, IP => packet exchange is enabled regardless of the IP subnet configuration => on each of these interfaces. Thus, Teco's assertion is wrong. It seems to me that each of the three parts quoted above are either highly questionable, mysterious, or wrong. What's to agree with? Regards, Charlie P. From cjbc@it.uc3m.es Tue Feb 9 09:56:13 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0750228C169 for ; Tue, 9 Feb 2010 09:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.35 X-Spam-Level: X-Spam-Status: No, score=-5.35 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UU-yd2fXGxG2 for ; Tue, 9 Feb 2010 09:56:12 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id CDE433A7230 for ; Tue, 9 Feb 2010 09:56:11 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id A2E55BAB1AC; Tue, 9 Feb 2010 18:57:16 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4B71A08F.9060904@earthlink.net> References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> <007401caa681$61506090$23f121b0$@nl> <1265735848.4511.97.camel@acorde.it.uc3m.es> <4B71A08F.9060904@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-EW3SbbQvzp+99PQUIPcf" Organization: Universidad Carlos III de Madrid Date: Tue, 09 Feb 2010 18:57:23 +0100 Message-ID: <1265738243.4511.105.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 17:56:13 -0000 --=-EW3SbbQvzp+99PQUIPcf Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hello Charlie, On Tue, 2010-02-09 at 09:51 -0800, Charles E. Perkins wrote: > Hello Carlos, >=20 > Questions/comments inline: >=20 >=20 > On 2/9/2010 9:17 AM, Carlos Jes=FAs Bernardos Cano wrote: >=20 > >> Agreed that standard "not that clever" behavior of the IP stack is > >> putting prefixes, configured on interfaces, in the routing table? >=20 > What "not that clever" agent is putting them there? >=20 > >> Agreed that putting other prefixes is 'something clever'? If an prefix::iid/lprefix on-link address is configured in one interface, then a route to that prefix prefix:://lprefix is configured and I can communicate with other addresses of the same prefix on the same L2 link. If the address is off-link, something else is needed to communicate. A good example of the above are link-locals. With current document, we always need something else to communicate. This is not something I'm necessarily against, I just said that I agree that something else is needed with current addressing model. Carlos >=20 > "other prefixes" =3D=3D ??? >=20 > >> Agreed that with the proposed addressing model, under conditions that > >> the 'something clever' is not functioning, L3 communication fails for > >> links between two nodes that have L2 communication? > > > > I agree with this. >=20 > But the document says: >=20 > =3D> If L2 communication is enabled between a pair of interfaces, IP > =3D> packet exchange is enabled regardless of the IP subnet configurat= ion > =3D> on each of these interfaces. >=20 > Thus, Teco's assertion is wrong. >=20 > It seems to me that each of the three parts quoted above > are either highly questionable, mysterious, or wrong. >=20 > What's to agree with? >=20 > Regards, > Charlie P. --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-EW3SbbQvzp+99PQUIPcf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAktxogIACgkQNdy6TdFwT2fZLACgxu9avoqoDd401kUoC1AK/nal eeIAn2FY1O0PkcKi1gvZB1k8lMgnbVK3 =fwpu -----END PGP SIGNATURE----- --=-EW3SbbQvzp+99PQUIPcf-- From teco@inf-net.nl Tue Feb 16 07:40:33 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAF93A7D2C for ; Tue, 16 Feb 2010 07:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp+X3z1ILcS9 for ; Tue, 16 Feb 2010 07:40:32 -0800 (PST) Received: from CPSMTPM-EML107.kpnxchange.com (Cpsmtpm-eml107.kpnxchange.com [195.121.3.11]) by core3.amsl.com (Postfix) with ESMTP id 69C153A7D2A for ; Tue, 16 Feb 2010 07:40:31 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML107.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 16 Feb 2010 16:42:04 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> <007401caa681$61506090$23f121b0$@nl> In-Reply-To: Date: Tue, 16 Feb 2010 16:41:57 +0100 Message-ID: <008f01caaf1e$925b5820$b7120860$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acqmi3gn7kXxb99LROevGGaAYdCmZAIjzfEg Content-Language: nl X-OriginalArrivalTime: 16 Feb 2010 15:42:04.0878 (UTC) FILETIME=[96E266E0:01CAAF1E] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 15:40:33 -0000 Thomas, Late response. I have little time to work on Autoconf. I have to deploy something. Sorry for that. >-----Oorspronkelijk bericht----- >Van: Thomas Heide Clausen [mailto:thomas@thomasclausen.org] >Verzonden: vrijdag 5 februari 2010 18:49 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document > >Dear Teco, > >On Feb 5, 2010, at 17:36 PM, Teco Boot wrote: > >> Thomas, >> >> Is this catching words? > >Not at all. It was explaining what I meant by "something clever" -- >you, incorrectly, read something into that phrase that wasn't intended. > >> >> Agreed that standard "not that clever" behavior of the IP stack is >> putting prefixes, configured on interfaces, in the routing table? >> >> Agreed that putting other prefixes is 'something clever'? >> >> Agreed that with the proposed addressing model, under conditions that >> the 'something clever' is not functioning, L3 communication fails for >> links between two nodes that have L2 communication? > >No, I do not agree with the above. I think you miss something important here. >> If I am missing something, please come up with it. > >That's not how it works. I'm posting this issue AFTER testing. And I'm quite familiar with currently shipped MANET products. I can't see how these can support the suggested addressing model. I also asked Mark on this. No response yet !! Far more important. It doesn't work when I post during WGLC, and it is ignored totally. I checked mail archives, there wasn't a single response form doc editors for clarification, nor corrections in the draft. >There's a document that has attained what appears to be relatively >wide consensus. OK, this is up to you as chair. But wide consensus? > You state that there's something wrong with the >document and that you have an "alternative model". That's fair enough, >but then the onus is on you to explain what is wrong, lay out your >"alternative model", and make sure that in doing so it addresses also >the concerns which draft-ietf-autoconf-adhoc-addr-model raise. I explained what is wrong. And at least one (Carlos) understands the issue in the document. Again, my response during WGLC on this topic: Page 4: If L2 communication is enabled between a pair of interfaces, IP packet exchange is enabled regardless of the IP subnet configuration on each of these interfaces. This is only possible if the IP stack is aware of the L2 link between the pair of interfaces. One way of establishing this is configure an on-link subnet prefix. Now we choose not to configure so, and instead run a MANET protocol. But this makes IP communication dependent on the MANET protocol, which can have a negative effect on managing the network. Think of remote management and updates on the MANET protocol. >Absent that (and we have had since the Stockholm IETF), I propose that >we move forward draft-ietf-autoconf-adhoc-addr-model. I might write something. No time today. Thanks, Teco From teco@inf-net.nl Tue Feb 16 08:32:29 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA3028C184 for ; Tue, 16 Feb 2010 08:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYC2qWDEwx2Z for ; Tue, 16 Feb 2010 08:32:26 -0800 (PST) Received: from CPSMTPM-EML105.kpnxchange.com (cpsmtpm-eml105.kpnxchange.com [195.121.3.9]) by core3.amsl.com (Postfix) with ESMTP id DBD9828C0DF for ; Tue, 16 Feb 2010 08:32:24 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML105.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Tue, 16 Feb 2010 17:33:57 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <4B6B0E85.5050101@earthlink.net> <003e01caa63e$a8d190d0$fa74b270$@nl> <4B6C64F6.9040807@earthlink.net> In-Reply-To: <4B6C64F6.9040807@earthlink.net> Date: Tue, 16 Feb 2010 17:33:50 +0100 Message-ID: <009601caaf25$d2005b90$760112b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcqmkgVtzOdT8JZkSziNLVzcnMAFsQIjMNhA Content-Language: nl X-OriginalArrivalTime: 16 Feb 2010 16:33:57.0976 (UTC) FILETIME=[D66F7580:01CAAF25] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 16:32:29 -0000 Hi Charlie, Also sorry for late response. >> ... existing IP addressing models don't depend on such clever >> thing. Here, we have the "assumption". Right? > >First, I do not understand what the "assumption" >is that you mean here. > >Second, existing IP addressing models that you >might be referring to, depend on a model of a >link == communication medium that does not pertain >to all ad hoc networks. No, existing IP addressing models work with non-transitive links also. When there is a link, there is IP communication. For example OSPFv2 has the Point-to-MultiPoint mode to support these networks. You can read RFC2328 for a description. There are a huge number of networks that works this way. >>> I also do not >>> agree that we must avoid being clever. >> >> Agreed. That is why I use an addressing model that is better resistant >> against failures. > >I didn't see which model you meant. How do IEEE 802.11 IBSS users configure their network today? >>> I read this, and had to smile. Of course there's no reason >>> to avoid link-locals for 1-hop traffic as long as you _know_ >>> it's one hop. In fact, blast away. >> >> OK, now we are there. >> MANET protocols that use RFC5498 can perfectly use link-locals. >> Same for L2 address resolving, as ND does. > >You can be very mysterious at times. I admit defeat, >unable to meet the challenge of understanding your meaning. Sorry. Maybe I should include a complete packet trace. In short: OLSR packets source address is typically LL when using IPv6 LL-MANET-Routers, because LL-MANET-Routers has scope Link-Local. See RFC5498 for the details. And the IPv6 stack uses the link-locals for MLD and ND. Try to get rid of it yourself. You guess need to rewrite a lot in the IPv6 stack. >As you well know, ND works for nodes in range. >As specified now, it does not work for nodes that >are not in range, in case you wanted to tackle the >onerous project of creating a wireless link that >exceeds the transmission range of any node in the >link. IP depends on sub-IP links. So yes, you are right. But what is your message? Can ARP resolve L2 addresses multi-hop? Do you need something like that? No, of course not. IMHO the MANET routing protocol extends the communication capability from single-hop to multi-hop. We know how to this. But: The MANET addressing model shall not limit single hop communication in cases where the MANET routing protocol is inactive. This is my requirement. Also important, as far as I know, the majority of current operational MANETs have a common prefix for the MANET segment. And the MANET routing protocol advertises the /32 "host prefix" in the MANET, if this address is required to be reachable. This works great. That is the reason it is deployed so much. >>> But for people who are running networks without such >>> comforts, assurance of availability for a L2 communication >>> channel is often necessary or at least highly desirable. >>> Then suddenly your link-local address is potentially >>> (a) invalid (b) unavailable or (c) ambiguous. These >>> are normally considered poor indicators for IP-based >>> communications. >> >> What happens if your ULA or global is (a) invalid, >> (b) unavailable or (c) ambiguous? >> I don't see a difference with link-locals. >> Link-locals are used for protocols that require 1-hop >> communication or when no other addresses are available. >> In the latter, it is also 1-hop only. > >Teco, whenever you ask this question, please first >revisit my explanation which I have offered perhaps >a dozen times in the past: >- determining link-local uniqueness should not require > multi-hop protocol action IMHO this answer is incorrect. Or do you use non-link-local addresses that determine global uniqueness with single-hop communication? Or addresses with an angel, defending uniqueness? >- with ad hoc networks, you may not know if a node > with a link-local address on a particular link > is actually adjacent/neighboring/in-range/... This is a valid answer. But handling this issue requires an update on address selection. So we have to write a draft that updates RFC3484 one day. Many products in use have a policy that selects global or ULA over link-local addresses for packets that may require multi-hop communication. LL addresses should not be preferred for that. >On the positive side, you have asked the same >question so many times that I have the answer >instantly at the ready. And there is a good reason for repeating this question. I'll stop when there is a nice mechanism for IPv6 multi-homed MANETs without NAT. I can't see how we can do this without prefix swapping, where the prefix comes from the border router. And for smooth address swapping, I suggest not repeating address uniqueness testing. So I suggest to use unique InterfaceIDs. By nature, by good randomization and / or by duplicate check. >>> And that is the problem needing solution in the >>> general case, which has motivated the current form >>> of the addressing model document. >> >> With IPv6 in mind, the general case can easily include >> link-locals. Wouldn't it be nice to support IPv6 basics? > >I have IPv6 in mind. The general case does not >easily include link-locals over wireless media. It is up and running in many scenario's already. I can't remember a single issue. Yes, duplicate testing. That is an issue for non-link-locals also! >The particular specializations _may_ include >link-locals. > >Wouldn't it be nicer to avoid requiring >particular specializations when the general >case is just waiting for us to quit delaying >and standardize an already-known solution? Yes. But we don't agree on what is used today. Regards, Teco From ryuji.wakikawa@gmail.com Tue Feb 16 11:58:18 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A5FB28C172 for ; Tue, 16 Feb 2010 11:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jlaikaob1G60 for ; Tue, 16 Feb 2010 11:58:17 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 4136C28C16B for ; Tue, 16 Feb 2010 11:58:17 -0800 (PST) Received: by qyk13 with SMTP id 13so3540993qyk.31 for ; Tue, 16 Feb 2010 11:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:mime-version :subject:from:date:cc:content-transfer-encoding:message-id:to :x-mailer; bh=gtOstQSFvHZJ8de2LUHqpS/jxkknXeoXMovtdoD+Ouc=; b=smjwyPY+oz879xdjLRBE5alMPran7v09wrA+Da40vasvNzz6n95D+DdsmVNfGN6LEU ThKPWOsACTO/UIjSl75liX0RGBbb6ZuODgD/tRAEDz9zQsa1NSm6Q7JTsN9OQ1MJk7+O 0gZlkM3b/4kjAF3KhOG8yr5on/PFbiIHRufa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:to:x-mailer; b=XeN5Sab2yNil26HYZbbd/TTCTekku4HeF9FAt0bolRgrPklsKcMN3mVP22jsE9Uwc/ SQvHxBIn09H2DdLmEZY2dQhmc+1uM86kswb5aTcSSjXmSm6R8Fsrgrpsstdysb2B+TwF d8OqiZRxkIt6WC2l7qaoWdsI5wqEzhKeu57+I= Received: by 10.224.107.8 with SMTP id z8mr1092366qao.275.1266350389550; Tue, 16 Feb 2010 11:59:49 -0800 (PST) Received: from ?192.168.18.110? (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id 7sm22139023qwb.37.2010.02.16.11.59.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 11:59:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: Ryuji Wakikawa Date: Tue, 16 Feb 2010 11:59:44 -0800 Content-Transfer-Encoding: 7bit Message-Id: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> To: autoconf@ietf.org X-Mailer: Apple Mail (2.1077) Subject: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:58:18 -0000 Dear All, We have concluded the WGLC of draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a -02 document issued, following up on this. Thanks to all for all the reviews and comments to this document! After Thomas and I (Chairs) carefully reviewed discussions on the mailing list, we do find that there is rough consensus for the current document. There was an individual objection to the description of the use of link-local address, but we did not detect wide support within the working group. This objection will, of course, be reflected in the PROTO write-up that will be sent to the IESG and the ADs, and reflected in the tracker. As a conclusion, we have established rough consensus to the new document. The WG chairs will start preparing the PROTO writeup for forwarding the document. Thanks, WG chairs From jari.arkko@piuha.net Tue Feb 16 11:59:42 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BF6528C15E for ; Tue, 16 Feb 2010 11:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHLIzUudI3QW for ; Tue, 16 Feb 2010 11:59:41 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 9912128C137 for ; Tue, 16 Feb 2010 11:59:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8B6BB2D294; Tue, 16 Feb 2010 22:01:16 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQrBlD4XuF80; Tue, 16 Feb 2010 22:01:15 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id BDDF52D293; Tue, 16 Feb 2010 22:01:15 +0200 (EET) Message-ID: <4B7AF98B.7050806@piuha.net> Date: Tue, 16 Feb 2010 22:01:15 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ryuji Wakikawa References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> In-Reply-To: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 19:59:42 -0000 Great. Lets move this doc forward! Jari Ryuji Wakikawa kirjoitti: > Dear All, > > We have concluded the WGLC of > draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a -02 > document issued, following up on this. > > Thanks to all for all the reviews and comments to this document! > > After Thomas and I (Chairs) carefully reviewed discussions on the > mailing list, we do find that there is rough consensus for the current > document. > > There was an individual objection to the description of the use of > link-local address, but we did not detect wide support within the > working group. This objection will, of course, be reflected in the PROTO > write-up that will be sent to the IESG and the ADs, and reflected in the > tracker. > > As a conclusion, we have established rough consensus to the new document. > > The WG chairs will start preparing the PROTO writeup for forwarding the > document. > > Thanks, > > WG chairs > > > From ryuji.wakikawa@gmail.com Tue Feb 16 12:01:46 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D06628C15E for ; Tue, 16 Feb 2010 12:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUsCw5qelaiJ for ; Tue, 16 Feb 2010 12:01:45 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 0AE0C28C137 for ; Tue, 16 Feb 2010 12:01:44 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so455203qwb.31 for ; Tue, 16 Feb 2010 12:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=/U1W0DLvFp8gIdknV8PpPblQZCiXmHRn/czsctSIRyU=; b=AyVuFDC4VkiSpMoktZq6jepxIxzSW3zMQR4jQVqeh/3nz5wQS2Amg0mttgE0AyPPsU xlFcLxLgVN5gfeqH0nL4QtdL7WesrFsswQUJ9cpsXeVlXf8w10KU1aoXMMgRNgYAQ+Yn iuQd9BudXUpDWjd0d/z7uNIHb9OYdebzUW2ks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=B9EojcsiXLkBb4k+29qDZLMbEtYgDthKUsf9PF3PsWtHRpmUUhUHhwlFCfiYB2TNca Tv9VcwbT9AHZk7o0Lx0JBCJMvgsmHYUR/wjwN7sWmekD0u0hQj6RpNmWBFcQvNYGYjp2 kSPScXH/J6zIiYEvF8QUtZT9b2wsIR9v7D8I8= Received: by 10.224.123.196 with SMTP id q4mr1125280qar.117.1266350595828; Tue, 16 Feb 2010 12:03:15 -0800 (PST) Received: from ?192.168.18.110? (adsl-99-49-9-50.dsl.pltn13.sbcglobal.net [99.49.9.50]) by mx.google.com with ESMTPS id 6sm22894228qwk.0.2010.02.16.12.03.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 12:03:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Ryuji Wakikawa In-Reply-To: <4B7AF98B.7050806@piuha.net> Date: Tue, 16 Feb 2010 12:03:10 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> To: Jari Arkko X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:01:46 -0000 We will send you the PROTO document shortly. thanks for waiting! ryuji On 2010/02/16, at 12:01, Jari Arkko wrote: > Great. Lets move this doc forward! > > Jari > > Ryuji Wakikawa kirjoitti: >> Dear All, >> >> We have concluded the WGLC of >> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a -02 >> document issued, following up on this. >> >> Thanks to all for all the reviews and comments to this document! >> >> After Thomas and I (Chairs) carefully reviewed discussions on the >> mailing list, we do find that there is rough consensus for the current >> document. >> >> There was an individual objection to the description of the use of >> link-local address, but we did not detect wide support within the >> working group. This objection will, of course, be reflected in the PROTO >> write-up that will be sent to the IESG and the ADs, and reflected in the >> tracker. >> >> As a conclusion, we have established rough consensus to the new document. >> >> The WG chairs will start preparing the PROTO writeup for forwarding the >> document. >> >> Thanks, >> >> WG chairs >> >> >> > From alexandru.petrescu@gmail.com Tue Feb 16 12:17:09 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2020928C182 for ; Tue, 16 Feb 2010 12:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.496 X-Spam-Level: X-Spam-Status: No, score=-1.496 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY-gMKks7h54 for ; Tue, 16 Feb 2010 12:17:08 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 23DCA28C181 for ; Tue, 16 Feb 2010 12:17:06 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id CB0FCD4811D for ; Tue, 16 Feb 2010 21:18:39 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9B34ED48134 for ; Tue, 16 Feb 2010 21:18:36 +0100 (CET) Message-ID: <4B7AFD9A.1090901@gmail.com> Date: Tue, 16 Feb 2010 21:18:34 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> In-Reply-To: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:17:09 -0000 Le 16/02/2010 20:59, Ryuji Wakikawa a écrit : > Dear All, > > We have concluded the WGLC of > draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a > -02 document issued, following up on this. > > Thanks to all for all the reviews and comments to this document! > > After Thomas and I (Chairs) carefully reviewed discussions on the > mailing list, we do find that there is rough consensus for the > current document. > > There was an individual objection to the description of the use of > link-local address, but we did not detect wide support within the > working group. Please make that count 2 not 1. I already sent a few days ago a public mail response to ThomasC. I said "well I believe it should [treat multicast]". Me too I object to the lack of treatment of multicast in this draft. Multicast is the very first thing happening when booting up. It's the only thing that can help autoconf. This draft ignoring multicast shows signs autoconf can't happen. Multicast is what helps DHCP happen, which is a kind of what autoconf tries to achieve. Multicast helps many other protocols trying to do things as autoconf tries. Multicast is what an RFC MANET document reserves in its IANA section. > This objection will, of course, be reflected in the PROTO write-up > that will be sent to the IESG and the ADs, and reflected in the > tracker. Please add the multicast objection too thank you. Alex > > As a conclusion, we have established rough consensus to the new > document. > > The WG chairs will start preparing the PROTO writeup for forwarding > the document. > > Thanks, > > WG chairs > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Tue Feb 16 12:19:05 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCBF3A73A5 for ; Tue, 16 Feb 2010 12:19:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=0.723, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6bLfXB38Xdn for ; Tue, 16 Feb 2010 12:19:04 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id F08133A735F for ; Tue, 16 Feb 2010 12:19:02 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id AAE90D48201 for ; Tue, 16 Feb 2010 21:20:35 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id B3D4CD4812D for ; Tue, 16 Feb 2010 21:20:32 +0100 (CET) Message-ID: <4B7AFE0E.8010100@gmail.com> Date: Tue, 16 Feb 2010 21:20:30 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> In-Reply-To: <4B7AF98B.7050806@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:19:05 -0000 Le 16/02/2010 21:01, Jari Arkko a écrit : > Great. Lets move this doc forward! YEs, let's move this forward and add multicast discussion to it without which autoconf can't fly. Multicast is what typical autoconfiguration protocols use today without which they'd never work. Multicast is what IPv6 got builtin precisely for the reason of autoconfing. This draft being silent about multicast spells it's not autoconf, IMHO. Alex > > Jari > > Ryuji Wakikawa kirjoitti: >> Dear All, >> >> We have concluded the WGLC of >> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a -02 >> document issued, following up on this. >> >> Thanks to all for all the reviews and comments to this document! >> >> After Thomas and I (Chairs) carefully reviewed discussions on the >> mailing list, we do find that there is rough consensus for the current >> document. >> >> There was an individual objection to the description of the use of >> link-local address, but we did not detect wide support within the >> working group. This objection will, of course, be reflected in the PROTO >> write-up that will be sent to the IESG and the ADs, and reflected in the >> tracker. >> >> As a conclusion, we have established rough consensus to the new document. >> >> The WG chairs will start preparing the PROTO writeup for forwarding the >> document. >> >> Thanks, >> >> WG chairs >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Tue Feb 16 12:19:47 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF9F3A6BF8 for ; Tue, 16 Feb 2010 12:19:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[AWL=0.695, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKc-Qa8ksDNI for ; Tue, 16 Feb 2010 12:19:46 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 5F5E33A73A5 for ; Tue, 16 Feb 2010 12:19:44 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 150E9D480DD for ; Tue, 16 Feb 2010 21:21:17 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 19EE7D48174 for ; Tue, 16 Feb 2010 21:21:15 +0100 (CET) Message-ID: <4B7AFE39.7030702@gmail.com> Date: Tue, 16 Feb 2010 21:21:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:19:47 -0000 Le 16/02/2010 21:03, Ryuji Wakikawa a écrit : > We will send you the PROTO document shortly. YEs, please the PROTO document shortly and add multicast discussion to it too, thank you. No more waiting, Alex > > thanks for waiting! > ryuji > > On 2010/02/16, at 12:01, Jari Arkko wrote: > >> Great. Lets move this doc forward! >> >> Jari >> >> Ryuji Wakikawa kirjoitti: >>> Dear All, >>> >>> We have concluded the WGLC of >>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a -02 >>> document issued, following up on this. >>> >>> Thanks to all for all the reviews and comments to this document! >>> >>> After Thomas and I (Chairs) carefully reviewed discussions on the >>> mailing list, we do find that there is rough consensus for the current >>> document. >>> >>> There was an individual objection to the description of the use of >>> link-local address, but we did not detect wide support within the >>> working group. This objection will, of course, be reflected in the PROTO >>> write-up that will be sent to the IESG and the ADs, and reflected in the >>> tracker. >>> >>> As a conclusion, we have established rough consensus to the new document. >>> >>> The WG chairs will start preparing the PROTO writeup for forwarding the >>> document. >>> >>> Thanks, >>> >>> WG chairs >>> >>> >>> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From thomas@thomasclausen.org Tue Feb 16 12:21:54 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B8D3A7BD0 for ; Tue, 16 Feb 2010 12:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEclH+o+rHSr for ; Tue, 16 Feb 2010 12:21:53 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 437843A7B0B for ; Tue, 16 Feb 2010 12:21:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 25C79430064; Tue, 16 Feb 2010 12:23:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 54439430038; Tue, 16 Feb 2010 12:23:28 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B7AFE0E.8010100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Feb 2010 21:23:26 +0100 References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:21:54 -0000 Dear Alex, Autoconf is about configuring addresses on interfaces, not on =20 allocating addresses in a registry, not sending IP packets to =20 multicast destinations. Sincerely, Thomas On Feb 16, 2010, at 21:20 PM, Alexandru Petrescu wrote: > Le 16/02/2010 21:01, Jari Arkko a =E9crit : >> Great. Lets move this doc forward! > > YEs, let's move this forward and add multicast discussion to it =20 > without which autoconf can't fly. Multicast is what typical =20 > autoconfiguration protocols use today without which they'd never work. > > Multicast is what IPv6 got builtin precisely for the reason of =20 > autoconfing. > > This draft being silent about multicast spells it's not autoconf, =20 > IMHO. > > Alex > >> >> Jari >> >> Ryuji Wakikawa kirjoitti: >>> Dear All, >>> >>> We have concluded the WGLC of >>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have =20= >>> a -02 >>> document issued, following up on this. >>> >>> Thanks to all for all the reviews and comments to this document! >>> >>> After Thomas and I (Chairs) carefully reviewed discussions on the >>> mailing list, we do find that there is rough consensus for the =20 >>> current >>> document. >>> >>> There was an individual objection to the description of the use of >>> link-local address, but we did not detect wide support within the >>> working group. This objection will, of course, be reflected in the =20= >>> PROTO >>> write-up that will be sent to the IESG and the ADs, and reflected =20= >>> in the >>> tracker. >>> >>> As a conclusion, we have established rough consensus to the new =20 >>> document. >>> >>> The WG chairs will start preparing the PROTO writeup for =20 >>> forwarding the >>> document. >>> >>> Thanks, >>> >>> WG chairs >>> >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Feb 16 12:27:35 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B403F3A7BD0 for ; Tue, 16 Feb 2010 12:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJCSLUVkFcI8 for ; Tue, 16 Feb 2010 12:27:34 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 86B673A7BED for ; Tue, 16 Feb 2010 12:27:32 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id A4667D48131; Tue, 16 Feb 2010 21:29:05 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9816CD480D5; Tue, 16 Feb 2010 21:29:02 +0100 (CET) Message-ID: <4B7B000C.1070602@gmail.com> Date: Tue, 16 Feb 2010 21:29:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:27:35 -0000 Le 16/02/2010 21:23, Thomas Heide Clausen a écrit : > Dear Alex, > > Autoconf is about configuring addresses on interfaces, not on > allocating addresses in a registry, not sending IP packets to > multicast destinations. Thomas, thank you for the reply. Link-layer multicast mechanisms are used in any autoconfing (DHCPv6, SLAAC, probably more) mechanism. A stack booting up sends packets to multicast destinations. MANET already allocates a multicast address for this. Suffices it to mention it. Otherwise leave place for non-understanding: will the IPv6 autoconf stack use the MANET multicast address? Or the other non-MANET multicast address? I mostly agree with you. And there are two different people here (Teco, myself) saying approximately the same thing about multicast. The autoconf group is not large. Are two opinions worth ignoring? Alex > > Sincerely, > > Thomas > > > On Feb 16, 2010, at 21:20 PM, Alexandru Petrescu wrote: > >> Le 16/02/2010 21:01, Jari Arkko a écrit : >>> Great. Lets move this doc forward! >> >> YEs, let's move this forward and add multicast discussion to it >> without which autoconf can't fly. Multicast is what typical >> autoconfiguration protocols use today without which they'd never >> work. >> >> Multicast is what IPv6 got builtin precisely for the reason of >> autoconfing. >> >> This draft being silent about multicast spells it's not autoconf, >> IMHO. >> >> Alex >> >>> >>> Jari >>> >>> Ryuji Wakikawa kirjoitti: >>>> Dear All, >>>> >>>> We have concluded the WGLC of >>>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and >>>> have a -02 document issued, following up on this. >>>> >>>> Thanks to all for all the reviews and comments to this >>>> document! >>>> >>>> After Thomas and I (Chairs) carefully reviewed discussions on >>>> the mailing list, we do find that there is rough consensus for >>>> the current document. >>>> >>>> There was an individual objection to the description of the >>>> use of link-local address, but we did not detect wide support >>>> within the working group. This objection will, of course, be >>>> reflected in the PROTO write-up that will be sent to the IESG >>>> and the ADs, and reflected in the tracker. >>>> >>>> As a conclusion, we have established rough consensus to the >>>> new document. >>>> >>>> The WG chairs will start preparing the PROTO writeup for >>>> forwarding the document. >>>> >>>> Thanks, >>>> >>>> WG chairs >>>> >>>> >>> >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From thomas@thomasclausen.org Tue Feb 16 12:34:02 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2875028C17F for ; Tue, 16 Feb 2010 12:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkwWne1XO1-s for ; Tue, 16 Feb 2010 12:34:01 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2F2313A7DB7 for ; Tue, 16 Feb 2010 12:34:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 42991430034; Tue, 16 Feb 2010 12:35:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 6A856430061; Tue, 16 Feb 2010 12:35:36 -0800 (PST) Message-Id: <6A7C46D7-A872-4D00-AE85-C0E72FD48EC3@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B7B000C.1070602@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Feb 2010 21:35:34 +0100 References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> <4B7B000C.1070602@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:34:02 -0000 Dear Alex, On Feb 16, 2010, at 21:29 PM, Alexandru Petrescu wrote: > Le 16/02/2010 21:23, Thomas Heide Clausen a =E9crit : >> Dear Alex, >> >> Autoconf is about configuring addresses on interfaces, not on >> allocating addresses in a registry, not sending IP packets to >> multicast destinations. > > Thomas, thank you for the reply. > > Link-layer multicast mechanisms are used in any autoconfing (DHCPv6, > SLAAC, probably more) mechanism. > > A stack booting up sends packets to multicast destinations. > > MANET already allocates a multicast address for this. > > Suffices it to mention it. > These reflections belong properly in the problem-statement/scoping and =20= solution-space discussions -- hopefully, we will be able to get to =20 those (the fun part: building protocols) soon. So hold that thought =20 until later. > Otherwise leave place for non-understanding: will the IPv6 autoconf > stack use the MANET multicast address? Or the other non-MANET =20 > multicast > address? If I configure my addresses manually, as is one viable option, I can =20 follow the recommendations in draft-ietf-autoconf-adhoc-addr-=20 model-02.txt and have a valid configuration. In that case, the =20 "configuration mechanism" needs no multicast. I note that this may =20 apply more to IPv4 than IPv6, and that the document covers both. If a MANET autoconfiguration protocol needs to exchange information =20 for proper functioning - which it may well do - then that protocol =20 will have to decide on which addresses, messages and algorithms to use =20= for that. So again, these reflections belong properly in the problem-=20 statement/scoping and solution-space discussions. Sincerely, Thomas > I mostly agree with you. > > And there are two different people here (Teco, myself) saying > approximately the same thing about multicast. The autoconf group is =20= > not > large. Are two opinions worth ignoring? > > Alex > >> >> Sincerely, >> >> Thomas >> >> >> On Feb 16, 2010, at 21:20 PM, Alexandru Petrescu wrote: >> >>> Le 16/02/2010 21:01, Jari Arkko a =E9crit : >>>> Great. Lets move this doc forward! >>> >>> YEs, let's move this forward and add multicast discussion to it >>> without which autoconf can't fly. Multicast is what typical >>> autoconfiguration protocols use today without which they'd never >>> work. >>> >>> Multicast is what IPv6 got builtin precisely for the reason of >>> autoconfing. >>> >>> This draft being silent about multicast spells it's not autoconf, >>> IMHO. >>> >>> Alex >>> >>>> >>>> Jari >>>> >>>> Ryuji Wakikawa kirjoitti: >>>>> Dear All, >>>>> >>>>> We have concluded the WGLC of >>>>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and >>>>> have a -02 document issued, following up on this. >>>>> >>>>> Thanks to all for all the reviews and comments to this >>>>> document! >>>>> >>>>> After Thomas and I (Chairs) carefully reviewed discussions on >>>>> the mailing list, we do find that there is rough consensus for >>>>> the current document. >>>>> >>>>> There was an individual objection to the description of the >>>>> use of link-local address, but we did not detect wide support >>>>> within the working group. This objection will, of course, be >>>>> reflected in the PROTO write-up that will be sent to the IESG >>>>> and the ADs, and reflected in the tracker. >>>>> >>>>> As a conclusion, we have established rough consensus to the >>>>> new document. >>>>> >>>>> The WG chairs will start preparing the PROTO writeup for >>>>> forwarding the document. >>>>> >>>>> Thanks, >>>>> >>>>> WG chairs >>>>> >>>>> >>>> >>>> _______________________________________________ Autoconf mailing >>>> list Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>>> >>> >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Feb 16 12:39:43 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F2AB3A78B1 for ; Tue, 16 Feb 2010 12:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFfhTrM1IIKe for ; Tue, 16 Feb 2010 12:39:42 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 23E3128C171 for ; Tue, 16 Feb 2010 12:39:40 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 46EF5D4813B; Tue, 16 Feb 2010 21:41:12 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 03902D4806C; Tue, 16 Feb 2010 21:41:09 +0100 (CET) Message-ID: <4B7B02E4.2050206@gmail.com> Date: Tue, 16 Feb 2010 21:41:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> <4B7B000C.1070602@gmail.com> <6A7C46D7-A872-4D00-AE85-C0E72FD48EC3@thomasclausen.org> In-Reply-To: <6A7C46D7-A872-4D00-AE85-C0E72FD48EC3@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100216-1, 16/02/2010), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:39:43 -0000 ThomasC, oh sorry, so the problem statement document is going to happen later? We're not yet at that stage? And in this "IP Addressing Model in Ad Hoc Networks" we don't even mention multicast addresses, as if the multicast address were not an address? Sorry for disturbing but my remark was really gentle, I thought the draft could easily mention multicast address. I sometimes feel that the more I ask a thing the less it gets accepted. IT must be because it comes from me :-) I will shut up maybe things will happen better :-) Alex Le 16/02/2010 21:35, Thomas Heide Clausen a écrit : > Dear Alex, > > On Feb 16, 2010, at 21:29 PM, Alexandru Petrescu wrote: > >> Le 16/02/2010 21:23, Thomas Heide Clausen a écrit : >>> Dear Alex, >>> >>> Autoconf is about configuring addresses on interfaces, not on >>> allocating addresses in a registry, not sending IP packets to >>> multicast destinations. >> >> Thomas, thank you for the reply. >> >> Link-layer multicast mechanisms are used in any autoconfing (DHCPv6, >> SLAAC, probably more) mechanism. >> >> A stack booting up sends packets to multicast destinations. >> >> MANET already allocates a multicast address for this. >> >> Suffices it to mention it. >> > > These reflections belong properly in the problem-statement/scoping and > solution-space discussions -- hopefully, we will be able to get to those > (the fun part: building protocols) soon. So hold that thought until later. > >> Otherwise leave place for non-understanding: will the IPv6 autoconf >> stack use the MANET multicast address? Or the other non-MANET multicast >> address? > > If I configure my addresses manually, as is one viable option, I can > follow the recommendations in > draft-ietf-autoconf-adhoc-addr-model-02.txt and have a valid > configuration. In that case, the "configuration mechanism" needs no > multicast. I note that this may apply more to IPv4 than IPv6, and that > the document covers both. > > If a MANET autoconfiguration protocol needs to exchange information for > proper functioning - which it may well do - then that protocol will have > to decide on which addresses, messages and algorithms to use for that. > So again, these reflections belong properly in the > problem-statement/scoping and solution-space discussions. > > Sincerely, > > Thomas > >> I mostly agree with you. >> >> And there are two different people here (Teco, myself) saying >> approximately the same thing about multicast. The autoconf group is not >> large. Are two opinions worth ignoring? >> >> Alex >> >>> >>> Sincerely, >>> >>> Thomas >>> >>> >>> On Feb 16, 2010, at 21:20 PM, Alexandru Petrescu wrote: >>> >>>> Le 16/02/2010 21:01, Jari Arkko a écrit : >>>>> Great. Lets move this doc forward! >>>> >>>> YEs, let's move this forward and add multicast discussion to it >>>> without which autoconf can't fly. Multicast is what typical >>>> autoconfiguration protocols use today without which they'd never >>>> work. >>>> >>>> Multicast is what IPv6 got builtin precisely for the reason of >>>> autoconfing. >>>> >>>> This draft being silent about multicast spells it's not autoconf, >>>> IMHO. >>>> >>>> Alex >>>> >>>>> >>>>> Jari >>>>> >>>>> Ryuji Wakikawa kirjoitti: >>>>>> Dear All, >>>>>> >>>>>> We have concluded the WGLC of >>>>>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and >>>>>> have a -02 document issued, following up on this. >>>>>> >>>>>> Thanks to all for all the reviews and comments to this >>>>>> document! >>>>>> >>>>>> After Thomas and I (Chairs) carefully reviewed discussions on >>>>>> the mailing list, we do find that there is rough consensus for >>>>>> the current document. >>>>>> >>>>>> There was an individual objection to the description of the >>>>>> use of link-local address, but we did not detect wide support >>>>>> within the working group. This objection will, of course, be >>>>>> reflected in the PROTO write-up that will be sent to the IESG >>>>>> and the ADs, and reflected in the tracker. >>>>>> >>>>>> As a conclusion, we have established rough consensus to the >>>>>> new document. >>>>>> >>>>>> The WG chairs will start preparing the PROTO writeup for >>>>>> forwarding the document. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> WG chairs >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ Autoconf mailing >>>>> list Autoconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>> >>>> >>>> _______________________________________________ Autoconf mailing >>>> list Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>> >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From charles.perkins@earthlink.net Tue Feb 16 12:45:16 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EDEB28C1BB for ; Tue, 16 Feb 2010 12:45:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGJM2xAtSgfa for ; Tue, 16 Feb 2010 12:45:14 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 89EAC28C1BC for ; Tue, 16 Feb 2010 12:45:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bD4exbWUutMNoZ5RusNDYGTp5oUgAO889JP0pj5Rwb7+monCzRDmMqc6WExH8WQY; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.77]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhUJi-0007NG-I1; Tue, 16 Feb 2010 15:46:47 -0500 Message-ID: <4B7B0433.6080305@earthlink.net> Date: Tue, 16 Feb 2010 12:46:43 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <4B6B0E85.5050101@earthlink.net> <003e01caa63e$a8d190d0$fa74b270$@nl> <4B6C64F6.9040807@earthlink.net> <009601caaf25$d2005b90$760112b0$@nl> In-Reply-To: <009601caaf25$d2005b90$760112b0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f528dbbee57eb5a13ae969cf6e9e7240b66350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 20:45:16 -0000 Hello Teco, Replies inline. I had hoped that my answers were going to resolve your issues, but I see there is still more to be discussed... On 2/16/2010 8:33 AM, Teco Boot wrote: >>> ... existing IP addressing models don't depend on such clever >>> thing. Here, we have the "assumption". Right? >> >> First, I do not understand what the "assumption" >> is that you mean here. >> >> Second, existing IP addressing models that you >> might be referring to, depend on a model of a >> link == communication medium that does not pertain >> to all ad hoc networks. > > No, existing IP addressing models work with non-transitive links I don't think anyone is disputing that _some_ of them do. > also. When there is a link, there is IP communication. I don't think anyone is disputing that. ... > >>>> I also do not >>>> agree that we must avoid being clever. >>> >>> Agreed. That is why I use an addressing model that is better resistant >>> against failures. >> >> I didn't see which model you meant. > > How do IEEE 802.11 IBSS users configure their network today? A lot of different ways, some of which are quite incompatible with some ad hoc networks. >>>> I read this, and had to smile. Of course there's no reason >>>> to avoid link-locals for 1-hop traffic as long as you _know_ >>>> it's one hop. In fact, blast away. >>> >>> OK, now we are there. >>> MANET protocols that use RFC5498 can perfectly use link-locals. >>> Same for L2 address resolving, as ND does. >> >> You can be very mysterious at times. I admit defeat, >> unable to meet the challenge of understanding your meaning. > > Sorry. Maybe I should include a complete packet trace. I hope it's possible to exhibit your meaning by distilling something important out of a mass of information. > In short: OLSR packets source address is typically LL > when using IPv6 LL-MANET-Routers, because LL-MANET-Routers > has scope Link-Local. See RFC5498 for the details. I never denied that some protocols should be allowed to use link-local addresses. It seems to me, though, that various OLSR proponents are very much in favor of promulgating the existing addressing document. So, the dichotomy that you seem to suggest does not exist. And such false dichotomies have plagued this discussion for so many years. And continue to do so, it seems. > And the IPv6 stack uses the link-locals for MLD and ND. > Try to get rid of it yourself. You guess need to rewrite > a lot in the IPv6 stack. Not really. We did it a very long time ago. It worked great. >> As you well know, ND works for nodes in range. >> As specified now, it does not work for nodes that >> are not in range, in case you wanted to tackle the >> onerous project of creating a wireless link that >> exceeds the transmission range of any node in the >> link. > > IP depends on sub-IP links. So yes, you are right. > But what is your message? Can ARP resolve L2 addresses > multi-hop? Do you need something like that? > No, of course not. Me? Need multi-hop links? Surely you jest :-). > IMHO the MANET routing protocol extends the communication > capability from single-hop to multi-hop. We know how to this. Thank goodness! > But: > The MANET addressing model shall not limit single hop > communication in cases where the MANET routing protocol > is inactive. This is my requirement. I don't see any suggestion that your requirement has been contravened. > Also important, as far as I know, the majority of current > operational MANETs have a common prefix for the MANET segment. > And the MANET routing protocol advertises the /32 "host prefix" > in the MANET, if this address is required to be reachable. > This works great. That is the reason it is deployed so much. I like it. Why can't we go with that for a while? >>>> But for people who are running networks without such >>>> comforts, assurance of availability for a L2 communication >>>> channel is often necessary or at least highly desirable. >>>> Then suddenly your link-local address is potentially >>>> (a) invalid (b) unavailable or (c) ambiguous. These >>>> are normally considered poor indicators for IP-based >>>> communications. >>> >>> What happens if your ULA or global is (a) invalid, >>> (b) unavailable or (c) ambiguous? >>> I don't see a difference with link-locals. >>> Link-locals are used for protocols that require 1-hop >>> communication or when no other addresses are available. >>> In the latter, it is also 1-hop only. >> >> Teco, whenever you ask this question, please first >> revisit my explanation which I have offered perhaps >> a dozen times in the past: >> - determining link-local uniqueness should not require >> multi-hop protocol action > > IMHO this answer is incorrect. I guess you think multi-(L3)hop protocols can be used to insure link-local uniqueness. This is a matter on which consensus might be measured. If more people agree with you, then I'll be surprised. If it's L2, then it's out of scope for this discussion. > IMHO this answer is incorrect. Or do you use non-link-local > addresses that determine global uniqueness with single-hop > communication? Or addresses with an angel, defending uniqueness? Global uniqueness can be ascertained with multi-hop protocols. I can't imagine that anyone would seriously argue against this. >> - with ad hoc networks, you may not know if a node >> with a link-local address on a particular link >> is actually adjacent/neighboring/in-range/... > > This is a valid answer. But handling this issue requires an > update on address selection. I am sorry, but I think this is one of the most outrageously wrong proposals you have made. To put it mildly, I disagree most vociferously. I almost dare you to find a single AD who might agree. > So we have to write a draft that > updates RFC3484 one day. Many products in use have a policy > that selects global or ULA over link-local addresses for packets > that may require multi-hop communication. LL addresses should not > be preferred for that. Nope, nopity, nope, nope, nope. This is quite orthogonal to any discussion about preferring global vs. ULAs. > And there is a good reason for repeating this question. > I'll stop when there is a nice mechanism for IPv6 multi-homed > MANETs without NAT. So, we can't make an addressing model in [autoconf] without boiling all 7 NAT oceans? You can't be serious. > I can't see how we can do this without prefix swapping, where > the prefix comes from the border router. That's because you insist on flogging yourself with link-local bullwhips. > And for smooth > address swapping, I suggest not repeating address uniqueness > testing. Finally, a statement I can agree with :-). > So I suggest to use unique InterfaceIDs. By nature, > by good randomization and / or by duplicate check. If you have unique InterfaceIDs, there is _no issue_. Nothing to talk about. Zippity nil nada. So go write the [autoconf] document that restricts to that condition. You'll have lots of friends, I reckon. It's a different problem (or, more properly, a way of defining the problem out of existence). This is also a point I have tried to make at least a dozen times. If that's the universe in which you are trying to reside, why not do so and formalize your intent? >>> With IPv6 in mind, the general case can easily include >>> link-locals. Wouldn't it be nice to support IPv6 basics? >> >> I have IPv6 in mind. The general case does not >> easily include link-locals over wireless media. > > It is up and running in many scenario's already. I can't > remember a single issue. You apparently assume unique InterfaceIDs. I no longer see where our discussions need to intersect. > Yes, duplicate testing. That is an issue for non-link-locals > also! And who claimed otherwise?? >> The particular specializations _may_ include >> link-locals. >> >> Wouldn't it be nicer to avoid requiring >> particular specializations when the general >> case is just waiting for us to quit delaying >> and standardize an already-known solution? > > Yes. But we don't agree on what is used today. The way it seems to me, is that you don't agree that anyone can use anything else other than unique InterfaceIDs (i.e., what you use today). Regards, Charlie P. From charles.perkins@earthlink.net Tue Feb 16 13:19:23 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 574BE28C1DF for ; Tue, 16 Feb 2010 13:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs37OPtecsMz for ; Tue, 16 Feb 2010 13:19:22 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 4BABF3A722A for ; Tue, 16 Feb 2010 13:19:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lzPBw30TWZovUIkK+MvvbOzEeciBzhlvv2attHZ+t3+6/ENm36r4fQGWnRakLQnn; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.74.16] (helo=[192.168.1.77]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhUqn-0004J1-EI; Tue, 16 Feb 2010 16:20:57 -0500 Message-ID: <4B7B0C36.9000805@earthlink.net> Date: Tue, 16 Feb 2010 13:20:54 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Teco Boot References: <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net> <00a601caa19e$7122c810$53685830$@nl> <005501caa5a5$9b0fc7d0$d12f5770$@nl> <6CD290EC-969F-4421-B5C9-0558A4A5A865@thomasclausen.org> <003501caa63a$7b15ca20$71415e60$@nl> <93EB52DC-5869-450B-B1BE-8870D010BEF5@thomasclausen.org> <007401caa681$61506090$23f121b0$@nl> <008f01caaf1e$925b5820$b7120860$@nl> In-Reply-To: <008f01caaf1e$925b5820$b7120860$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5285d80323c904276662d8f4367285df17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.74.16 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Updated ad hoc addressing model document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 21:19:23 -0000 Hello Teco, I'm not a document author, but I have been answering your questions. More comments below. On 2/16/2010 7:41 AM, Teco Boot wrote: >>> Agreed that with the proposed addressing model, under conditions that >>> the 'something clever' is not functioning, L3 communication fails for >>> links between two nodes that have L2 communication? >> >> No, I do not agree with the above. > > I think you miss something important here. What? I agree that L2 neighbors can exchange L3 packets even with no MANET routing protocol operational. Do you disagree??! > Far more important. It doesn't work when I post during WGLC, and it is > ignored totally. I even disagree with this, since I have not ignored your postings. What am I, chopped liver? [old New Yorker joke...] >> You state that there's something wrong with the >> document and that you have an "alternative model". That's fair enough, >> but then the onus is on you to explain what is wrong, lay out your >> "alternative model", and make sure that in doing so it addresses also >> the concerns which draft-ietf-autoconf-adhoc-addr-model raise. > > I explained what is wrong. And at least one (Carlos) understands > the issue in the document. All the defects you have claimed, I have tried to redress. > Again, my response during WGLC on this topic: > Page 4: > If L2 communication is enabled between a pair of interfaces, IP > packet exchange is enabled regardless of the IP subnet configuration > on each of these interfaces. > This is only possible if the IP stack is aware of the L2 link between the > pair of interfaces. That is tautological. Let's agree to agree on statements that are tautological. > One way of establishing this is configure an on-link > subnet prefix. That's one way. > Now we choose not to configure so, and instead run a MANET > protocol. This is hardly the only other choice available. > But this makes IP communication dependent on the MANET protocol, > which can have a negative effect on managing the network. Well, so much for _that_ straw man. It burned so easily down to the ground. > Think of remote > management and updates on the MANET protocol. I'm thinking about that. What inference am I supposed to draw? Regards, Charlie P. From ryuji.wakikawa@gmail.com Tue Feb 16 15:57:59 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EBF73A7E11 for ; Tue, 16 Feb 2010 15:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K15dW2mqbkAU for ; Tue, 16 Feb 2010 15:57:58 -0800 (PST) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by core3.amsl.com (Postfix) with ESMTP id 15FCE3A6AD0 for ; Tue, 16 Feb 2010 15:57:58 -0800 (PST) Received: by ywh2 with SMTP id 2so516865ywh.31 for ; Tue, 16 Feb 2010 15:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=/LR6L8et9gQzYZtVer5taUzbvAvItUHbVJ/dFemdGqo=; b=p7s9sauMqm6YfG1HQuKUFaHNQ+TsHXM5jth/mMQtS1LJcqI9t1VOWW8mt0YNUOjpaH dB+7H5PrAeKIqFgz7eSiC+fWHMfMKib+wfQqg0tupBJ4jn4Qzubjmg9VeW0lOPbvSaqT nOcj551wnq6GecRUa0mE7Kllh0AQ6nqWraOJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=Lyzkc9ZyVjPHI0iRgR9X+tiovI6SiotKdWt0klgq8NUqeucYjj4khhNwqhlqsY5wpt b0TTM651JpIY49YOnEM1Qc04A2BSpy2p7RgNtNe7e9YOaBUhzrvuGROOxIfx+AW5i7SE T0F0WG7xDcjoGj/yqs8hY75sJILJonBgPXlx8= Received: by 10.150.118.29 with SMTP id q29mr5921163ybc.200.1266364769700; Tue, 16 Feb 2010 15:59:29 -0800 (PST) Received: from macbookpro-ryuji.paloalto.toyota-itc.com ([206.132.173.18]) by mx.google.com with ESMTPS id 6sm3020701ywc.53.2010.02.16.15.59.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 15:59:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Ryuji Wakikawa In-Reply-To: <4B7B02E4.2050206@gmail.com> Date: Tue, 16 Feb 2010 15:59:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> <4B7B000C.1070602@gmail.com> <6A7C46D7-A872-4D00-AE85-C0E72FD48EC3@thomasclausen.org> <4B7B02E4.2050206@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 23:57:59 -0000 Hi Alex, On 2010/02/16, at 12:41, Alexandru Petrescu wrote: > ThomasC, oh sorry, so the problem statement document is going to = happen later? We're not yet at that stage? Thomas means a problem statement document for the future solution space, = since you start explaining solution spaces. The addr-model document is not a solution. There is no need to have a = problem statement at this stage. > And in this "IP Addressing Model in Ad Hoc Networks" we don't even = mention multicast addresses, as if the multicast address were not an = address? >=20 > Sorry for disturbing but my remark was really gentle, I thought the = draft could easily mention multicast address. >=20 > I sometimes feel that the more I ask a thing the less it gets = accepted. IT must be because it comes from me :-) Not at all. We cannot adapt comments only when there is less supporter.=20= We have to move forward based on the consensus.=20 > I will shut up maybe things will happen better :-) :-) regards, ryuji >=20 > Alex >=20 > Le 16/02/2010 21:35, Thomas Heide Clausen a =E9crit : >> Dear Alex, >>=20 >> On Feb 16, 2010, at 21:29 PM, Alexandru Petrescu wrote: >>=20 >>> Le 16/02/2010 21:23, Thomas Heide Clausen a =E9crit : >>>> Dear Alex, >>>>=20 >>>> Autoconf is about configuring addresses on interfaces, not on >>>> allocating addresses in a registry, not sending IP packets to >>>> multicast destinations. >>>=20 >>> Thomas, thank you for the reply. >>>=20 >>> Link-layer multicast mechanisms are used in any autoconfing (DHCPv6, >>> SLAAC, probably more) mechanism. >>>=20 >>> A stack booting up sends packets to multicast destinations. >>>=20 >>> MANET already allocates a multicast address for this. >>>=20 >>> Suffices it to mention it. >>>=20 >>=20 >> These reflections belong properly in the problem-statement/scoping = and >> solution-space discussions -- hopefully, we will be able to get to = those >> (the fun part: building protocols) soon. So hold that thought until = later. >>=20 >>> Otherwise leave place for non-understanding: will the IPv6 autoconf >>> stack use the MANET multicast address? Or the other non-MANET = multicast >>> address? >>=20 >> If I configure my addresses manually, as is one viable option, I can >> follow the recommendations in >> draft-ietf-autoconf-adhoc-addr-model-02.txt and have a valid >> configuration. In that case, the "configuration mechanism" needs no >> multicast. I note that this may apply more to IPv4 than IPv6, and = that >> the document covers both. >>=20 >> If a MANET autoconfiguration protocol needs to exchange information = for >> proper functioning - which it may well do - then that protocol will = have >> to decide on which addresses, messages and algorithms to use for = that. >> So again, these reflections belong properly in the >> problem-statement/scoping and solution-space discussions. >>=20 >> Sincerely, >>=20 >> Thomas >>=20 >>> I mostly agree with you. >>>=20 >>> And there are two different people here (Teco, myself) saying >>> approximately the same thing about multicast. The autoconf group is = not >>> large. Are two opinions worth ignoring? >>>=20 >>> Alex >>>=20 >>>>=20 >>>> Sincerely, >>>>=20 >>>> Thomas >>>>=20 >>>>=20 >>>> On Feb 16, 2010, at 21:20 PM, Alexandru Petrescu wrote: >>>>=20 >>>>> Le 16/02/2010 21:01, Jari Arkko a =E9crit : >>>>>> Great. Lets move this doc forward! >>>>>=20 >>>>> YEs, let's move this forward and add multicast discussion to it >>>>> without which autoconf can't fly. Multicast is what typical >>>>> autoconfiguration protocols use today without which they'd never >>>>> work. >>>>>=20 >>>>> Multicast is what IPv6 got builtin precisely for the reason of >>>>> autoconfing. >>>>>=20 >>>>> This draft being silent about multicast spells it's not autoconf, >>>>> IMHO. >>>>>=20 >>>>> Alex >>>>>=20 >>>>>>=20 >>>>>> Jari >>>>>>=20 >>>>>> Ryuji Wakikawa kirjoitti: >>>>>>> Dear All, >>>>>>>=20 >>>>>>> We have concluded the WGLC of >>>>>>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and >>>>>>> have a -02 document issued, following up on this. >>>>>>>=20 >>>>>>> Thanks to all for all the reviews and comments to this >>>>>>> document! >>>>>>>=20 >>>>>>> After Thomas and I (Chairs) carefully reviewed discussions on >>>>>>> the mailing list, we do find that there is rough consensus for >>>>>>> the current document. >>>>>>>=20 >>>>>>> There was an individual objection to the description of the >>>>>>> use of link-local address, but we did not detect wide support >>>>>>> within the working group. This objection will, of course, be >>>>>>> reflected in the PROTO write-up that will be sent to the IESG >>>>>>> and the ADs, and reflected in the tracker. >>>>>>>=20 >>>>>>> As a conclusion, we have established rough consensus to the >>>>>>> new document. >>>>>>>=20 >>>>>>> The WG chairs will start preparing the PROTO writeup for >>>>>>> forwarding the document. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> WG chairs >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ Autoconf mailing >>>>>> list Autoconf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ Autoconf mailing >>>>> list Autoconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/autoconf >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >>=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Feb 17 06:50:01 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E79C3A7ED1 for ; Wed, 17 Feb 2010 06:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLfvcigymonH for ; Wed, 17 Feb 2010 06:50:00 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 21CB53A7D12 for ; Wed, 17 Feb 2010 06:49:59 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HEpbx1027239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 17 Feb 2010 15:51:37 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HEpbaP017729 for ; Wed, 17 Feb 2010 15:51:37 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HEpbPQ010009 for ; Wed, 17 Feb 2010 15:51:37 +0100 Message-ID: <4B7C0279.2030904@gmail.com> Date: Wed, 17 Feb 2010 15:51:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> In-Reply-To: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [Autoconf] Licensing scheme for draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 14:50:01 -0000 HEllo AUTOCONFers, About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model. Its boilerplate currently says "Code Components extracted from this document must include Simplified BSD License...". I disagree with it for three reasons. First and foremost I do not want Code Components extracted from this document to include that license, but another one. E.g. if linux kernel implements it then GPL is more suitable. Second, if there are no Code Components then it would be useless to talk about Code Components. Also I disagree with it because the implementation experience which has been shared on this list often has been about linux, and which is often GPL and rarely BSD license. I also have to say I understand fully that the boilerplate is there from the IETF Trust to which I am bound to abide, by the fact that I am subscribed to this list. Respectfully, Alex (this is about a series of I-Ds I am following in several WGs) Le 16/02/2010 20:59, Ryuji Wakikawa a écrit : > Dear All, > > We have concluded the WGLC of > draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a > -02 document issued, following up on this. > > Thanks to all for all the reviews and comments to this document! > > After Thomas and I (Chairs) carefully reviewed discussions on the > mailing list, we do find that there is rough consensus for the > current document. > > There was an individual objection to the description of the use of > link-local address, but we did not detect wide support within the > working group. This objection will, of course, be reflected in the > PROTO write-up that will be sent to the IESG and the ADs, and > reflected in the tracker. > > As a conclusion, we have established rough consensus to the new > document. > > The WG chairs will start preparing the PROTO writeup for forwarding > the document. > > Thanks, > > WG chairs > > _______________________________________________ Autoconf mailing > list Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From zach@sensinode.com Wed Feb 17 06:59:30 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BE503A70E2 for ; Wed, 17 Feb 2010 06:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+4AJCt0CVkb for ; Wed, 17 Feb 2010 06:59:29 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id E84BE3A7710 for ; Wed, 17 Feb 2010 06:59:28 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o1HF10mT004997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Feb 2010 17:01:01 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <4B7C0279.2030904@gmail.com> Date: Wed, 17 Feb 2010 17:01:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <17AB1C98-132A-4E35-94B4-0C4A91776556@sensinode.com> References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7C0279.2030904@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Licensing scheme for draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 14:59:30 -0000 Alex, There is no code in this I-D, therefore this is pointless. And as this = is the IETF trust boilerplate, it is also useless to discuss it here as = you pointed out yourself.=20 Zach On Feb 17, 2010, at 16:51 , Alexandru Petrescu wrote: > HEllo AUTOCONFers, >=20 > About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model. >=20 > Its boilerplate currently says "Code Components extracted from this > document must include Simplified BSD License...". >=20 > I disagree with it for three reasons. First and foremost I do not = want > Code Components extracted from this document to include that license, > but another one. E.g. if linux kernel implements it then GPL is more > suitable. Second, if there are no Code Components then it would be > useless to talk about Code Components. >=20 > Also I disagree with it because the implementation experience which = has > been shared on this list often has been about linux, and which is = often > GPL and rarely BSD license. >=20 > I also have to say I understand fully that the boilerplate is there = from > the IETF Trust to which I am bound to abide, by the fact that I am > subscribed to this list. >=20 > Respectfully, >=20 > Alex > (this is about a series of I-Ds I am following in several WGs) >=20 > Le 16/02/2010 20:59, Ryuji Wakikawa a =E9crit : >> Dear All, >>=20 >> We have concluded the WGLC of >> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a >> -02 document issued, following up on this. >>=20 >> Thanks to all for all the reviews and comments to this document! >>=20 >> After Thomas and I (Chairs) carefully reviewed discussions on the >> mailing list, we do find that there is rough consensus for the >> current document. >>=20 >> There was an individual objection to the description of the use of >> link-local address, but we did not detect wide support within the >> working group. This objection will, of course, be reflected in the >> PROTO write-up that will be sent to the IESG and the ADs, and >> reflected in the tracker. >>=20 >> As a conclusion, we have established rough consensus to the new >> document. >>=20 >> The WG chairs will start preparing the PROTO writeup for forwarding >> the document. >>=20 >> Thanks, >>=20 >> WG chairs >>=20 >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >>=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From henning.rogge@fkie.fraunhofer.de Wed Feb 17 07:02:47 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F48D3A7ACC for ; Wed, 17 Feb 2010 07:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DleintcpiFE4 for ; Wed, 17 Feb 2010 07:02:45 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id B0FE83A70E2 for ; Wed, 17 Feb 2010 07:02:45 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NhlRt-0006L4-Kt; Wed, 17 Feb 2010 16:04:21 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NhlRt-0003SI-6i; Wed, 17 Feb 2010 16:04:21 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Wed, 17 Feb 2010 16:04:10 +0100 User-Agent: KMail/1.12.4 (Linux/2.6.31-17-generic; KDE/4.3.5; i686; ; ) References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7C0279.2030904@gmail.com> In-Reply-To: <4B7C0279.2030904@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart21466508.SeMZ5KGcRB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002171604.15551.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.3/10400/Wed Feb 17 12:28:53 2010) by mailguard.fgan.de X-Scan-Signature: 093a4d18fb20d26714c728ddf8a13ad0 Subject: Re: [Autoconf] Licensing scheme for draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 15:02:47 -0000 --nextPart21466508.SeMZ5KGcRB Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed February 17 2010 15:51:37 Alexandru Petrescu wrote: > HEllo AUTOCONFers, >=20 > About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model. >=20 > Its boilerplate currently says "Code Components extracted from this > document must include Simplified BSD License...". >=20 > I disagree with it for three reasons. First and foremost I do not want > Code Components extracted from this document to include that license, > but another one. E.g. if linux kernel implements it then GPL is more > suitable. Second, if there are no Code Components then it would be > useless to talk about Code Components. You can get from "simplified BSD" (2-clause BSD) to GPL. The other way arou= nd=20 is not possible. See http://tinyurl.com/ykwyud4 (Link to wikipedia). =46orcing GPL would mean that the code fragments cannot be included into=20 commercial software, which contradicts the purpose of the IETF RFCs. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart21466508.SeMZ5KGcRB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkt8BWoACgkQRIfGfFXsz+A6DwCeIUgIcSV3rdsxQMJuHYqWXq8M P3gAmwQqaVfVKC/VUN8TtocZZa7WzK6w =omVX -----END PGP SIGNATURE----- --nextPart21466508.SeMZ5KGcRB-- From ulrich@herberg.name Wed Feb 17 07:09:36 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3515428C102 for ; Wed, 17 Feb 2010 07:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSSNhzlEGy0e for ; Wed, 17 Feb 2010 07:09:32 -0800 (PST) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id CFB213A773A for ; Wed, 17 Feb 2010 07:09:31 -0800 (PST) Received: by bwz19 with SMTP id 19so5600800bwz.28 for ; Wed, 17 Feb 2010 07:11:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.6.203 with SMTP id a11mr1671371bka.33.1266419463274; Wed, 17 Feb 2010 07:11:03 -0800 (PST) In-Reply-To: <17AB1C98-132A-4E35-94B4-0C4A91776556@sensinode.com> References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7C0279.2030904@gmail.com> <17AB1C98-132A-4E35-94B4-0C4A91776556@sensinode.com> Date: Wed, 17 Feb 2010 16:11:03 +0100 Message-ID: <25c114b91002170711k61243ae6h5ce791bc5d3aedba@mail.gmail.com> From: Ulrich Herberg To: Zach Shelby Content-Type: multipart/alternative; boundary=0015175884b63ec264047fcd429e Cc: autoconf@ietf.org Subject: Re: [Autoconf] Licensing scheme for draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 15:09:36 -0000 --0015175884b63ec264047fcd429e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex, I second Zach. This I-D does not contain any code. And as you have been indicated in the ROLL WG, this mailing list is the wrong place to discuss the boilerplate. Ulrich On Wed, Feb 17, 2010 at 4:01 PM, Zach Shelby wrote: > Alex, > > There is no code in this I-D, therefore this is pointless. And as this is > the IETF trust boilerplate, it is also useless to discuss it here as you > pointed out yourself. > > Zach > > On Feb 17, 2010, at 16:51 , Alexandru Petrescu wrote: > > > HEllo AUTOCONFers, > > > > About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model. > > > > Its boilerplate currently says "Code Components extracted from this > > document must include Simplified BSD License...". > > > > I disagree with it for three reasons. First and foremost I do not want > > Code Components extracted from this document to include that license, > > but another one. E.g. if linux kernel implements it then GPL is more > > suitable. Second, if there are no Code Components then it would be > > useless to talk about Code Components. > > > > Also I disagree with it because the implementation experience which has > > been shared on this list often has been about linux, and which is often > > GPL and rarely BSD license. > > > > I also have to say I understand fully that the boilerplate is there fro= m > > the IETF Trust to which I am bound to abide, by the fact that I am > > subscribed to this list. > > > > Respectfully, > > > > Alex > > (this is about a series of I-Ds I am following in several WGs) > > > > Le 16/02/2010 20:59, Ryuji Wakikawa a =E9crit : > >> Dear All, > >> > >> We have concluded the WGLC of > >> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a > >> -02 document issued, following up on this. > >> > >> Thanks to all for all the reviews and comments to this document! > >> > >> After Thomas and I (Chairs) carefully reviewed discussions on the > >> mailing list, we do find that there is rough consensus for the > >> current document. > >> > >> There was an individual objection to the description of the use of > >> link-local address, but we did not detect wide support within the > >> working group. This objection will, of course, be reflected in the > >> PROTO write-up that will be sent to the IESG and the ADs, and > >> reflected in the tracker. > >> > >> As a conclusion, we have established rough consensus to the new > >> document. > >> > >> The WG chairs will start preparing the PROTO writeup for forwarding > >> the document. > >> > >> Thanks, > >> > >> WG chairs > >> > >> _______________________________________________ Autoconf mailing > >> list Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf > >> > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > -- > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system without > producing, distributing or retaining copies thereof. > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --0015175884b63ec264047fcd429e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,

I second Zach. This I-D does not contain any code. And as you = have been indicated in the ROLL WG, this mailing list is the wrong place to= discuss the boilerplate.

Ulrich

On Wed, Feb 17, 2010 at 4:01 PM, Zach Shelby <zach@sensinode.com> wrote:
=
Alex,

There is no code in this I-D, therefore this is pointless. And as this is t= he IETF trust boilerplate, it is also useless to discuss it here as you poi= nted out yourself.

Zach

On Feb 17, 2010, at 16:51 , Alexandru Petrescu wrote:

> HEllo AUTOCONFers,
>
> About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model.<= br> >
> Its boilerplate currently says "Code Components extracted from th= is
> document must include Simplified BSD License...".
>
> I disagree with it for three reasons. =A0First and foremost I do not w= ant
> Code Components extracted from this document to include that license,<= br> > but another one. =A0E.g. if linux kernel implements it then GPL is mor= e
> suitable. =A0Second, if there are no Code Components then it would be<= br> > useless to talk about Code Components.
>
> Also I disagree with it because the implementation experience which ha= s
> been shared on this list often has been about linux, and which is ofte= n
> GPL and rarely BSD license.
>
> I also have to say I understand fully that the boilerplate is there fr= om
> the IETF Trust to which I am bound to abide, by the fact that I am
> subscribed to this list.
>
> Respectfully,
>
> Alex
> (this is about a series of I-Ds I am following in several WGs)
>
> Le 16/02/2010 20:59, Ryuji Wakikawa a =E9crit :
>> Dear All,
>>
>> We have concluded the WGLC of
>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have= a
>> -02 document issued, following up on this.
>>
>> Thanks to all for all the reviews and comments to this document! >>
>> After Thomas and I (Chairs) carefully reviewed discussions on the<= br> >> mailing list, we do find that there is rough consensus for the
>> current document.
>>
>> There was an individual objection to the description of the use of=
>> link-local address, but we did not detect wide support within the<= br> >> working group. This objection will, of course, be reflected in the=
>> PROTO write-up that will be sent to the IESG and the ADs, and
>> reflected in the tracker.
>>
>> As a conclusion, we have established rough consensus to the new >> document.
>>
>> The WG chairs will start preparing the PROTO writeup for forwardin= g
>> the document.
>>
>> Thanks,
>>
>> WG chairs
>>
>> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf
>>
>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf

--
http://www.sensinode= .com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - N= ew book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain lega= lly privileged information. If you are not the intended recipient, please c= ontact the sender and delete the e-mail from your system without producing,= distributing or retaining copies thereof.




_______________________________________________

--0015175884b63ec264047fcd429e-- From thomas@thomasclausen.org Wed Feb 17 07:15:10 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857603A7ED7 for ; Wed, 17 Feb 2010 07:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhFey4qIA2ch for ; Wed, 17 Feb 2010 07:15:08 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id C2A2C3A68D6 for ; Wed, 17 Feb 2010 07:15:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E7934430068; Wed, 17 Feb 2010 07:16:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.133.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9F7C243003C; Wed, 17 Feb 2010 07:16:43 -0800 (PST) Message-Id: <82A71BCF-9C57-46D1-AE00-CF2CB97DB937@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B7C0279.2030904@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Feb 2010 16:16:41 +0100 References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7C0279.2030904@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Adrian Farrel Subject: Re: [Autoconf] Licensing scheme for draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 15:15:10 -0000 Dear Alex, As has been pointed out to you by Adrian Farrel (RTG AD) on = roll@ietf.org=20 , when you raised the exact same issue there, discussions concerning =20 the I-D boilerplate and licensing are appropriate on the tlp-interest =20= mailing list -- and NOT on WG mailing lists. I would therefore kindly ask that you move this discussion to the =20 appropriate mailing list -- and that you cease discussion on this =20 particular matter on autoconf@ietf.org. I entered "tlp-interest mailing list" in a well-known web-search =20 engine, which as first result returned this URL -- which I believe =20 would be a more appropriate venue, should you want to continue =20 discussing this: https://www.ietf.org/mailman/listinfo/tlp-interest Thanks in advance for your kind cooperation on this matter, Thomas On Feb 17, 2010, at 15:51 PM, Alexandru Petrescu wrote: > HEllo AUTOCONFers, > > About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model. > > Its boilerplate currently says "Code Components extracted from this > document must include Simplified BSD License...". > > I disagree with it for three reasons. First and foremost I do not =20 > want > Code Components extracted from this document to include that license, > but another one. E.g. if linux kernel implements it then GPL is more > suitable. Second, if there are no Code Components then it would be > useless to talk about Code Components. > > Also I disagree with it because the implementation experience which =20= > has > been shared on this list often has been about linux, and which is =20 > often > GPL and rarely BSD license. > > I also have to say I understand fully that the boilerplate is there =20= > from > the IETF Trust to which I am bound to abide, by the fact that I am > subscribed to this list. > > Respectfully, > > Alex > (this is about a series of I-Ds I am following in several WGs) > > Le 16/02/2010 20:59, Ryuji Wakikawa a =E9crit : >> Dear All, >> >> We have concluded the WGLC of >> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a >> -02 document issued, following up on this. >> >> Thanks to all for all the reviews and comments to this document! >> >> After Thomas and I (Chairs) carefully reviewed discussions on the >> mailing list, we do find that there is rough consensus for the >> current document. >> >> There was an individual objection to the description of the use of >> link-local address, but we did not detect wide support within the >> working group. This objection will, of course, be reflected in the >> PROTO write-up that will be sent to the IESG and the ADs, and >> reflected in the tracker. >> >> As a conclusion, we have established rough consensus to the new >> document. >> >> The WG chairs will start preparing the PROTO writeup for forwarding >> the document. >> >> Thanks, >> >> WG chairs >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Feb 17 09:23:19 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C2728C102 for ; Wed, 17 Feb 2010 09:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGkqxSxqgjZ7 for ; Wed, 17 Feb 2010 09:23:18 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 99AEE28C0EC for ; Wed, 17 Feb 2010 09:23:18 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HHOtq9028225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2010 18:24:56 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HHOtvu021257; Wed, 17 Feb 2010 18:24:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HHOtsu027895; Wed, 17 Feb 2010 18:24:55 +0100 Message-ID: <4B7C2667.5070400@gmail.com> Date: Wed, 17 Feb 2010 18:24:55 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7C0279.2030904@gmail.com> <82A71BCF-9C57-46D1-AE00-CF2CB97DB937@thomasclausen.org> In-Reply-To: <82A71BCF-9C57-46D1-AE00-CF2CB97DB937@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Licensing scheme for draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 17:23:19 -0000 ThomasC, members of WG autoconf - don't overeact. FYI I started a discussion on the tlp-interest cc'ing trustees; first about the procedure (should we always cc trustees, as the trustees request, even if it bounces back?). Later I will mention boilerplate. My statement about the licensing scheme is not intended for discussion. It is a public statement showing my personal opinion on the licensing scheme of this draft. It discharges me personally from any legal bind I may have with what may happen later with this draft (from a legal standpoint). (I am trying to do the same with every draft I have been following or commented on recently, because I just discovered the new strict BSD licensing in the boilerplate.) Yours, Alex Le 17/02/2010 16:16, Thomas Heide Clausen a écrit : > Dear Alex, > > > > As has been pointed out to you by Adrian Farrel (RTG AD) on > roll@ietf.org, when you raised the exact same issue there, > discussions concerning the I-D boilerplate and licensing are > appropriate on the tlp-interest mailing list -- and NOT on WG > mailing lists. > > I would therefore kindly ask that you move this discussion to the > appropriate mailing list -- and that you cease discussion on this > particular matter on autoconf@ietf.org. > > I entered "tlp-interest mailing list" in a well-known web-search > engine, which as first result returned this URL -- which I believe > would be a more appropriate venue, should you want to continue > discussing this: > > https://www.ietf.org/mailman/listinfo/tlp-interest > > Thanks in advance for your kind cooperation on this matter, > > Thomas > > > > On Feb 17, 2010, at 15:51 PM, Alexandru Petrescu wrote: > >> HEllo AUTOCONFers, >> >> About a non-technical matter of >> draft-ietf-autoconf-adhoc-addr-model. >> >> Its boilerplate currently says "Code Components extracted from this >> document must include Simplified BSD License...". >> >> I disagree with it for three reasons. First and foremost I do not >> want Code Components extracted from this document to include that >> license, but another one. E.g. if linux kernel implements it then >> GPL is more suitable. Second, if there are no Code Components then >> it would be useless to talk about Code Components. >> >> Also I disagree with it because the implementation experience >> which has been shared on this list often has been about linux, and >> which is often GPL and rarely BSD license. >> >> I also have to say I understand fully that the boilerplate is >> there from the IETF Trust to which I am bound to abide, by the fact >> that I am subscribed to this list. >> >> Respectfully, >> >> Alex (this is about a series of I-Ds I am following in several >> WGs) >> >> Le 16/02/2010 20:59, Ryuji Wakikawa a écrit : >>> Dear All, >>> >>> We have concluded the WGLC of >>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and >>> have a -02 document issued, following up on this. >>> >>> Thanks to all for all the reviews and comments to this document! >>> >>> After Thomas and I (Chairs) carefully reviewed discussions on the >>> mailing list, we do find that there is rough consensus for the >>> current document. >>> >>> There was an individual objection to the description of the use >>> of link-local address, but we did not detect wide support within >>> the working group. This objection will, of course, be reflected >>> in the PROTO write-up that will be sent to the IESG and the ADs, >>> and reflected in the tracker. >>> >>> As a conclusion, we have established rough consensus to the new >>> document. >>> >>> The WG chairs will start preparing the PROTO writeup for >>> forwarding the document. >>> >>> Thanks, >>> >>> WG chairs >>> >>> _______________________________________________ Autoconf mailing >>> list Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From charles.perkins@earthlink.net Wed Feb 17 10:22:18 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53EA3A7D74 for ; Wed, 17 Feb 2010 10:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ff4MDpTD3KJt for ; Wed, 17 Feb 2010 10:22:18 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by core3.amsl.com (Postfix) with ESMTP id 1AE043A7B99 for ; Wed, 17 Feb 2010 10:22:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RZC8x3CfsHKZDbPQymJ06skLxGnlFnrtbaIFYM0PgnQygzmY5QEL57zRjg+YzJEy; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.28]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NhoZ2-0001CQ-Sc; Wed, 17 Feb 2010 13:23:57 -0500 Message-ID: <4B7C3434.7070804@earthlink.net> Date: Wed, 17 Feb 2010 10:23:48 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alexandru Petrescu References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> In-Reply-To: <4B7AFE0E.8010100@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52946132dbc3bff88e77e3742fd7604b70350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:22:19 -0000 Hello Alex, On 2/16/2010 12:20 PM, Alexandru Petrescu wrote: > Le 16/02/2010 21:01, Jari Arkko a écrit : >> Great. Lets move this doc forward! > > YEs, let's move this forward and add multicast discussion to it without > which autoconf can't fly. What if we find that the requirements for a mobile ad hoc network do not enable us to rely on a typical autoconfiguration protocol? > Multicast is what typical autoconfiguration > protocols use today without which they'd never work. This isn't true. In every case I am aware of, we could have designed for pure broadcast operation. But of course you might just say that broadcast is a special case of multicast. In that case, your argument completely loses its apparent force anyway. > Multicast is what IPv6 got builtin precisely for the reason of autoconfing. Nothing wrong with using the tools available to perform the function for which they were built in the systems where they can be expected to work. > This draft being silent about multicast spells it's not autoconf, IMHO. Well, I strongly disagree, especially since your arguments as I understand them are fatally flawed. However, I'd be happy to have a non-tree-based local multicast group consisting of all members within range of a node. There's absolutely zero multicast protocol required to maintain membership in this group, conveniently. I would not insist to have that group definition appear in the addr-model draft. Regards, Charlie P. From hrogge@googlemail.com Wed Feb 17 10:34:11 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8A5228C184 for ; Wed, 17 Feb 2010 10:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Prs-xfXsN5ok for ; Wed, 17 Feb 2010 10:34:10 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 4232328C105 for ; Wed, 17 Feb 2010 10:34:09 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so1288839eyd.51 for ; Wed, 17 Feb 2010 10:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=/tAft+yJGNVrDWqqNkV39CgsKrsZAL+TRzuiOF850p4=; b=LIWdc/4kbFwQZ77W/wLYSBoZKskzYQyG6ill6PL9Z4lSQ/4sDfsVSu0MjU44zyxp4p oLWw93bZLqrYpI/X5/VzdO5mwptjg/wgzgyrkRdPlaok4YQB5S9L3Mnq6Drggg4Y+i7J ousGhpR1+rEYhXSHJL/iAPFBKI/xo0emsuRwQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=wfDEe69F+GRtw3BN/UtON/Q6wW2ATQEVZ5kjt7Rmna5O/6mizOgl3nhtql+xGrVUV/ 7MZrI/iAeodxW2/AI+9N82CVISF9ewO1sKgsLAAn0MKpTe9TOPgu1Ilzk3wZsBwuHydE TEb6KT4bStKHcSJpqvtTZa6A89X8NnzIFyStw= Received: by 10.213.49.143 with SMTP id v15mr3057547ebf.17.1266431746281; Wed, 17 Feb 2010 10:35:46 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 5sm23517eyh.0.2010.02.17.10.35.45 (version=SSLv3 cipher=RC4-MD5); Wed, 17 Feb 2010 10:35:45 -0800 (PST) From: Henning Rogge To: autoconf@ietf.org Date: Wed, 17 Feb 2010 19:35:37 +0100 User-Agent: KMail/1.13.0 (Linux/2.6.32-gentoo-r3; KDE/4.4.0; x86_64; ; ) References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AFE0E.8010100@gmail.com> <4B7C3434.7070804@earthlink.net> In-Reply-To: <4B7C3434.7070804@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2197851.XBJslgTVgs"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002171935.43307.hrogge@googlemail.com> Subject: Re: [Autoconf] =?iso-8859-1?q?Conclusion=3A=09draft-ietf-autoconf-adh?= =?iso-8859-1?q?oc-addr-model-02=2Etxt?= X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:34:12 -0000 --nextPart2197851.XBJslgTVgs Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Mittwoch 17 Februar 2010 19:23:48 schrieb Charles E. Perkins: > > Multicast is what typical autoconfiguration > >=20 > > protocols use today without which they'd never work. >=20 > This isn't true. In every case I am aware of, we could > have designed for pure broadcast operation. >=20 > But of course you might just say that broadcast is a > special case of multicast. In that case, your > argument completely loses its apparent force anyway. >=20 > > Multicast is what IPv6 got builtin precisely for the reason of > > autoconfing. >=20 > Nothing wrong with using the tools available to > perform the function for which they were built > in the systems where they can be expected to work. I think most "autoconf protocols" just use a linklocal multicast, which is = the=20 same as a broadcast without retransmission. =20 > > This draft being silent about multicast spells it's not autoconf, IMHO. >=20 > Well, I strongly disagree, especially since your > arguments as I understand them are fatally flawed. >=20 > However, I'd be happy to have a non-tree-based > local multicast group consisting of all members > within range of a node. There's absolutely zero > multicast protocol required to maintain membership > in this group, conveniently. Do current IP stacks even have something like "linklocal membership" ? Henning Rogge --nextPart2197851.XBJslgTVgs Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkt8Nv8ACgkQcenvcwAcHWc9NQCfSqHzZpEo8pz3TWE6ptIZeI9o j5oAn14psz49haXH0M6q58tzeZpH0ZDv =PZXA -----END PGP SIGNATURE----- --nextPart2197851.XBJslgTVgs-- From alexandru.petrescu@gmail.com Wed Feb 17 10:39:57 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB02A3A7BA5 for ; Wed, 17 Feb 2010 10:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E1QsKmDhA28 for ; Wed, 17 Feb 2010 10:39:57 -0800 (PST) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id B232528C0EC for ; Wed, 17 Feb 2010 10:39:56 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o1HIfXwg003428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 17 Feb 2010 19:41:33 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id o1HIfXh4030424; Wed, 17 Feb 2010 19:41:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o1HIfWsG011722; Wed, 17 Feb 2010 19:41:33 +0100 Message-ID: <4B7C385D.8060109@gmail.com> Date: Wed, 17 Feb 2010 19:41:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Charles E. Perkins" References: <6565C346-EBE5-425A-9291-BBCA4A9FCE27@gmail.com> <4B7AF98B.7050806@piuha.net> <4B7AFE0E.8010100@gmail.com> <4B7C3434.7070804@earthlink.net> In-Reply-To: <4B7C3434.7070804@earthlink.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2010 18:39:57 -0000 Charles - I must say thank you for the reply about motivating the absence of multicast in the autoconf addressing model because of its ressemblance to broadcast, lack of tools to build trees and dedicated suitability to non-MANET environments. I will excuse myself for not replying. I don't because this group is not friendly. Later, when we wonder who owes an answer to whom - it'll be simpler :-) Alex Le 17/02/2010 19:23, Charles E. Perkins a écrit : > > Hello Alex, > > On 2/16/2010 12:20 PM, Alexandru Petrescu wrote: >> Le 16/02/2010 21:01, Jari Arkko a écrit : >>> Great. Lets move this doc forward! >> >> YEs, let's move this forward and add multicast discussion to it >> without which autoconf can't fly. > > What if we find that the requirements for a mobile ad hoc network do > not enable us to rely on a typical autoconfiguration protocol? > > >> Multicast is what typical autoconfiguration protocols use today >> without which they'd never work. > > This isn't true. In every case I am aware of, we could have designed > for pure broadcast operation. > > But of course you might just say that broadcast is a special case of > multicast. In that case, your argument completely loses its apparent > force anyway. > > >> Multicast is what IPv6 got builtin precisely for the reason of >> autoconfing. > > Nothing wrong with using the tools available to perform the function > for which they were built in the systems where they can be expected > to work. > >> This draft being silent about multicast spells it's not autoconf, >> IMHO. > > Well, I strongly disagree, especially since your arguments as I > understand them are fatally flawed. > > However, I'd be happy to have a non-tree-based local multicast group > consisting of all members within range of a node. There's absolutely > zero multicast protocol required to maintain membership in this > group, conveniently. > > I would not insist to have that group definition appear in the > addr-model draft. > > > Regards, Charlie P. > > From jari.arkko@piuha.net Fri Feb 19 01:11:58 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88FEC28C113 for ; Fri, 19 Feb 2010 01:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBkcFuE0CuGP for ; Fri, 19 Feb 2010 01:11:57 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 671EC3A726D for ; Fri, 19 Feb 2010 01:11:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9AB9B2D290 for ; Fri, 19 Feb 2010 11:13:42 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BbOb5ySyyUY for ; Fri, 19 Feb 2010 11:13:42 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 24A7E2D257 for ; Fri, 19 Feb 2010 11:13:42 +0200 (EET) Message-ID: <4B7E5645.9090109@piuha.net> Date: Fri, 19 Feb 2010 11:13:41 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] AD review of draft-ietf-autoconf-addr-model X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 09:11:58 -0000 The document looks good. I have sent it forward to IETF Last Call. Jari From wwwrun@core3.amsl.com Fri Feb 19 05:42:16 2010 Return-Path: X-Original-To: autoconf@ietf.org Delivered-To: autoconf@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D3CBE28C1CF; Fri, 19 Feb 2010 05:42:16 -0800 (PST) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100219134216.D3CBE28C1CF@core3.amsl.com> Date: Fri, 19 Feb 2010 05:42:16 -0800 (PST) Cc: autoconf@ietf.org Subject: [Autoconf] Last Call: draft-ietf-autoconf-adhoc-addr-model (IP Addressing Model in Ad Hoc Networks) to Informational RFC X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2010 13:42:16 -0000 The IESG has received a request from the Ad-Hoc Network Autoconfiguration WG (autoconf) to consider the following document: - 'IP Addressing Model in Ad Hoc Networks ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-autoconf-adhoc-addr-model-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19285&rfc_flag=0 From cjbc@it.uc3m.es Tue Feb 23 03:39:50 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189E828C192 for ; Tue, 23 Feb 2010 03:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.466 X-Spam-Level: X-Spam-Status: No, score=-5.466 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1nuwNyrdY5A for ; Tue, 23 Feb 2010 03:39:48 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 9B79328C1B5 for ; Tue, 23 Feb 2010 03:39:47 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id F0380BA9E20 for ; Tue, 23 Feb 2010 12:41:47 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-cC/vrXnqiPNoJVT/zswl" Organization: Universidad Carlos III de Madrid Date: Tue, 23 Feb 2010 12:41:51 +0100 Message-ID: <1266925311.4036.71.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Subject: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 11:39:50 -0000 --=-cC/vrXnqiPNoJVT/zswl Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, It seems that after a very long (and not free of pain sometimes) process, the WG seems to be close to be done with its currently only one milestone. I guess we now should start working on solution-space, right? If that is finally the step to go, I'd like to know if the WG thinks that it'd make sense / be useful to update some of the documents we submitted in the past about solution space: http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02=20 http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-consideratio= ns-03 and=20 http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 I think these documents can help in the solution space discussion. If people are interested, we can update it taking into account the current direction of the WG and the addressing-model doc, so they can be used in the (hopefully) upcoming discussions. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-cC/vrXnqiPNoJVT/zswl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkuDvv4ACgkQNdy6TdFwT2evxgCfZX1qkg9Evl7Oaqf0de09wDxc QD4AoOHwTTaIk1kT3iR2wHFK9eRaweOr =LRFk -----END PGP SIGNATURE----- --=-cC/vrXnqiPNoJVT/zswl-- From ulrich@herberg.name Tue Feb 23 05:00:39 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D529628C28D for ; Tue, 23 Feb 2010 05:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srDP0yaQ2zfB for ; Tue, 23 Feb 2010 05:00:38 -0800 (PST) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by core3.amsl.com (Postfix) with ESMTP id 91BF728C1B8 for ; Tue, 23 Feb 2010 05:00:38 -0800 (PST) Received: by bwz3 with SMTP id 3so2604497bwz.29 for ; Tue, 23 Feb 2010 05:02:37 -0800 (PST) Received: by 10.204.8.75 with SMTP id g11mr2018733bkg.172.1266930157439; Tue, 23 Feb 2010 05:02:37 -0800 (PST) Received: from phoenix-mac.local (sphinx.lix.polytechnique.fr [129.104.11.1]) by mx.google.com with ESMTPS id 14sm1826050bwz.2.2010.02.23.05.02.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 05:02:33 -0800 (PST) Message-ID: <4B83D1E8.5000003@herberg.name> Date: Tue, 23 Feb 2010 14:02:32 +0100 From: Ulrich Herberg User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: autoconf@ietf.org References: <1266925311.4036.71.camel@acorde.it.uc3m.es> In-Reply-To: <1266925311.4036.71.camel@acorde.it.uc3m.es> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: Re: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 13:00:40 -0000 Hi, wouldn't we need to recharter first before working on solutions? The charter says: " The main purpose of the AUTOCONF WG is to describe the addressing model for ad hoc networks [...]. Once this sole work item is completed, the group can be rechartered to work on additional issues." Ulrich On 2/23/10 12:41 PM, Carlos Jesús Bernardos Cano wrote: > Hi, > > It seems that after a very long (and not free of pain sometimes) > process, the WG seems to be close to be done with its currently only one > milestone. > > I guess we now should start working on solution-space, right? If that > is finally the step to go, I'd like to know if the WG thinks that it'd > make sense / be useful to update some of the documents we submitted in > the past about solution space: > > http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 > http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-considerations-03 > > and > > http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 > > I think these documents can help in the solution space discussion. If > people are interested, we can update it taking into account the current > direction of the WG and the addressing-model doc, so they can be used in > the (hopefully) upcoming discussions. > > Thanks, > > Carlos > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From cjbc@it.uc3m.es Tue Feb 23 07:49:31 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C34E428C2D4 for ; Tue, 23 Feb 2010 07:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.525 X-Spam-Level: X-Spam-Status: No, score=-5.525 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyksR6AtzMSf for ; Tue, 23 Feb 2010 07:49:30 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 709F628C2A1 for ; Tue, 23 Feb 2010 07:49:30 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 3535D6C7103; Tue, 23 Feb 2010 16:51:32 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ulrich Herberg In-Reply-To: <4B83D1E8.5000003@herberg.name> References: <1266925311.4036.71.camel@acorde.it.uc3m.es> <4B83D1E8.5000003@herberg.name> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-gZ6Yu90nkomJDXNCCDft" Organization: Universidad Carlos III de Madrid Date: Tue, 23 Feb 2010 16:51:36 +0100 Message-ID: <1266940296.4036.106.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17162.002 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:49:31 -0000 --=-gZ6Yu90nkomJDXNCCDft Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Tue, 2010-02-23 at 14:02 +0100, Ulrich Herberg wrote: > Hi, >=20 > wouldn't we need to recharter first before working on solutions? Absolutely, I'm trying to trigger discussion on potential rechartering. With current charter, we can just sit and wait for the IESG to say something about the addr-model document. Thanks, Carlos >=20 > The charter says: > " The main purpose of the AUTOCONF WG is to describe the addressing > model for ad hoc networks [...]. Once this sole work item is completed, > the group can be rechartered to work on additional issues." >=20 >=20 > Ulrich >=20 >=20 > On 2/23/10 12:41 PM, Carlos Jes=FAs Bernardos Cano wrote: > > Hi, > > > > It seems that after a very long (and not free of pain sometimes) > > process, the WG seems to be close to be done with its currently only on= e > > milestone. > > > > I guess we now should start working on solution-space, right? If that > > is finally the step to go, I'd like to know if the WG thinks that it'd > > make sense / be useful to update some of the documents we submitted in > > the past about solution space: > > > > http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02=20 > > http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-consider= ations-03 > > > > and=20 > > > > http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 > > > > I think these documents can help in the solution space discussion. If > > people are interested, we can update it taking into account the current > > direction of the WG and the addressing-model doc, so they can be used i= n > > the (hopefully) upcoming discussions. > > > > Thanks, > > > > Carlos > > > > =20 > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > =20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-gZ6Yu90nkomJDXNCCDft Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkuD+YcACgkQNdy6TdFwT2di+wCgs/GVDKF+e4Bstea7SvPWghBQ 4u0An1WTL40FsfAo3rFxiw8K/bg5GTBG =drRr -----END PGP SIGNATURE----- --=-gZ6Yu90nkomJDXNCCDft-- From charles.perkins@earthlink.net Tue Feb 23 14:29:02 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6303B28C396 for ; Tue, 23 Feb 2010 14:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjkU5CQXNdCy for ; Tue, 23 Feb 2010 14:29:01 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 8FDB528C391 for ; Tue, 23 Feb 2010 14:29:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=gPBojJF9M02lxSzK3h5d9ozDo67MiMCZ5ksIhIso453xuyOsnZS1AInb2Zh5YM3U; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.14]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Nk3HV-0002yG-75; Tue, 23 Feb 2010 17:31:05 -0500 Message-ID: <4B845726.4070309@earthlink.net> Date: Tue, 23 Feb 2010 14:31:02 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1266925311.4036.71.camel@acorde.it.uc3m.es> In-Reply-To: <1266925311.4036.71.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5268d9c158b9943d7daa030275547cd837350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 22:29:02 -0000 Hello folks, I am definitely in favor of getting into solution space, whether or not it requires rechartering :-). Regards, Charlie P. On 2/23/2010 3:41 AM, Carlos Jesús Bernardos Cano wrote: > Hi, > > It seems that after a very long (and not free of pain sometimes) > process, the WG seems to be close to be done with its currently only one > milestone. > > I guess we now should start working on solution-space, right? If that > is finally the step to go, I'd like to know if the WG thinks that it'd > make sense / be useful to update some of the documents we submitted in > the past about solution space: > > http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 > http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-considerations-03 > > and > > http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 > > I think these documents can help in the solution space discussion. If > people are interested, we can update it taking into account the current > direction of the WG and the addressing-model doc, so they can be used in > the (hopefully) upcoming discussions. > > Thanks, > > Carlos > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From emmanuel.baccelli@gmail.com Fri Feb 26 06:43:37 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E619128C177 for ; Fri, 26 Feb 2010 06:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3dnAyG41e3Z for ; Fri, 26 Feb 2010 06:43:36 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 13AFA28C167 for ; Fri, 26 Feb 2010 06:43:35 -0800 (PST) Received: by ewy7 with SMTP id 7so92354ewy.29 for ; Fri, 26 Feb 2010 06:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to :content-type; bh=fc/oVfLK5t0T+FtBQkUsSDQk/gmCLpMZwCRN2JJ3hg8=; b=he6BvAS5uri3mJLyu2XYLIg2e5SN/FA9Ue4+FP/JaQsOIH7evXS04T9qTayNHrQZ8/ n+wy+lhgNNkHL52XOrq4hDV8MsQCGU4bnjlHjCtL8YQmLRk9E4po0MwabasfU7dvwpaU 0eB97HJ+Lay6K5K6biTK7RpSbeKlmZVqLX7Sw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=XP5Z/TwaQM64/6rJDtMC/8GH1nRJ6u8rN6m15Gbp6yarq1NDcgmAYVm718kWco0EDZ LGQU8QcA22O2Yh3z+eBgT1j0HetJf9yToLiS7NPjAyNrAcWigq8lPZEhvpsaIOokqKwk ZTqS1SLHQHteLUaA7/1wLKwhBvi+ZBW9ET+UE= MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.213.1.151 with SMTP id 23mr184173ebf.34.1267195546285; Fri, 26 Feb 2010 06:45:46 -0800 (PST) In-Reply-To: <4B845726.4070309@earthlink.net> References: <1266925311.4036.71.camel@acorde.it.uc3m.es> <4B845726.4070309@earthlink.net> From: Emmanuel Baccelli Date: Fri, 26 Feb 2010 15:45:26 +0100 X-Google-Sender-Auth: 4ec1e6d8ace1a425 Message-ID: To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=000e0ce029f665b826048081f422 Subject: Re: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 14:43:38 -0000 --000e0ce029f665b826048081f422 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi autoconfers, I'm also longing for solution space... I hope we can do this "officially" soon! In the mean time, as suggested by Carlos, I think it is a good idea t= o start preparing for this next stage. Best regards, Emmanuel On Tue, Feb 23, 2010 at 11:31 PM, Charles E. Perkins < charles.perkins@earthlink.net> wrote: > > Hello folks, > > I am definitely in favor of getting into solution > space, whether or not it requires rechartering :-). > > Regards, > Charlie P. > > > > > On 2/23/2010 3:41 AM, Carlos Jes=FAs Bernardos Cano wrote: > >> Hi, >> >> It seems that after a very long (and not free of pain sometimes) >> process, the WG seems to be close to be done with its currently only one >> milestone. >> >> I guess we now should start working on solution-space, right? If >> that >> is finally the step to go, I'd like to know if the WG thinks that it'd >> make sense / be useful to update some of the documents we submitted in >> the past about solution space: >> >> http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 >> >> http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-considera= tions-03 >> >> and >> >> http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 >> >> I think these documents can help in the solution space discussion. If >> people are interested, we can update it taking into account the current >> direction of the WG and the addressing-model doc, so they can be used in >> the (hopefully) upcoming discussions. >> >> Thanks, >> >> Carlos >> >> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --000e0ce029f665b826048081f422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi autoconfers,

I'm also longing for solution space.= .. I hope we can do this "officially" soon! In the mean time, as = suggested by Carlos, I think it is a good idea to start preparing for this = next stage.

Best regards,
Emmanuel


On Tue, Feb 23, 2010 at 11:31 PM, Charles E. Perkins= <cha= rles.perkins@earthlink.net> wrote:

Hello folks,

I am definitely in favor of getting into solution
space, whether or not it requires rechartering :-).

Regards,
Charlie P.




On 2/23/2010 3:41 AM, Carlos Jes=FAs Bernardos Cano wrote:
Hi,

=A0 =A0 =A0 =A0It seems that after a very long (and not free of pain somet= imes)
process, the WG seems to be close to be done with its currently only one milestone.

=A0 =A0 =A0 =A0I guess we now should start working on solution-space, righ= t? If that
is finally the step to go, I'd like to know if the WG thinks that it= 9;d
make sense / be useful to update some of the documents we submitted in
the past about solution space:

http://tools.ietf.org/html/draft-bernardos-autocon= f-solution-space-02
http://tools.ietf.org/html/draft-bernar= dos-autoconf-evaluation-considerations-03

and

http://tools.ietf.org/html/draft-bernardos-manet-aut= oconf-survey-04

I think these documents can help in the solution space discussion. If
people are interested, we can update it taking into account the current
direction of the WG and the addressing-model doc, so they can be used in the (hopefully) upcoming discussions.

Thanks,

Carlos




_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www.ietf.org/mailman/listinfo/autoconf

--000e0ce029f665b826048081f422-- From alexandru.petrescu@gmail.com Fri Feb 26 12:25:32 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9564328C1EC for ; Fri, 26 Feb 2010 12:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXiVctxZYJMk for ; Fri, 26 Feb 2010 12:25:31 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 59F0F3A855E for ; Fri, 26 Feb 2010 12:25:29 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 144DBD480F7; Fri, 26 Feb 2010 21:27:41 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id F0052D48062; Fri, 26 Feb 2010 21:27:38 +0100 (CET) Message-ID: <4B882EB5.4070605@gmail.com> Date: Fri, 26 Feb 2010 21:27:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: "autoconf@ietf.org" References: <1266925311.4036.71.camel@acorde.it.uc3m.es> In-Reply-To: <1266925311.4036.71.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100226-0, 26/02/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 20:25:32 -0000 Hey Carlos, thanks for triggering the discussion, In the solution space I am interested in the use of link-local addresses and of multicast link-scoped addresses. I hope these are not forbidden by the IPv6 addressing architecture document, which seems to be sent to the IESG now. Alex Le 23/02/2010 12:41, Carlos Jesús Bernardos Cano a écrit : > Hi, > > It seems that after a very long (and not free of pain sometimes) > process, the WG seems to be close to be done with its currently only > one milestone. > > I guess we now should start working on solution-space, right? If > that is finally the step to go, I'd like to know if the WG thinks > that it'd make sense / be useful to update some of the documents we > submitted in the past about solution space: > > http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 > > http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-considerations-03 > > and > > http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 > > I think these documents can help in the solution space discussion. > If people are interested, we can update it taking into account the > current direction of the WG and the addressing-model doc, so they can > be used in the (hopefully) upcoming discussions. > > Thanks, > > Carlos > > > > > _______________________________________________ Autoconf mailing > list Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From ryuji.wakikawa@gmail.com Fri Feb 26 13:34:18 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71EDC28C150 for ; Fri, 26 Feb 2010 13:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAzNrM3LdnF9 for ; Fri, 26 Feb 2010 13:34:17 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 93E613A8849 for ; Fri, 26 Feb 2010 13:34:17 -0800 (PST) Received: by vws20 with SMTP id 20so217557vws.31 for ; Fri, 26 Feb 2010 13:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=fBKfwTpurK6w847vMkPgG4qHQoBX2fkfl16H0HJpduc=; b=HbuMKGpCVjr3K6+hlQ3QhnZKA0yWge78t+d6Uh9rYpmn1PF0OIzwmaHph4f4RSK7Up 1j3++9nB+gSWxxqOmtYcvHOQcX1cfPqpXqtdGfy4IOuRDo5jofLrP0hYRqmcyR/I8oV3 T1cQUudnPpM+Ken1Vp3SclifF/0pdZqLsxIc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=AZpNV4aMN1q50c9NkIZvg0UPw8ZcVuVOxrWzVhKP7EHOMN0RDYb9CeJMTANkgzx3lC Zoc+g4vqsE6019qIWVdYSFmWW7QuTr11am5bKyz4wmnB+BDbp6QiPSVi77RgWmlqoxwa nVPFFW2vHs4jJwmCFPxIZkexNjvaehLpl5z6Q= Received: by 10.220.107.17 with SMTP id z17mr630272vco.195.1267220189324; Fri, 26 Feb 2010 13:36:29 -0800 (PST) Received: from ?10.10.13.38? ([66.114.246.14]) by mx.google.com with ESMTPS id 22sm4036074vws.14.2010.02.26.13.36.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Feb 2010 13:36:27 -0800 (PST) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2010 13:35:57 -0800 Message-Id: To: autoconf@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Autoconf] Friday 0900-1130 meeting at Anaheim X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 21:34:18 -0000 Hi all, We have 2.5 hours at the 77 meeting and plan to discuss our next step = including rechartering. Thomas and I have discussed the next steps right now and will start = discussion on this list. I saw several folks showed their interests to the solution space.=20 https://datatracker.ietf.org/meeting/77/agenda.html thanks. ryuji= From charles.perkins@earthlink.net Fri Feb 26 15:05:53 2010 Return-Path: X-Original-To: autoconf@core3.amsl.com Delivered-To: autoconf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6231B3A82B0 for ; Fri, 26 Feb 2010 15:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYMpJPRUhjNq for ; Fri, 26 Feb 2010 15:05:52 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 888983A74B6 for ; Fri, 26 Feb 2010 15:05:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=dqs+5oywOHh/GjwoTlJM7b1WSw+I7OpYWVyHTXKS88oH75T8gFIRQ28Qt0MJkfgR; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.150]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Nl9I0-0003Fl-I1; Fri, 26 Feb 2010 18:08:08 -0500 Message-ID: <4B885457.80203@earthlink.net> Date: Fri, 26 Feb 2010 15:08:07 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Alexandru Petrescu References: <1266925311.4036.71.camel@acorde.it.uc3m.es> <4B882EB5.4070605@gmail.com> In-Reply-To: <4B882EB5.4070605@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d23581bfbb8ebcef0b23592697ef5cf0350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Next steps? X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 23:05:53 -0000 Hello Alex, Do you have drafts about how to perform autoconfiguration using those techniques? Regards, Charlie P. On 2/26/2010 12:27 PM, Alexandru Petrescu wrote: > Hey Carlos, thanks for triggering the discussion, > > In the solution space I am interested in the use of link-local addresses > and of multicast link-scoped addresses. > > I hope these are not forbidden by the IPv6 addressing architecture > document, which seems to be sent to the IESG now. > > Alex > > Le 23/02/2010 12:41, Carlos Jesús Bernardos Cano a écrit : >> Hi, >> >> It seems that after a very long (and not free of pain sometimes) >> process, the WG seems to be close to be done with its currently only >> one milestone. >> >> I guess we now should start working on solution-space, right? If >> that is finally the step to go, I'd like to know if the WG thinks >> that it'd make sense / be useful to update some of the documents we >> submitted in the past about solution space: >> >> http://tools.ietf.org/html/draft-bernardos-autoconf-solution-space-02 >> >> > http://tools.ietf.org/html/draft-bernardos-autoconf-evaluation-considerations-03 > >> >> and >> >> http://tools.ietf.org/html/draft-bernardos-manet-autoconf-survey-04 >> >> I think these documents can help in the solution space discussion. >> If people are interested, we can update it taking into account the >> current direction of the WG and the addressing-model doc, so they can >> be used in the (hopefully) upcoming discussions. >> >> Thanks, >> >> Carlos >> >> >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >