In your previous mail you wrote:
The definitions reads:
2.8. Correspondent Node (CN)
Any node that is communicating with one or more MNNs. A CN could be
either located within a fixed network or within another mobile network,
and could be either fixed or mobile.
So, we should just replace the word "another" with "a" in front of
"mobile network".
=> fine.
>> - in 3 page 9: some sort -> some kind?
>> - in 3* pages 9 and 10: LFN, VMN and LMN are a partition of MNN. IMHO
>> the wording should be a bit clearer, for instance with an "either"
>> .. "or"
>> construct?
Would you clarify which is the sentence that should be clarified ?
Please also not that the term "MNN: is defined in 2.7, so that
definition by itself might be enough to clarify your concern ?
=> hum, IMHO the best is to add an "either" before VMN in 2.7,
i.e., put "A Mobile Network Node may either be a
fixed node (LFN) or a mobile node (either VMN or LMN)."
^^^^^^
>> - in 4.1 page 11 (technical): there is no reason that the topology is a
>> tree so the wording must be changed in order to explain how we can get
>> a hierarchy from any interconnection graph. For this point IMHO the
>> magic
>> words are "spanning tree" with the Internet as the root but things
>> can be more complex about the prefix delegation and/or with
>> multi-homing.
The reason why this could become a tree is that the visiting MR must
obtain an address on the parent NEMO.
^^^
=> the issue is about this "the": I have no concern to have a constraint
on considered topologies but this should be explicitely stated.
However, the child NEMO can also
be a parent NEMO over another path (says that a MNN in a sub-NEMO is
an AR adversiting a prefix, so the MR from the parent-NEMO may get an
address from the sub-NEMO. So, nested topologies could become very
complex, and would bring some interesting issues. This could bring
loops, but it is not the intention to discuss this in this document.
I'm not sure the term "spanning tree" would fit in here.
=> spanning tree is the standard way to extract a tree from a random
graph.
>> - in 5.1 page 13, 5.3 page 14, 5.4 page 14: "either" is for exclusive or
>> and is used in situations where a standard inclusive or is better.
OK, we should just remove the word "either" if in English it has a
definite exclusive meaning (I leave that to the RFC editor, then).
=> I agree: arguable language points should be handled by the RFC editor!
>> - in 7.4 page 19: the word "necessary" is far too strong and surely not
>> necessary...
Well, from a usage and deployment point of view, everyone agree that
optimizations are necessary. The reason why the solution is not optimzed
yet is "security" as you know. So, optimizations are necessary from a
performance point of view, but it's not clear yet if this would
compromise security, in which case optimizations may not be provided.
Anyway, I propose to change "necessary" with "performance".
=> fine.
>> - in authors' addresses page 25: please use the French (and only correct
>> in these cases) position for the postal code (aka zip code) which is
>> supposed to have only a local (here pour nous) meaning.
This is an xml issue. The RFC editor will make sure that the address is
"78153 Le Chesnay" and not the other way round.
=> IMHO "code" should not be used for French postal addresses...
(I use the "city" for the whole line)
Thanks
[EMAIL PROTECTED]
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
