Thanks for this. I agree that 'better wording' is almost always possible. If anyone thinks there should be a different resolution (rejected), please reply here.
Otherwise, I'm going to add this to the stack of errata to finalize. Deb On Wed, Jul 29, 2026 at 3:54 AM 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. > > 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. > > So, in my (perhaps biased) opinion the current text is not incorrect and > the erratum should be rejected. > That said, better wording is definitely possible (that is almost always > the case, alas). > > Regards, > Valery. > > > > -----Original Message----- > > From: [email protected] <[email protected]> > > Sent: Friday, July 24, 2026 7:12 PM > > To: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected]; > > [email protected]; [email protected]; > [email protected]; > > [email protected]; [email protected]; > [email protected] > > Cc: [email protected]; [email protected]; [email protected] > > Subject: [IPsec] [Technical Errata Reported] RFC9370 (9036) > > > > The following errata report has been submitted for RFC9370, > > "Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 > (IKEv2)" > > > > -------------------------------------- > > You may review the report below and at: > > https://errata.rfc-editor.org/eid9036/ > > > > -------------------------------------- > > Type: Technical > > Reported by: Andrew Cagney <[email protected]> > > > > Section 2.2.4-5 says: > > > > Original Text > > ------------- > > The responder MUST include this notification in a CREATE_CHILD_SA or > IKE_FOLLOWUP_KE response > > message in case the next IKE_FOLLOWUP_KE exchange is expected, filling > it with some data that would allow > > linking the current exchange to the next one. The initiator MUST send > back this notification intact in the request > > message of the next IKE_FOLLOWUP_KE exchange. > > > > Corrected Text > > -------------- > > Suspect the text was meant to say something like: > > > > The responder MUST include this notification in a CREATE_CHILD_SA or > IKE_FOLLOWUP_KE response > > message in the case of a further IKE_FOLLOWUP_KE exchange is expected, > ... > > > > But better text would something like: > > > > The responder MUST include this notification in the CREATE_CHILD_SA > response message, and in all but the > > final IKE_FOLLOWUP_KE response message, ... > > > > Notes > > ----- > > To my reading, the current sentence states that an > ADDITIONAL_KEY_EXCHANGE notification payload MUST be > > included in all IKE_FOLLOW_UP response messages, just "in case" a > further IKE_FOLLOW_UP exchange is > > needed (we're not sure so we're hedging our bets). > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". Please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > will log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC9370 (draft-ietf-ipsecme-ikev2-multiple-ke) > > -------------------------------------- > > Title : Multiple Key Exchanges in the Internet Key > Exchange Protocol Version 2 (IKEv2) > > Publication Date : May 2023 > > Author(s) : CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, > D. Van Geest, O. Garcia-Morchon, V. Smyslov > > Category : Proposed Standard > > Source : ipsecme (sec) > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > IPsec mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
