[Autoconf] Comments on draft-ietf-autoconf-statement-02.txt
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Wed, 21 November 2007 00:25 UTC
Return-path: <autoconf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudOs-0000AD-Sn; Tue, 20 Nov 2007 19:25:06 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IudOr-0008Ry-Pm for autoconf-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 19:25:05 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IudOr-0008Lg-9P for autoconf@ietf.org; Tue, 20 Nov 2007 19:25:05 -0500
Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IudOq-0003ac-BG for autoconf@ietf.org; Tue, 20 Nov 2007 19:25:04 -0500
Received: from [192.168.0.4] (82.159.23.147.dyn.user.ono.com [82.159.23.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id CD63F23CF20 for <autoconf@ietf.org>; Wed, 21 Nov 2007 01:25:02 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: autoconf@ietf.org
Organization: Universidad Carlos III de Madrid
Date: Wed, 21 Nov 2007 01:24:47 +0100
Message-Id: <1195604687.5119.43.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Subject: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1447016919=="
Errors-To: autoconf-bounces@ietf.org
Hi all, Thanks for the new version of the draft. Some comments below (I hope I don't repeat any already brought on the ML): - "Connected MANET - A mobile ad hoc network, which contains at least one ICP." --> I'm not sure a connected MANET should necessarily contain one ICP, at least as I understand what an ICP is. As I see it, an ICP can be -- going to solution space -- a DHCP server in the infrastructure (and therefore not _contained_ in the MANET). Maybe it's just myself not reading the definition properly. - "Another example of such a scenario is coverage extension of a fixed wide-area wireless network, where one or more mobile routers in the MANET are connected to the Internet through technologies such as UMTS or WiMAX." --> I think the term mobile router may lead to confusion, I'd prefer MANET router, since mobile router is usually related to NEMO (RFC 3963). - (Section 4.1.2 Dynamic Topology Support) "Moreover, possible frequent reconfiguration due to intermittent reachability cause [5] to be less efficient than expected, due to large amounts of control signalling." --> I think I'm missing something here, can [5] (RFC 4862) be used in a multihop environment? I don't clearly the comment on [5] and dynamic topology. - (Section 4.1.3 Network Merging Support) "For instance, [5] and [3] test address uniqueness via messages that are sent to neighbors only, and as such cannot detect the presence of duplicate addresses configured within the network but located several hops away. However, since MANETs are generally multi-hop, detection of duplicate addresses over several hops is a feature that may be required for MANET interface address assignment (see Section 4.2.2)." --> Again, I think I'm missing something here, I see network merging has more to do with the in-service uniqueness requirement that with the multi-hop nature (of course, everything is related ...). - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "Phenomena such as MANET merging and MANET partitioning may bring the need for checking the uniqueness (within the specified scope) of addresses or prefixes that are already assigned and used." --> I'd remove "and MANET partitioning", since IMHO only merging may produce duplicates, right? - (Section 4.2.2 Prefix and Address Uniqueness Requirements) "For instance, if (i) is extremely low and (ii) significant, then checking pre-service uniqueness of addresses and prefixes may not be used." --> shouldn't it say ... checking in-service uniqueness of addresses ...? I thought pre-service is assumed to be always required to avoid duplicate addresses when a MANET router joins the network (and therefore avoid routing problems, etc...). - (Section 5 Solutions Considerations) "Solutions must achieve their task with (i) low overhead, due to scarse bandwidth, and (ii) low delay/convergence time, due to the dynamicity of the topology." --> Are we assuming always "scarse bandwidth"? IMHO this is scenario-specific, and although I agree on the requirement of low overhead in general, how important this issue is depends on the particular scenario. IMHO, Section 5 as it is now does not really fulfils the goal of providing solutions considerations. I really think that performing such an analysis without going more deeply into the details (such as in draft-bernardos-autoconf-evaluation-considerations-01.txt) is very hard. As I see it (this is my personal view on that), either we extend this section or we remove it. Hope these comments help. Kind Regards, Carlos J. -- ¡ASÓCIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jesús Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67
_______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf
- [Autoconf] Comments on draft-ietf-autoconf-statem… Carlos Jesús Bernardos Cano
- Re: [Autoconf] Comments on draft-ietf-autoconf-st… Emmanuel Baccelli
- Re: [Autoconf] Comments on draft-ietf-autoconf-st… Simone Ruffino
- Re: [Autoconf] Comments on draft-ietf-autoconf-st… Carlos Jesús Bernardos Cano
- Re: [Autoconf] Comments on draft-ietf-autoconf-st… Carlos Jesús Bernardos Cano
- Re: [Autoconf] Comments on draft-ietf-autoconf-st… Alexandru Petrescu
- Re: [Autoconf] Comments on draft-ietf-autoconf-st… Carlos Jesús Bernardos Cano