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

Francis.Dupont@fdupont.fr

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?