Tobias, inline below... > > > 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.
I closed this accordingly, as there were no other comments. > > > > 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". New text proposal, based on your input: 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 corresponds to the current R1 generation counter, but that if it is unable to make progress with that R1, the Initiator may try the other R1s 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. Since there were no other comments, I believe that we can stay with the status quo and leave these enhancements for future work. > > > > > 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. I just closed this issue and left some documentation in the tracker. We have two open issues above but I think they can be closed as suggested above; I'll close them on Friday if there are no other comments by then. - Tom _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
