On Wed, 29 Jul 2026 at 03:54, Valery Smyslov <[email protected]> wrote: > > Hi, > > I don't know how to handle this erratum report. In my opinion, the current > text > is correct, however, better wording is definitely possible. I think that I > was the author of this particular sentence, > and as non-native speaker, I might crafted it with some ambiguity, which I > didn't realize. > However, my co-authors include several native speakers and they did not have > problems with it.
Did not have or did not notice? By clarifying the text our dear reader will be saved from having to wade through the reasoning below. (btw, does the IETF consider RFC diagrams normative, or informative?) > The proposed reading is inconsistent with the rest of the Section 2.2.4. The > peers first > negotiate the additional key exchanges in CREATE_CHILD_SA. So, once > CREATE_CHILD_SA is completed, the responder knows the exact number of the > IKE_FOLLOWUP_KE > exchanges that will follow. There cannot be more exchanges than the > negotiated number, > so the responder always knows whether it expects any further IKE_FOLLOWUP_KE > (in which case it includes the ADDITIONAL_KEY_EXCHANGE notification) or not > (in which case there is no point for including this notification). So, the > situation > when the responder does not know whether the next IKE_FOLLOWUP_KE follows > or not and thus includes ADDITIONAL_KEY_EXCHANGE "just in case" is not > possible. I don't think anyone is questioning the RFC's intent. Just the need for clarity. As they say, the panda eats shoots and leaves. > _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
