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-hip-mm-05.txt
Reviewer: Francis Dupont
Review Date: 03 April 2007
IESG Telechat date: 05 April 2007
Summary: Not Ready
Comments:
- as I wrote in the summary message, IMHO the abstract needs a
full rewrite
- in 5.4 page 31, I have a real concern with "the new SPI value
SHOULD be random" because IPsec people took a real care to
*never* put such a constraint on SPI values. I simply propose
to not specify how to choose a new SPI value (out of the reserved
range of course)
- I believe the reference [3] (Rendez vous) should be made not
normative. Perhaps the introduction wording needs to be adapted
(I don't believe so but you should check with your AD)
(minor points)
- abstract page 2, intro page 4, 3.2.3 page 14, 3.2.5 page 15,
3.3.4 page 21: I prefer a space before -- (as it is the rule
in French, the language the construct is from :-)
- intro page 4: double (and too close) usage of the word "possible"
- 2 page 6: perhaps the right place to introduce the status keywords
and locator types
- 3.1 page 9: the "for fault tolerante" is too restrictive, I propose
to add "for instance"
- 3.1.2 page 10: other transport modes -> formats?
- 3.2.1 page 12: first use of the status keywords (UNVERIFIED,
DEPRECATED and ACTIVE)
- 3.2.3 page 13: question: what happens for addresses which are not
in a locator? This is a generic issue, if we want to avoid this case
the address selection rules (RFC 3484) should be prepended with a
rule limiting the candidate set to locators
- 3.2.3 page 13: in "However, it is recommended that implementations
attempt to support peers that prefer to use non-paired SAs" why not
RECOMMENDED? (BTW to avoid this kind of question the best is to
use a synonym in the place of a lower case keyword)
- 3.2.3 page 14: first use of locator types (and without any hint
about what there are for a new reader)
- 3.2.7 page 16: some type of mechanism -> mechanisms?
- 3.3.3 page 20: draft -> document/text/... (but not draft! :-)
- 3.3.4 page 21: "unless the ESP anti-replay window is loose"???
^^^^^
I suggest "is large enough"
- 3.3.4 page 22: I don't (want to) understand what you mean by
"at least reset its ESP anti-replay window"
^^^^^
- 4 page 24: the P (preferred) flag is underdefined. It seems
according to 5.5 -3 it is in fact a hint. So it can be an
answer to my question: is it possible to set zero or more than
one P flag to one?
- 4.2 page 25: th locator type must be introduced before!
- 5.1 page 26: the status must be introduced before!
- 5.2 page 27 and 5.3 page 30: the IPv6 undefined address should
be added to the illegal addresses (i.e., with broadcast and
multicast)?
- 5.5 -3 page 33: I really don't like the idea to pick randomly
an address. Why not using the RFC 3484 rules?
- 5.6 page 33: to stay polite and because my own opinion is already
well known, I shan't say what I think about the CBA mechanism...
- 7 page 42: the Section 5.3 doesn't "define this parameter with
a Value of 46" (easy but mandatory to fix as the IANA consideration
will stay)
- appendix A page 44: the usage is to specify the appendix will be
removed by the RFC editor
Regards
[EMAIL PROTECTED]
PS: IMHO the document provides readdressing which is a limited form
of mobility (as explained inside the document, so the issue is in the
wording) and a limited form of multihoming too. Perhaps the source of
the problem is the mixed between the mechanism and its usage?
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www1.ietf.org/mailman/listinfo/gen-art
