Hello Tom, I'm sorry for the late reply. See my comments below.
Am 02.01.2013 08:23, schrieb Henderson, Thomas R: > I'd like to try to wrap up the open issues on RFC5201-bis. There are four > issues remaining in the tracker: > > 1) ticket 25: Orchid Generation Algorithm > (http://trac.tools.ietf.org/wg/hip/trac/ticket/25) > > This issue was open to flag the need to revise RFC4843-bis. I believe that > this has been done and the documents are now consistent (although the > 5201-bis draft should point to the -03 version of the 4843-bis draft). I > propose to close this with no further changes other than a reference refresh, > if there are no objections. I agree. > > 2) ticket 39: Improve text relating to R1 counter rollover > (http://trac.tools.ietf.org/wg/hip/trac/ticket/39) > > I'd like to propose the following text change: > > OLD TEXT (sec 4.1.4): > > The R1 counter SHOULD NOT roll over. > > NEW TEXT: > > The R1 generation counter may roll over or may become reset. It is > important for an Initiator to be robust to the loss of state about the R1 > generation counter of a peer, or to a reset of the peer's counter. It is > recommended that, when choosing between multiple R1s, the Initiatior prefer > to use the R1 that is most consistent with the R1 generation counter, but > that if it is unable to make progress with that R1, the Initiator may try the > other R1s. I think "most consistent" is ambiguous. I would rather say "with the least numerical distance" or "closest to" or even "identical to" because the last sentence already deals with the case that an identical counter is not available. The last sentence could be extended by: "may try other R1s with lower R1 counters beginning with the R1 packet with the highest counter". > > 3) ticket 40: decreasing the per-packet overhead > (http://trac.tools.ietf.org/wg/hip/trac/ticket/40) > > Rene has suggested changes to the PUZZLE, SOLUTION, and R1_COUNTER encoding, > to make them more bit-efficient. The proposals seem reasonable to me but > there hasn't been much list discussion. Should we proceed with these > changes? (suggested in this email: > http://www.ietf.org/mail-archive/web/hipsec/current/msg03608.html) I think the proposals are valuable but I think the benefit of the changes would not justify the effort of implemeting these (at this late state). I would opt for leaving the protocol as it is now. > > 4) ticket 41: LSI prefix range > (http://trac.tools.ietf.org/wg/hip/trac/ticket/41) > > As I mentioned last month, it seems that the use of special IPv4 addresses > (loopback prefix or class E prefix) may cause problems on some operating > systems. > > However, I just scanned the draft and couldn't find any place where we are > mentioning LSIs. It may be out of scope for 5201-bis. I propose to close > this with no changes, perhaps just updating the tracker issue with the > results of the implementation survey. If there is a future need to specify > LSI ranges, it may be that RFC 1918 blocks or other address blocks known to > be unused in a HIP environment could be recommended as LSIs. I agree that this can be handled later if the need arises. Thanks for your work. Tobias > > We also have the open issue of IANA allocation of an Orchid prefix, but that > is a 4843-bis issue. > > - Tom > _______________________________________________ > Hipsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/hipsec _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
