Document: draft-ietf-nemo-terminology-06.txt
Reviewer: Francis Dupont
Review Date:  2006/12/1
IETF LC End Date: 
IESG Telechat date: 2006/11/30

Summary: Ready with nits

Comments: I have many comments about language/wording, some have
a technical impact but none is really critical:
 - in 1 page 4, 3.2 page 10, 4 page 11 (twice), 5.1 page 13 (twice),
  5.2 page 13: e.g. or i.e. are not followed by a comma.
 - in 2 page 5, page 6 (twice), 2.1 page 7, 2.2 page 7 (twice), 6.8 page
  18: the word subnetwork should be used in place of subnet in text
  (I propose to keep the abbrev in figures but to use the full term in text).
 - in 2 page 6 (technical): from the Access Router -> from an Access Router.
 - in 2 page 6, 2.3 page 7 (always twice): IMHO "one or more" introduces
  a plural (ask the RFC editor to fix this).
 - in 2.8 page 8 (technical): the wording seems to exclude CNs which
  are on the same mobile network (!= fixed or *another* mobile).
  Is it the intention?
 - 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?
 - 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.
 - in 4.4/4.7 pages 11/12: the opposite of "parent" is "child", not
  "subservient". Is there a good reason to avoid child-NEMO/child-MR terms?
 - 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.
 - in 7.4 page 19: the word "necessary" is far too strong and surely not
   necessary...
 - 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.
Not my comment: in 2.10 page 8: the abbrev CE (Correspondent Entity)
collides with already heavily used CE (Customer Equipment). CNR was
proposed (cf. IESG evaluation comment logs in the tracker).