Re: [Autoconf] Comments on draft-ietf-autoconf-statement-02.txt

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Emmanuel,

	See below...

El mié, 21-11-2007 a las 10:42 +0100, Emmanuel Baccelli escribió:
> Hi Cralos thanks for your feedback,
> 
> Carlos Jesús Bernardos Cano a écrit :
> > 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.
> > 
> 
> OK, I agree. Maybe a more precise way would be to say instead that a 
> connected MANET can reach an ICP?

	That's a possibility, although I'm not 100% convinced about current ICP
definition (as Simone also comments). I have to think more about it
before providing a suggestion...

> 
> > 	- "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).
> 
> Agreed.
> 
> > 
> > 	- (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 ...).
> > 
> 
> I see what you mean. How about replacing the word "assignment" by 
> "(re)assignment"?

	I'll address this in my reply to Simone's mail.

> 
> > 	- (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?
> > 
> 
> Agreed. I guess the order was more intended to be 
> partitionning=>merging=>problems ;) But it may be clearer to just talk 
> about merging here.
> 
> > 	- (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...).
> 
> You are right. This is a typo that eluded me.
> 
> > 
> > 	- (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.
> > 
> 
> We agree that low control overhead is a generic requirement. If you see 
> other generic requirements that are missing here, please tell us and it 
> will be mentionned in this section.

	I'll also address this in my reply to Simone's mail.

	Regards,

	Carlos

> 
> Emmanuel
> 
> 
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/autoconf
-- 
¡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
[e-mail]
https://www1.ietf.org/mailman/listinfo/autoconf