Hi Debbie, Nice find! Thank you for your quick response. We will update the document accordingly!
Madison Church RFC Production Center > On Sep 26, 2025, at 11:10 AM, Deb Cooley <[email protected]> wrote: > > and to really nail this down, NIST also agrees to AES-CCM. Huzzah! > > Deb > > On Fri, Sep 26, 2025 at 11:50 AM Deb Cooley <[email protected]> wrote: > I checked with the author of RFC 4309 who prefers the hyphen. So AES-CCM, > please. > > Deb > > On Fri, Sep 26, 2025 at 10:24 AM Deb Cooley <[email protected]> wrote: > I'm going to make some inquiries (to authors and NIST), like Valery, this > looks very strange. If one or the other is correct, I'm going to pick that... > > Stay tuned. > > Deb > > On Fri, Sep 26, 2025 at 9: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 > > >>> 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"). > > >> 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]
