[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