In your previous mail you wrote: 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. => note that the only issue here is the (old) abstract doesn't reflect the content of the document. 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. => I have no problem with the title itself as soon as the abstract is clear.
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. => this new abstract is far better! 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 asked in the IPsec list whether SPIs should be random and the answer was a loud *no*. IMHO there is not good reason to have such a constraint. I believe we should simply ask the security ADs. > - 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. => this is only a half solution as the interaction between the LOCATOR notion (including the status) and the RFC 3484 has to be specified (note this is an issue of RFC 3484: as soon as something new is introduced the rule sets, which are in a standard track document, have to be amended by another document at a similar level...). I can see you understand the problem in the new P flag text. 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? => fine with me. Thanks [EMAIL PROTECTED] _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art