At 5:05 PM +0200 1/21/10, Tero Kivinen wrote: All changes made other than the following.
>---------------------------------------------------------------------- > >Section 2.8.2 there was removed paragraph: > > However, there is a twist to the other case where one rekeying > finishes first: > >and I think some kind of paragraph is needed, as the example given >below is not about normal simultaneous IKE SA rekey, but this special >case. Now someone might think that the example given is the normal >simulatenous IKE SA rekey example. Please open a new issue in the tracker and put specific text in it. >---------------------------------------------------------------------- > >The section 1.7 should be more like description of changes, not just >listing section numbers with changed text. For example I think it >would be better to combine: > > In section 1.3.2, changed "The KEi payload SHOULD be included" to be > "The KEi payload MUST be included". This also lead to changes in > section 2.18. > > Section 2.18 requires doing a Diffie-Hellman exchange when rekeying > the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- > Hellman exchange was optional, but this was not useful (or > appropriate) when rekeying the IKE_SA. > >to one item saying: > > Diffie-Hellman exchange is now required for IKE SA rekeys. In > theory, RFC 4306 allowed a policy where the Diffie- Hellman > exchange was optional, but this was not useful (or appropriate) > when rekeying the IKE_SA (section 1.3.2 and section 2.18). This difference is not worth the effort of re-writing the whole section and possibly losing information. >---------------------------------------------------------------------- > >For example in 1.7 the point: > > This document clarifies the use of the critical flag in Section 2.5. > >does not help implementors at all, as they now need to go through the >old RFC4306 section 2.5 and compare it with the new section 2.5 to >find out what was done (and I do not remember that myself, so I need >to do that to provide better text for that bullet). Clarifications such as this are welcome. Please provide text. >---------------------------------------------------------------------- > >In section 1.7 the bullet > > In 2.8, changed "Note that, when rekeying, the new Child SA MAY have > different traffic selectors and algorithms than the old one" to "Note > that, when rekeying, the new Child SA SHOULD NOT have different > traffic selectors and algorithms than the old one". > >should be rewritten to > > In the Child SA rekey the new recommended behavior is that the new > Child SA SHOULD NOT have different traffic selectors and algorithms > than what was used in the old Child SA. Previously it > was that "Child SA MAY have different traffic selectors and > algorithms then the old one" (section 2.8). Those two feel equivalent to me; not done. I am quite hesitant to do wordsmithing at this stage, particularly if it could cause loss of information. >---------------------------------------------------------------------- > >Also I think the new sections could be combined together i.e. replace: > > The new Section 2.8.2 covers simultaneous IKE SA rekeying. > > The new Section 2.9.2 covers traffic selectors in rekeying. > > Added Section 2.23.1 to describe NAT traversal when transport mode is > requested. > >to > > There are completely new sections covering simultaneous IKE SA > rekeying (Section 2.8.2), traffic selectors in rekeying (Section > 2.9.2) and NAT traversal in transport mode (2.23.1). Ditto. These are equivalent. >---------------------------------------------------------------------- > >In general implementators are not that interested in what parts of the >text changed, they are interested in what was the real change that >affects them. That's a very broad claim, made by someone who already fully implemented IKEv2. Other implementers, particularly those who are in the middle of implementing IKEv2, might differ. >---------------------------------------------------------------------- > >Also I think issue #40 requires its own item, as it do change behavior >of implementations. Good catch; added in the next version. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
