Hi Brian, Thank you for your reply! See inline for responses.
> On Sep 26, 2025, at 11:44 AM, Brian Weis <[email protected]> wrote: > > HI Madison, > >> On Sep 26, 2025, at 6:48 AM, Madison Church <[email protected]> >> wrote: >> >> Hi Valery and Brian, *Debbie, >> >> Thank you both for your replies and patience as we incorporate your >> requested changes! We have updated the document and have a few followup >> questions/comments inline (for easy readability, we have only included >> outstanding questions in this thread). >> >> *Debbie - As responsible AD for this document, please see question 14 and >> let us know if you approve the change made to the first sentence in Section >> 2.5. The change may be viewed in this diff file: >> https://www.rfc-editor.org/authors/rfc9838-diff.html. >> >>>>> 4) <!-- [rfced] Please review whether any of the notes in this document >>>>> should be in the <aside> element. It is defined as "a container for >>>>> content that is semantically less important or tangential to the >>>>> content that surrounds it" >>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>> --> >>>> >>>> I'm not sure I understand the visual effect of <aside> element (I guess >>>> this is an xml2rfc v3 feature). >>>> Can you point me to RFCs that use this element? >>>> >>>> And do you have some parts of this document in mind that >>>> this element can be useful for? >> >> 1) Depending on author preference, we will occasionally use <aside> for text >> marked as "Note:". The output yields a visual of indented text with a >> vertical line on the left. For example, RFCs 9800 [1] and 9801 [2] utilize >> the <aside> element frequently. >> >> As for areas in this document that may benefit from the <aside>, the last >> sentence of Section 1 (Introduction and Overview) contains a note. >> >> [1]: https://www.rfc-editor.org/rfc/rfc9800.txt >> [2]: https://www.rfc-editor.org/rfc/rfc9801.txt > > Thanks for the additional information and examples. I wouldn’t see any harm > using this new feature for the following notes, but am interested to hear > Valery's thoughts since he’s more in tune with the culture of the working > group and understanding how they would react to its use. > > 1. Section 1: "(Note: For clarity ….”. > > 2. Section 1: “Also note that GCKS ….”, but removing the “Also” and changing > “note” to “NOTE:”. > > 3. Section 2.3.1 “Note that due ….” > > 4. Section 6.1. “Note that while …." Noted! We will wait for Valery’s review before making any updates regarding the use of <aside>. >>>>> 14) <!-- [rfced] We have updated this sentence to use "AES CCM" (per >>>>> RFC 4309) rather than "AES-CCM". Please let us know any >>>>> objections. >>>>> >>>>> Original: >>>>> Several counter-based modes of operation have been specified for ESP >>>>> (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], >>>>> ChaCha20-Poly1305 [RFC7634], AES-GMAC [RFC4543]) and AH (e.g., AES- >>>>> GMAC [RFC4543]). >>>>> >>>>> Current: >>>>> Several counter-based modes of operation have been specified for ESP >>>>> (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES CCM [RFC4309], >>>>> ChaCha20-Poly1305 [RFC7634], and AES-GMAC [RFC4543]) and AH (e.g., AES- >>>>> GMAC [RFC4543]). >>>>> --> >>>> >>>> Hmm, obviously, I should have no objections to this as RFC 4309 uses this >>>> form >>>> but actually this is a big surprise for me: the lack of consistency in >>>> naming :-) >>>> >>>> And a number of RFCs related to IPsec (I suspect there are others too) >>>> actually use "AES-CCM" form >>>> (RFC8247, RFC7321). Thus, I have no position and rely on AD's decision on >>>> this. >>>> >>>>> 22) <!-- [rfced] May we restructure the text below as follows for >>>>> readability? >>>>> >>>>> Current: >>>>> This transform ID defines the following properties. Sequence numbers >>>>> are 32-bit in size and are transmitted in the Sequence Number field of >>>>> AH and >>>>> ESP packets. The value of sequence numbers is not guaranteed to be >>>>> unique for >>>>> the duration of an SA, thus they are not suitable for replay protection. >>>>> This >>>>> transform ID MUST be used by the GCKS in case of multi-sender multicast >>>>> Data-Security SAs utilizing protocols ESP or AH to inform the GMs that >>>>> the >>>>> replay protection is not expected to be possible. The GCKS MAY also use >>>>> this >>>>> transform ID for single-sender multicast Data-Security SAs if replay >>>>> protection is not needed (e.g. it is done on application level). >>>>> >>>>> >>>>> Perhaps: >>>>> This transform ID defines the following properties: >>>>> >>>>> * Sequence numbers are 32 bits in size and are transmitted in the >>>>> Sequence >>>>> Number field of AH and ESP packets. >>>>> >>>>> * The value of sequence numbers is not guaranteed to be unique for >>>>> the duration of an SA, thus they are not suitable for replay >>>>> protection. >>>>> >>>>> * This transform ID MUST be used by the GCKS in the case of multi-sender >>>>> multicast Data-Security SAs utilizing protocols ESP or AH to inform >>>>> the GMs that the replay protection is not expected to be possible. >>>>> >>>>> * The GCKS MAY also use this transform ID for single-sender multicast >>>>> Data-Security SAs if replay protection is not needed (e.g., it is done >>>>> on the application level). >>>>> --> >>>> >>>> Actually, only two first bullet define the properties, the last two >>>> just explain how to use this transform ID. I propose instead the following >>>> variants. >>>> >>>> Option A - split para and do not add list: >>>> >>>> NEW (Option A): >>>> This transform ID defines the >>>> following properties. Sequence numbers are 32 bits in size and are >>>> transmitted in the Sequence Number field of AH and ESP packets. The >>>> value of sequence numbers is not guaranteed to be unique for the >>>> duration of an SA, thus they are not suitable for replay protection. >>>> >>>> This transform ID MUST be used by the GCKS in case of multi-sender >>>> multicast Data-Security SAs utilizing protocols ESP or AH to inform >>>> the GMs that the replay protection is not expected to be possible. >>>> The GCKS MAY also use this transform ID for single-sender multicast >>>> Data-Security SAs if replay protection is not needed (e.g., it is >>>> done on the application level). >>>> >>>> Option B - use list for properties only: >>>> >>>> NEW (Option B): >>>> This transform ID defines the following properties: >>>> >>>> * Sequence numbers are 32 bits in size and are transmitted in the >>>> Sequence >>>> Number field of AH and ESP packets. >>>> >>>> * The value of sequence numbers is not guaranteed to be unique for >>>> the duration of an SA, thus they are not suitable for replay >>>> protection. >>>> >>>> This transform ID MUST be used by the GCKS in case of multi-sender >>>> multicast Data-Security SAs utilizing protocols ESP or AH to inform >>>> the GMs that the replay protection is not expected to be possible. >>>> The GCKS MAY also use this transform ID for single-sender multicast >>>> Data-Security SAs if replay protection is not needed (e.g., it is >>>> done on the application level). >>>> >>>> I have no preferences, but perhaps option B looks a bit neater. >>> >>> I’m fine with either of Valery’s proposals but also prefer Option B. >> >> 2) Thank you for your proposal! We have updated the document to use Option B. >> >>>>> 39) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>> online >>>>> Style Guide >>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>> and let us know if any changes are needed. Updates of this nature >>>>> typically >>>>> result in more precise language, which is helpful for readers. >>>>> >>>>> For example, please consider whether the term "man-in-the-middle" should >>>>> be >>>>> updated. --> >>>> >>>> I believe we can use "person-in-the-middle" instead. >>>> I failed to find other issues with inclusive language guide in the text. >>> >>> Alternatively, “On-Path Attack Protection”. >> >> 3) We have updated to use "on-path attack protection" (as this is a common >> replacement for "man-in-the-middle"). > > Could you verify this change please? I have refreshed and see an updated set > of author files but the header still seems to contain “Man-in-the-Middle”. Updated files have been reposted! Also note that we have reverted the following change ("AES CCM" to "AES-CCM") per Debbie’s response to question 14. OLD: Several counter-based modes of operation have been specified for ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES CCM [RFC4309], ChaCha20-Poly1305 [RFC7634], and AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). NEW: Several counter-based modes of operation have been specified for ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], ChaCha20-Poly1305 [RFC7634], and AES-GMAC [RFC4543]) and AH (e.g., AES-GMAC [RFC4543]). Updated files: https://www.rfc-editor.org/authors/rfc9838.txt https://www.rfc-editor.org/authors/rfc9838.pdf https://www.rfc-editor.org/authors/rfc9838.html https://www.rfc-editor.org/authors/rfc9838.xml Updated diff files: https://www.rfc-editor.org/authors/rfc9838-diff.html https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9838-auth48diff.html https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by side) Thank you! Madison Church RFC Production Center > Everything else looks fine to me. > > Thanks, > Brian > >> >>>> 40) Not all new IANA registries added to >>>> https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml >>>> are properly filled in. In particular, the "Reserved for Private Use" >>>> ranges in the "GSA Attributes", >>>> the "Group-wide Policy Attributes" and the "Member Key Bag Attributes" >>>> registries do not >>>> reference to this document (while the "Group Key Bag Attributes" registry >>>> does). >> >> 4) Thank you for pointing this out! We will ask IANA to update these >> registries. We will also ask them to correct the "Unassigned" range in Table >> 13 (as mentioned in mail from 9/24). >> >>>> I also have a proposal. The draft references >>>> draft-ietf-ipsecme-ikev2-qr-alt-10, >>>> which is currently in the RFC Editor queue in the state "AUTH48". >>>> While it is only informatively referenced, I think that it would be better >>>> if it is referenced >>>> as RFC and not as I-D. Can you please make this possible (I think it would >>>> require adding >>>> draft-ietf-ipsecme-ikev2-qr-alt-10 to C532 cluster). >> >> 5) Understood! As of right now, the document is cited as >> [IPSEC-IKEV2-QR-ALT] in the text. Would you like to update to use [RFC9867]? >> >> The files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9838.txt >> https://www.rfc-editor.org/authors/rfc9838.pdf >> https://www.rfc-editor.org/authors/rfc9838.html >> https://www.rfc-editor.org/authors/rfc9838.xml >> >> Diff files: >> https://www.rfc-editor.org/authors/rfc9838-diff.html >> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9838-auth48diff.html >> https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by >> side) >> >> For the AUTH48 status page, please see: >> https://www.rfc-editor.org/auth48/rfc9838. >> >> Thank you! >> >> Madison Church >> RFC Editor >> >>>> Regards, >>>> Valery. >>>> >>>> >>>>> Thank you. >>>>> >>>>> Madison Church and Karen Moore >>>>> RFC Production Center >>>>> >>>>> >>>>> On Sep 11, 2025, at 7:14 PM, RFC Editor via auth48archive >>>>> <[email protected]> wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2025/09/11 >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Instructions for Completing AUTH48 >>>>> >>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>> approved by you and all coauthors, it will be published as an RFC. >>>>> If an author is no longer available, there are several remedies >>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>> >>>>> You and you coauthors are responsible for engaging other parties >>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>> your approval. >>>>> >>>>> Planning your review >>>>> --------------------- >>>>> >>>>> Please review the following aspects of your document: >>>>> >>>>> * RFC Editor questions >>>>> >>>>> Please review and resolve any questions raised by the RFC Editor >>>>> that have been included in the XML file as comments marked as >>>>> follows: >>>>> >>>>> <!-- [rfced] ... --> >>>>> >>>>> These questions will also be sent in a subsequent email. >>>>> >>>>> * Changes submitted by coauthors >>>>> >>>>> Please ensure that you review any changes submitted by your >>>>> coauthors. We assume that if you do not speak up that you >>>>> agree to changes submitted by your coauthors. >>>>> >>>>> * Content >>>>> >>>>> Please review the full content of the document, as this cannot >>>>> change once the RFC is published. Please pay particular attention to: >>>>> - IANA considerations updates (if applicable) >>>>> - contact information >>>>> - references >>>>> >>>>> * Copyright notices and legends >>>>> >>>>> Please review the copyright notice and legends as defined in >>>>> RFC 5378 and the Trust Legal Provisions >>>>> (TLP – https://trustee.ietf.org/license-info). >>>>> >>>>> * Semantic markup >>>>> >>>>> Please review the markup in the XML file to ensure that elements of >>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>> and <artwork> are set correctly. See details at >>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>> >>>>> * Formatted output >>>>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>> formatted output, as generated from the markup in the XML file, is >>>>> reasonable. Please note that the TXT will have formatting >>>>> limitations compared to the PDF and HTML. >>>>> >>>>> >>>>> Submitting changes >>>>> ------------------ >>>>> >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>> the parties CCed on this message need to see your changes. The parties >>>>> include: >>>>> >>>>> * your coauthors >>>>> >>>>> * [email protected] (the RPC team) >>>>> >>>>> * other document participants, depending on the stream (e.g., >>>>> IETF Stream participants are your working group chairs, the >>>>> responsible ADs, and the document shepherd). >>>>> >>>>> * [email protected], which is a new archival mailing list >>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>> list: >>>>> >>>>> * More info: >>>>> >>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>> >>>>> * The archive itself: >>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>> >>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>> If needed, please add a note at the top of the message that you >>>>> have dropped the address. When the discussion is concluded, >>>>> [email protected] will be re-added to the CC list and >>>>> its addition will be noted at the top of the message. >>>>> >>>>> You may submit your changes in one of two ways: >>>>> >>>>> An update to the provided XML file >>>>> — OR — >>>>> An explicit list of changes in this format >>>>> >>>>> Section # (or indicate Global) >>>>> >>>>> OLD: >>>>> old text >>>>> >>>>> NEW: >>>>> new text >>>>> >>>>> You do not need to reply with both an updated XML file and an explicit >>>>> list of changes, as either form is sufficient. >>>>> >>>>> We will ask a stream manager to review and approve any changes that seem >>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>> and technical changes. Information about stream managers can be found in >>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>> >>>>> >>>>> Approving for publication >>>>> -------------------------- >>>>> >>>>> To approve your RFC for publication, please reply to this email stating >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>> as all the parties CCed on this message need to see your approval. >>>>> >>>>> >>>>> Files >>>>> ----- >>>>> >>>>> The files are available here: >>>>> https://www.rfc-editor.org/authors/rfc9838.xml >>>>> https://www.rfc-editor.org/authors/rfc9838.html >>>>> https://www.rfc-editor.org/authors/rfc9838.pdf >>>>> https://www.rfc-editor.org/authors/rfc9838.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9838-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9838-xmldiff1.html >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9838 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9838 (draft-ietf-ipsecme-g-ikev2-23) >>>>> >>>>> Title : Group Key Management using IKEv2 >>>>> Author(s) : V. Smyslov, B. Weis >>>>> WG Chair(s) : Yoav Nir, Tero Kivinen >>>>> >>>>> Area Director(s) : Deb Cooley, Paul Wouters >>>>> >>>>> >>>>> -- >>>>> auth48archive mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
