[Gen-art] Re: review of draft-ietf-nemo-terminology-06.txt
Hi, 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. OK, I'm commenting on the technical issues: Francis Dupont kirjoitti: 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? No, it's not the intention. 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. - 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 ? - 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. 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. - 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? 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. - 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). - 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. - 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. I Not my comment: in
[Gen-art] Re: review of draft-ietf-nemo-terminology-06.txt
Salut Francis, Thanks for your review and please see my comments inline... Cheers, Hong-Yon From: Francis Dupont [EMAIL PROTECTED] Date: Thu, 07 Dec 2006 19:33:48 +0100 To: Thierry Ernst [EMAIL PROTECTED] Cc: Jari Arkko [EMAIL PROTECTED], [EMAIL PROTECTED], gen-art@ietf.org, Hong-Yon Lach [EMAIL PROTECTED] Subject: Re: review of draft-ietf-nemo-terminology-06.txt 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). ^^ [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). - 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. [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? - 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
[Gen-art] Re: review of draft-ietf-nemo-terminology-06.txt
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
