[Gen-art] (re)review of draft-ietf-rohc-rfc3095bis-framework-04.txt

[Francis Dupont]

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-rohc-rfc3095bis-framework-04.txt
Reviewer: Francis Dupont 
Review Date: 2006-12-08
IETF LC End Date: 2006-11-28


IESG Telechat date: 2006-12-14

Summary: Ready

Comments: none (it is a rereview of a document which was already ready).

Regards

[EMAIL PROTECTED]

___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] Re: Review Assignment: draft-ietf-bmwg-hash-stuffing-07.txt

[Joel M. Halpern]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

This document is almost ready for publication as an Informational 
RFC.  There is one item that should be fixed before publications, and 
several items that should be changed given that a respin is needed anyway.


Yours,
Joel M. Halpern

Moderate:
1)  In the MPLS recommendation, it is recommended that labels be 
uniformly distributed between 0 and 2^20.  Given that the labels 
0-15  are reserved for special function, and often have special 
processing or discarding, it strikes me that test equipment may well 
get unexpected results if it randomly attempts to use those for 
normal operations.  I would recommend checking the the MPLS standards 
as to the current reserved range, and making sure the random 
assignment stays out of that.


Minor:
IDNits alerted the fact that the IPv4 address used as 
samples in Appendix C are not RFC 3330 documentation values 
(192.0.2.0/24).  Similarly, the IPv6 example does not use the IPv6 
documentation block assigned by RFC 3849 (2001:DB8::/32)
In section 4.2, in describing how to create the MAC address, 
the upper byte is anded with 0xFC to clear the global/local and 
unicast/multicast bit so that the address will be a global 
multicast.  there are two minor issues here:
Using a global MAC address construct from a random number and a 
port number is probably appropriate, but violates the standard.  It 
would probably be a good idea to acknowledge this fact, and explain 
why global (rather than local) addresses need to be used.
The text refers to the two bits that are being controlled as the 
"high order two bits of taht byte."  While those are the first two 
bits that will be clocked out over the ethernet, they are not the 
"high order" bits in most peoples understanding of the term.



OPS Hash and Stuffing: Overlooked Factors in Network Device 
Benchmarking (Informational)

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-hash-stuffing-07.txt

AD: David Kessens
Reviewer: Joel Halpern


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art

[Gen-art] GEN-ART Review ofdraft-ietf-radext-delegated-prefix-05.txt

[Spencer Dawkins]

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-radext-delegated-prefix-05.txt
Reviewer: Spencer Dawkins
Review Date: 8 December 2006
IESG Telechat date: 14 December 2006

Summary: This document is ready for publication as a Proposed Standard.

Comments: All of my Last Call comments for 01 have been addressed (thanks!), 
and the changes since 05 seem reasonable - no new comments found.



Hi, Joe and Ralph,

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
.


Summary - this draft is almost ready for publication as a Proposed 
Standard. It is short, and clearly written.


I have four observations - there may be DHCP conventions I don't know 
about, but this is how things look to me.


- The relationship between "Length" and "Prefix-Length" seems 
underspecified. If what you are saying is


  Length - the length of the entire attribute, in bytes. At least 4 (to 
hold Type/Length/Reserved/Prefix-Length for a 0-bit prefix), and no larger 
than 20 (to hold Type/Length/Reserved/Prefix-Length for a 128-bit prefix)


 Prefix-Length - the length of the prefix being delegated, in bits. At 
least 0 and no larger than 128 bits (identifying a single IPv6 address).


I'm guessing, and if you are actually saying something else, I don't know 
what it could be :-)


- Does "Reserved - Always set to zero" ever get validated as zero by a 
receiver?


- I completely missed the three-line, two-row "table" at the end of 
Section 3. If you could at least indent it, and maybe even draw ASCII 
boxes around it, the specification would be much easier to grok.


- It would also be nice to have a pointer to a reference for the 
definition of "Framed-IPv6-Prefix" in Section 3, but that's extremely 
minor.


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


Thanks,

Spencer Dawkins


___
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art





___
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

[Hong-Yon Lach]

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

[Thierry Ernst]

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 p