Re: [Autoconf] Autoconf addressing model
Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 04 March 2009 10:13 UTC
Return-Path: <alexandru.petrescu@gmail.com>
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 64BBD3A6AA4 for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 02:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level:
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078, 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 M4xO3WRRjSxC for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 02:13:54 -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 879533A689E for <autoconf@ietf.org>; Wed, 4 Mar 2009 02:12:48 -0800 (PST)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n24ADGwb004766; Wed, 4 Mar 2009 11:13:16 +0100
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n24ADFZQ001055; Wed, 4 Mar 2009 11:13:15 +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 n24ADEcQ027188; Wed, 4 Mar 2009 11:13:15 +0100
Message-ID: <49AE543A.8020602@gmail.com>
Date: Wed, 04 Mar 2009 11:13:14 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000b01c99c48$3a34ffa0$ae9efee0$@nl> <49ADB1CC.4000704@gmail.com> <000e01c99c5b$c16e2d30$444a8790$@nl>
In-Reply-To: <000e01c99c5b$c16e2d30$444a8790$@nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Autoconf addressing model
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Mar 2009 10:13:55 -0000
Teco Boot a écrit : > I'll think more on Internet access. Teco, when I mentioned default routes I didn't think Internet access. I think default routes are good for networks disconnected from the Internet too. > The diagrams were meant for MANET intra topology. I would not use > private addresses for this. For IPv4, all link addresses could be LL > also (169.254.0.0/16). YEs, I think for IPv4 the LL addresses could be 169.254. > On names in the tables: assume (m)DNS, with A, B and C resolved by it. OK? Ok if you wish so, with the caveat that DNS does not hold their prefix lengths whereas the routing tables do and the prefix lengths are important in the hits. > On metrics / costs, pick the term you like. I am assuming nothing, I use the > term metric where others use cost (or mixed usage, as below in the diagrams > / text). Sample below uses metric where I would use hopcount. > > I just play a bit with some protocols on some platforms. Here a (part off a) > routing table snapshot from one of the toys (OLSRv1 adjusted with ETX and > Link Costs): > > OLSR Routes in Kernel Is this the kernel routing table? Or OLSR's routing table? I believe it's OLSR, not vanilla kernel, because there are two fields 'Metric' and 'Cost' whereas the vanilla kernel only has 'Metric'. > Destination Gateway Metric Cost Interface > 10.128.12.0/24 169.254.1.12 1 725.000 ath0 > 10.128.13.0/24 169.254.1.13 1 630.303 ath0 > 10.128.14.0/24 169.254.1.14 1 622.727 ath0 > 10.128.15.0/24 169.254.1.15 1 671.429 ath0 > 10.128.16.0/24 169.254.1.16 1 973.594 ath0 > 10.128.17.0/24 169.254.1.17 1 749.285 ath0 > 10.128.18.0/24 169.254.1.18 1 766.667 ath0 > 10.128.19.0/24 169.254.1.19 1 663.244 ath0 > 10.128.20.0/24 169.254.1.20 1 958.831 ath0 > 10.128.21.0/24 169.254.1.16 2 1853.594 ath0 > 10.128.22.0/24 169.254.1.16 2 1754.594 ath0 > 10.128.23.0/24 169.254.1.16 2 1836.594 ath0 > 10.128.24.0/24 169.254.1.16 2 1662.594 ath0 > 10.128.25.0/24 169.254.1.16 2 1939.594 ath0 > 10.128.26.0/24 169.254.1.26 1 637.633 ath0 > 10.128.27.0/24 169.254.1.27 1 629.622 ath0 > 10.128.28.0/24 169.254.1.28 1 710.918 ath0 > 10.128.29.0/24 169.254.1.29 1 737.511 ath0 > 10.128.30.0/24 169.254.1.30 1 817.725 ath0 For my clarification: this table doesn't contain host-based routes, we agree. Also: are all the addresses 169.254.1.12-30 neighbors of the ath0 interface? What is/are the addresses assigned on ath0 of this node? What is the subnet address of the subnet on which ath0 is connected? If we have that then I could picture the topoology you're using, and draw subnet addresses and routing tables. > Metrics and cost do not have a need to be "published" in the kernel RT. > > On this toy, LL are multihop reachable (bad behavior !!): > > 169.254.1.21 169.254.1.16 2 1853.594 ath0 > 169.254.1.22 169.254.1.16 2 1754.594 ath0 Right! (LL addresses should be neighbors, not Metric 2.) Thanks for the routing table dump. Alex > > Teco. > > > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: dinsdag 3 maart 2009 23:40 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: Autoconf addressing model > | > |Teco, I'm happy you updated the obstacles scenario. That's important > |insight on what movement may actually be. > | > |I'd go further include default routes in the tables, and specific > |addresses like 10.1.1.1/32 instead of A, and subnet prefixes 10.1.1.0/24 > |for example. > | > |Sorry just asking about this: the Cost in the routing tables. The > |kernel routing tables don't have variable Cost, they're all metric 1 I > |believe (all next-hops are 1-hop away). The routing protocols' tables > |may have Cost and other variables. > | > |Did you assume a routing protocol? > | > |My preference is to not assume any routing protocol. > | > |Alex > | > |Teco Boot a écrit : > |> Hi Alex, > |> > |> I included wrong routing table info in the "obstacles" scenarios. > |> Here a full set of diagrams with routing table info. > |> > |> I removed "STA-", now the model applies to non-802.11 topologies as > |well. > |> > |> Teco. > |> > |> > |> > |> > |> 1. MANET topology with moving and blocking obstacle > |> > |> +------------------------+ +------------------------+ > |> | | | | > |> | ______B | | ______B | > |> | ___/ | | | ___/ | > |> | A | | | A OBSTACLE | > |> | '--_ | | | '--_ | > |> | '------C | | '------C | > |> | OBSTACLE | | | > |> +------------------------+ +------------------------+ > |> 1-1: Full connected 1-2: B-C via A > |> > |> +------------------------+ +------------------------+ > |> | | | O | > |> | ______B | | B B | > |> | ___/ | | | S | | > |> | A OB | | | A T | | > |> | ST | | | A | | > |> | AC C | | C C | > |> | LE | | L | > |> | | | E | > |> +------------------------+ +------------------------+ > |> 1-3: A-C via B 1-4: A-B and A-C blocked > |> > |> > |> The routing tables for the MANET Routers look as follows: > |> > |> ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | B | B | 1 | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | A | A | 1 | > |> | | C | C | 1 | | | C | A | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | A | 1 | | C | A | A | 1 | > |> | | B | B | 1 | | | B | B | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 1-1: All single hop 1-2: B-C degraded > |> > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | | | | > |> | | C | B | 2 | | | | | | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | | | | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | B | 2 | | C | | | | > |> | | B | B | 1 | | | B | B | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 1-3: A-C degraded 1-4: A-B and A-C blocked > |> > |> > |> > |> 2. MANET topology with moving and degrading obstacle > |> > |> In these scenarios, link metrics are introduced. > |> > |> +------------------------+ +------------------------+ > |> | | | | > |> | _______B | | ______B | > |> | __/ 1 | | | __/ 1 . | > |> | A | 1 | | A obstacle | > |> | '--_ 1 | | | '--_ 1 . 5 | > |> | '------C | | '------C | > |> | obstacle | | | > |> +------------------------+ +------------------------+ > |> 2-1: No hindrance 2-2: B-C degraded > |> > |> +------------------------+ +------------------------+ > |> | | | o | > |> | ______B | | 5 b .....B | > |> | ___/ 1 | | | ...s. | | > |> | A ob | 1 | | A t | 1 | > |> | ... st | | | ...a. | | > |> | 5 .ac.... C | | 5 c .....C | > |> | le | | l | > |> | | | e | > |> +------------------------+ +------------------------+ > |> 2-3: A-C degraded 2-4: A-B and A-C degraded > |> > |> > |> The routing tables: > |> > |> ROUTER DEST NEXTHOP COST ROUTER DEST NEXTHOP COST > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | B | B | 1 | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | A | A | 1 | > |> | | C | C | 1 | | | C | A | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | A | 1 | | C | A | A | 1 | > |> | | B | B | 1 | | | B | A | 2 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 2-1: No hindrance 2-2: B-C degraded > |> > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | A | B | B | 1 | | A | B | B | 5 | > |> | | C | B | 2 | | | C | C | 5 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | B | A | A | 1 | | B | A | A | 5 | > |> | | C | C | 1 | | | C | C | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> | C | A | B | 2 | | C | A | A | 5 | > |> | | B | B | 1 | | | B | B | 1 | > |> +-------+-------+-------+----+ +-------+-------+-------+----+ > |> 2-3: A-C degraded 2-4: A-B and A-C degraded > |> > |> In this scenario, the most optimal paths are used, a 2-hop path > |with > |> metric 2 is used instead of a single hop path with metric 5. > |> > |> > |> > |> 3. MANET topology with degrading obstacle and noise > |> > |> In this scenario, C can hear A through an obstacle as scenario 2- > |3, > |> but A reception of B and C is affected by high level "NOISE" (3.1) > |> or low level "noise" (3-2). With high level noise, A cannot hear C > |and > |> the link is "uni-directional". > |> > |> Term "asymmetric" is used to indicate unbalanced metrics for the > |> direction > |> of traffic between two nodes. In other documents, "asymmetric" is > |used > |> for > |> what is called "uni-directional" here. > |> > |> > |> +------------------------+ +------------------------+ > |> | | | | > |> | ____1_B | | ____1_B | > |> | 3__/ | | | 2__/ | | > |> | A ob | 1 | | A ob | 1 | > |> | NOISE st | | | noise ... st | | > |> | x.ac.>..C | | 10 .ac....C | > |> | le | | le 5 | > |> +------------------------+ +------------------------+ > |> 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric > |> A-B asymmetric > |> > |> > |> ROUTER DEST NEXTHOP METRIC ROUTER DEST NEXTHOP METRIC > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> | A | B | B | 3 | | A | B | B | 2 > || > |> | | C | B | 4 | | | C | B | 3 > || > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> | B | A | A | 1 | | B | A | A | 1 > || > |> | | C | C | 1 | | | C | C | 1 > || > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> | C | A | B | 2 | | C | A | B | 2 > || > |> | | B | B | 1 | | | B | B | 1 > || > |> +-------+-------+-------+------+ +-------+-------+-------+------ > |+ > |> 3-1: A-C uni-directional 3-2: A-C & B-C asymmetric > |> A-B asymmetric > |> > |> When the noise level near station A is intermitting between high > |and low > |> levels, this does not influence the routing topology, as the MANET > |> protocol > |> has selected path A-B-C between the routers A and C, because better > |> metrics > |> and bidirectional validation. > |> The MANET Routing Protocol checks directionality of links before > |using > |> these. > |> > |> > |> > |> > |> > >
- Re: [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Paul Lambert
- [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Charles E. Perkins
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] practical addressing Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] radio neighbors in range Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Rex Buddenberg
- Re: [Autoconf] practical addressing Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] radio neighbors in range Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Joe Macker
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] radio neighbors in range Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Teco Boot