Subject: [Gen-art] review of draft-ietf-nemo-terminology-06.txt

From: Francis Dupont <[email-masked]>
Date: Sat, 02 Dec 2006 18:51:21 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

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).

Regards

[email-masked]

PS: as the document is informational I don't know if a LC is planned for it.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Mon, 04 Dec 2006 17:27:22 +0200

Thanks for your review! No, there is no LC planned
for this document. In fact, we already dealt with it
in the IESG, and uncovered one technical issue that
needs to be addressed.

I would ask the chairs to look into these issues
and list changes, if any, so that I can take them
into account in the RFC Editor notes. For the
most part I believe the RFC Editor can deal with
the editorial stuff (and I can make them aware
of these comments), so focus on the technical
stuff.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Thu, 07 Dec 2006 19:33:48 +0100

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.

   >>   the wording should be a bit clearer, for instance with an "either"
   
   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)."
                                   ^^^^^^

   >>   can be more complex about the prefix delegation and/or with
   
   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.

   >>   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
   
   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.

   >>   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

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 7 Dec 2006 15:01:32 +0100

Hi,

OK, I'm commenting on the technical issues:

>>   are on the same mobile network (!= fixFrom [email-masked] Fri Dec 08 03:48:28 2006
Date: Thu, 7 Dec 2006 15:01:32 +0100
From: Thierry Ernst <[email-masked]>
To: Jari Arkko <[email-masked]>
Organization: INRIA
Cc: [email-masked], [email-masked], [email-masked]
Subject: [Gen-art] Re: review of draft-ietf-nemo-terminology-06.txt

Hi,

>>   are on the same mobile network (!= fixed or *another* mobile).

No, it's not the intention.

The definitions reads:

obtain an address on the parent NEMO. However, the child NEMO can also

>>   "subservient". Is there a good reason to avoid child-NEMO/child-MR

I cannot recall the exact discussion - it is somewhere in the archives -
the term "subservient" was proposed by Erik Nordmark. Since the visiting
NEMO obtains an address and an access from the parent, we conclude the
term "subservient" would be a better catch.

I
>> proposed (cf. IESG evaluation comment logs in the tracker).

There will always be collisions with other abbreviations, and we are
aware of this (the RO design team had a long discussion on this). But
here, the context between "Correspondent Entity" and "Customer
Equipment" is not the same, so I don't consider this as a problem. In
addition, consistency with other NEMO terms, and other NEMO documents is
important. The term CE is used in draft-ietf-nemo-ro-problem-statement
which is already approved by the IESG.

Thanks for the comments, Francis.

Thierry.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.ed or *another* mobile).
>>   Is it the intention?

No, it's not the intention.

The definitions reads:

obtain an address on the parent NEMO. However, the child NEMO can also

>>   "subservient". Is there a good reason to avoid child-NEMO/child-MR

I cannot recall the exact discussion - it is somewhere in the archives -
the term "subservient" was proposed by Erik Nordmark. Since the visiting
NEMO obtains an address and an access from the parent, we conclude the
term "subservient" would be a better catch.

I
>> proposed (cf. IESG evaluation comment logs in the tracker).

There will always be collisions with other abbreviations, and we are
aware of this (the RO design team had a long discussion on this). But
here, the context between "Correspondent Entity" and "Customer
Equipment" is not the same, so I don't consider this as a problem. In
addition, consistency with other NEMO terms, and other NEMO documents is
important. The term CE is used in draft-ietf-nemo-ro-problem-statement
which is already approved by the IESG.

Thanks for the comments, Francis.

Thierry.

---

From: Hong-Yon Lach <[email-masked]>
Date: Fri, 08 Dec 2006 09:25:38 +0100

Salut Francis,

Thanks for your review and please see my comments inline...

Cheers,
Hong-Yon

> From: Francis Dupont <[email-masked]>
> Date: Thu, 07 Dec 2006 19:33:48 +0100
> To: Thierry Ernst <[email-masked]>
> Cc: Jari Arkko <[email-masked]>, <[email-masked]>,
> <[email-masked]>, Hong-Yon Lach <[email-masked]>
> Subject: Re: review of draft-ietf-nemo-terminology-06.txt
> 
> => hum, IMHO the best is torg/mailman/listinfo/gen-art

---

From: Hong-Yon Lach <[email-masked]>
Date: Fri, 08 Dec 2006 09:25:38 +0100

Salut Francis,

Cheers,
Hong-Yon

> fixed node (LFN) or a mobile node (either VMN or LMN)."
[HYL] I think your suggestion is fine. I would put "either" after "be" so
that it reads:
"A Mobile Network Node may be either a fixed node (LFN) or a mobile node
(either VMN or LMN)."

> => spanning tree is the standard way to extract a tree from a random
[HYL] I think the purpose of the clause is to highlight the nesting of MR
and the potential issues. As this draft is not suggesting any solution, if
"spanning tree" is to be referred to, we need to mention it as a potential
way to resolve the "loop". Otherwise, don't you think it is sufficient to
just highlight the nature of nesting of MRs?

o add an "either" before VMN in 2.7,
> fixed node (LFN) or a mobile node (either VMN or LMN)."
[HYL] I think your suggestion is fine. I would put "either" after "be" so
that it reads:
"A Mobile Network Node may be either a fixed node (LFN) or a mobile node
(either VMN or LMN)."

> => spanning tree is the standard way to extract a tree from a random
[HYL] I think the purpose of the clause is to highlight the nesting of MR
and the potential issues. As this draft is not suggesting any solution, if
"spanning tree" is to be referred to, we need to mention it as a potential
way to resolve the "loop". Otherwise, don't you think it is sufficient to
just highlight the nature of nesting of MRs?