Francis, Thank you for the extensive review. I will respond inline to each of your points. At the end of the message, I will discuss possible next steps and open issues.
> -----Original Message----- > From: Francis Dupont [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 03, 2007 2:35 PM > To: gen-art@ietf.org > Cc: Henderson, Thomas R; [EMAIL PROTECTED] > Subject: review (full) of draft-ietf-hip-mm-05.txt > > 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 > > 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? > > I discussed briefly with the authors. Your comment is consistent with some other recent comments that the draft does not fully specify a mobility and multihoming solution but only the readdressing mechanisms. After thinking about your suggestion, I would be inclined to even retitle the document to something like: "Readdressing Extensions for HIP Mobility and Multihoming" to clarify that there are other aspects of mobility and multihoming that are not addressed. I would be inclined to keep "Mobility and Multihoming" terms in the title, though, because it is part of the HIP charter to produce such a document. Would you agree with the following abstract? If not, can you suggest specific changes? OLD: This document defines mobility and multihoming extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host-- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR parameter can also be used to support end-host multihoming, detailed procedures are left for further study. NEW: This document defines readdressing extensions to the Host Identity Protocol (HIP) to facilitate host mobility and multihoming. Specifically, this document defines and specifies basic elements of procedure for a general "LOCATOR" parameter for HIP messages. The LOCATOR parameter allows a HIP host to notify peers about alternate addresses at which it may be reached, and further allows it to express policy preferences as to which address to use in different situations when there exists more than one choice for a destination address. Procedures for requiring a host to test the reachability of alternate addresses are also specified. Using this basic readdressing mechanism, limited forms of host mobility and multihoming may be performed, but detailed procedures for a full solution for mobility and multihoming are left for further study. Question for the chairs/AD-- what do you think about changing the document title at this date in the review? > > - 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) AFAIK, this comes from even the very first drafts on HIP by Bob Moskowitz in 1999. The SPI is being used as an endpoint selector. I do not know the security assumptions that led Bob to recommend the "SHOULD" but I will ask. > > - 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) I agree to shifting this to informative, because it is just there for informational purposes. > > (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 :-) changed > > - intro page 4: double (and too close) usage of the word "possible" changed > > - 2 page 6: perhaps the right place to introduce the status keywords > and locator types I have introduced these earlier, as you suggested. > > - 3.1 page 9: the "for fault tolerante" is too restrictive, I propose > to add "for instance" changed > > - 3.1.2 page 10: other transport modes -> formats? changed > > - 3.2.1 page 12: first use of the status keywords (UNVERIFIED, > DEPRECATED and ACTIVE) changed (noted above) > > - 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 I think the question is whether a host may use an address that was not learned during the base exchange or through the LOCATOR parameter. I would suggest that such addresses, if learned out-of-band from the mechanisms specified herein, be treated as UNVERIFIED addresses. > > - 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) changed to RECOMMENDED (I think this is the only case in the document where s/recommended/RECOMMENDED is needed) > > - 3.2.3 page 14: first use of locator types (and without any hint > about what there are for a new reader) > changed (noted above) > - 3.2.7 page 16: some type of mechanism -> mechanisms? > changed > - 3.3.3 page 20: draft -> document/text/... (but not draft! :-) changed to document > > - 3.3.4 page 21: "unless the ESP anti-replay window is loose"??? > ^^^^^ > I suggest "is large enough" changed > > - 3.3.4 page 22: I don't (want to) understand what you mean by > "at least reset its ESP anti-replay window" > ^^^^^ > I deleted this clause. > - 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? Section 4.1 attempted to define this, but I will make this a bit more explicit in section 4.1: The "P" (preferred) bit, when set, has scope over the corresponding Traffic Type. That is, when a "P" bit is set for Traffic Type "2", for example, it means that the locator is preferred for data packets. If there is a conflict (for example, if P bit is set for an address of Type "0" and a different address of Type "2"), the more specific Traffic Type rule applies (in this case, "2"). By default, the IP addresses used in the base exchange are Preferred locators for both signaling and user data, unless a new Preferred locator supersedes them. The Preferred bit is a hint that identifies the locator(s) on which the receiver prefers to receive traffic. The sender of the LOCATOR MAY explicitly select one or more locator for each traffic type as a preferred locator. The corresponding host sending data packets MAY select any active, in-scope locator for a given Traffic Type, but it is RECOMMENDED that Preferred locators be used when all other considerations are equal. If there are more than one Preferred locators to choose from, the sender may select from among them according to [4] or local policy. If no Preferred locators are identified or usable, then the sender may again select from the active locators according to [4] or local policy. where [4] is RFC3484. > > - 4.2 page 25: th locator type must be introduced before! changed (noted above) > > - 5.1 page 26: the status must be introduced before! changed (noted above) > > - 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)? added > > - 5.5 -3 page 33: I really don't like the idea to pick randomly > an address. Why not using the RFC 3484 rules? I agree that it would be better to cite RFC 3484, so I've changed it to say that the host picks according to RFC3484 or local policy. > > - 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... no change. However, there is an outstanding open issue here which is that the citations have expired. > > - 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) > I changed this text as follows below: This document defines a LOCATOR parameter for the Host Identity Protocol [2]. The LOCATOR Parameter Type value is specified in Section 4. This document also defines a LOCATOR_TYPE_UNSUPPORTED Notify Message Type for the NOTIFICATION parameter defined in the Host Identity Protocol specification [2]. The value for the Notify Message Type of LOCATOR_TYPE_UNSUPPORTED is specified in Section 5.3. > - appendix A page 44: the usage is to specify the appendix will be > removed by the RFC editor > I added a note to this effect, as is customarily done. ---------- I have posted a candidate -06 version at the following URL, and will wait for either feedback or guidance from the chair as to how to proceed. http://www.openhip.org/ietf/drafts/draft-ietf-hip-mm-06-pre.txt If my proposed changes above are acceptable, the current open issues are: 1) whether the title should be changed 2) the "SHOULD" for setting the SPI value randomly 3) the CBA draft references need to be replaced with a permanent citation 4) should addresses learned out-of-band be treated as UNVERIFIED, and words to that effect be put in the draft? Regards, Tom _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
