That looks good to me. Deb
On Fri, Oct 3, 2025 at 3:54 AM Valery Smyslov <[email protected]> wrote: > Hi Deb, > > > > > > It all looks fantastic to me. A ton of work has gone into this and I > appreciate it. > > > > Thank you, we did our best J > > > > > > I have one comment on Section 5.1, para (2) below Table 9: That second > sentence is very long. What about: > > For a Rekey SA, *exactly one SA_KEY attribute MUST be* > > * present in the GSA_AUTH and the GSA_REGISTRATION exchange**.* > > * W**hile in the GSA_REKEY pseudo-exchange,* at least one SA_KEY > > attribute MUST be present in all cases and more of these attributes > MAY be > > present in a GSA_REKEY pseudo-exchange.*present.* > > where I added '. W' after GSA_REGISTRATION exchange. I made the text blue > above. > > If I've parsed that sentence incorrectly, I'll take hints/corrections. > > This is correct and I’m fine with this change. Actually, if the > sentence is split into two, > then in my opinion “while” is not needed: Thus, perhaps: > > CURRENT: > For a Rekey SA, exactly one SA_KEY attribute MUST be > present in the GSA_AUTH and the GSA_REGISTRATION exchange, > while in the GSA_REKEY pseudo-exchange, at least one SA_KEY > attribute MUST be present and more of these attributes MAY be > present. > > NEW (as a variant): > For a Rekey SA, exactly one SA_KEY attribute MUST be > present in the GSA_AUTH and the GSA_REGISTRATION exchange. > In the GSA_REKEY pseudo-exchange, at least one SA_KEY > attribute MUST be present and more of these attributes MAY be > present. > > I’m fine with either current, your or this variant and trust you, > Brian, and Madison to choose. > > Regards, > Valery. > > > > Deb > > > > > > > > On Thu, Oct 2, 2025 at 5:44 PM Madison Church < > [email protected]> wrote: > > Hi Brian, Valery, and *Deb, > > *Deb - As responsible AD, please review and approve the following changes, > which are best viewed in this diff file: > https://www.rfc-editor.org/authors/rfc9838-lastdiff.html. > - Section 4.4.2.1.2: Change in BCP language > - Section 4.5.4: Updated text in the second paragraph > - Section 5: Updated text under Table 9 > - Section 8.1: Updated text > > Brian and Valery - Thank you both for your helpful replies! We have > updated the document accordingly and have a few followup > comments/questions. Updated files are posted below. Please let us know if > there are any additional updates that are needed. > > >>>>> 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 ….”. > >> > >> I agree (and I think no parentheses are needed in this case): > >> > >> > >>>> 2. Section 1: “Also note that GCKS ….”, but removing the “Also” and > changing “note” to “NOTE:”. > >> > >> OK, but I think it must be "Note:" (with a capital letter, but not > all-uppercase) for consistency. > >> And I think the sentence needs some editing: > >> > >> NEW: > >> Note: GCKS may also be a GM (as shown in Figure 2). > >> > >> (I'm not sure about the need of the article in front of GCKS, sorry). > >> > >> > >>>> 3. Section 2.3.1 “Note that due ….” > >> > >> I agree, but with no "that": > >> > >> NEW: > >> Note: due to the similarities between IKE_AUTH and GSA_AUTH, most > >> IKEv2 extensions to the IKE_AUTH exchange (like secure password > >> authentication [RFC6467]) can also be used with the GSA_AUTH > >> exchange. > >> > >> > >>>> 4. Section 6.1. “Note that while …." > >> > >> I'd rather not to use <aside> here. Rationale: despite the "note" is > used, the sentence > >> actually is a continuation of the discussion of using implicit IV in > multicast SAs. > >> > >>> Noted! We will wait for Valery’s review before making any updates > regarding the use of <aside>. > >> > >> Tables 2, 7, 9, and 10 have some notes below. > >> I think that we can also use <aside> for these notes. > >> Brian, your opinion? > > > > I didn’t suggest Table 2 and Table 7 earlier because they are tightly > associated with the table. That is, the notes are linked to the table > through the use of asterisks and could be considered explicitly associated > with the table. In Tables 9 and 10 the Notes column explicitly refers to > the numbered Notes so again they do seem to be explicitly associated with > the table rather than asides. > > > > But I don't object to these becoming <aside> elements if you still > prefer. > > 1) Per Valery’s response on 10/1, we have not made any updates to Section > 6.1 and Tables 2, 7, 9, and 10. We have updated the relevant text to use > <aside> in Sections 1 and 2.3.1. > > >>> 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 checked the IANA page and found no changes. I hope IANA will update > the page before the publication is approved so that we can check :-) > > 2) The RPC typically sends updates to IANA once all parties on the AUTH48 > status page have approved the document (in this case, it would be both > authors as well as the responsible AD). After IANA completes their updates, > they will let us know and the RPC/authors will be able to verify the > changes. > > >> 49) Section 1. > >> > >> CURRENT: > >> The data communications within the group (e.g., IP > >> multicast packets) are protected by a key pushed to the GMs by the > >> Group Controller/Key Server (GCKS). > >> > >> Is it OK that "GM" is first used without expansion? It was expanded in > the previous > >> text version, but currently is first expanded only in Section 1.2 in > the body of the document. > >> It is also expanded in the Abstract, but I don't know if this matters. > In contract, "GSA" and > >> "GCKS" are expanded both in the Abstract and in Section 1 (and also in > Section 1.2). > >> Can we make this consistent? > > > > Expansion of GM seems like a good idea, unless Madison had a reason for > this exception. > > 3) We re-expanded GM in this sentence for consistency. Thanks for pointing > this out! > > >> 60) Section 2.3.3. > >> > >> CURRENT: > >> Proposals for Rekey SA are identified by new > >> Protocol ID GIKE_UPDATE with the value 6. > >> > >> NEW: > >> Proposals for Rekey SA are identified by new > >> Security Protocol Identifier GIKE_UPDATE with the value 6. > >> > >> "Security Protocol Identifier" is the official name for protocol > identifiers. > > 4) We have made this update with the addition of "a" before "new" in this > sentence. > > Current: > Proposals for Rekey SA are identified by a new > Security Protocol Identifier GIKE_UPDATE with the value 6. > > >> 61) Sections 4.7.1, 4.7.2, 4.7.3, 4.7.4 > >> > >> All these sections contain the same text: > >> > >> CURRENT: > >> The Protocol ID and SPI Size fields in the Notify > >> payload MUST be zero. > >> > >> Since "SPI Size" is a name of a field (as well as "Protocol ID") I > wonder whether > >> it should be prepended with "the" here? Apologize in advance if this is > not needed, > >> using articles is not my strong point... > >> > >> NEW (perhaps): > >> The Protocol ID and the SPI Size fields in the Notify > >> payload MUST be zero. > > 5) No worries—articles can be quite tricky! > > Since "Protocol ID" and "SPI Size" are both fields in the Notify payload, > using one article ("the") is acceptable in the Current text since "fields" > (plural) refers to both the Protocol ID field and the SPI Size field. Using > one article makes the sentence more concise, but we are happy to add an > additional article to "SPI Size field"; we would also suggest adding an > additional mention of "field" after "Protocol ID" for clarity (assuming > "Protocol ID" and "Protocol ID field" mean different things in the context > of RFC 7296). > > Perhaps: > The Protocol ID field and the SPI Size field in the Notify > payload MUST be zero. > > >> 62) Section 4.4.2 > >> > >> CURRENT: > >> The GSA policy substructure contains parameters for the SA that are > >> used with this group. > >> > >> NEW: > >> The GSA policy substructure contains parameters for the SA that is > >> used with this group. > >> > >> Rationale: it is SA that used with this group, and parameters are > >> for this SA. > > > > You’ve moved to a singular verb rather than a plural to highlight > > that there is a single SA. I might suggest wording that might flow a bit > better. > > I believe that It still refers to a single SA, but because the GSA > Policy > > Substructure does contain a plurality of parameters that the word > > “are” is appropriate. > > > > NEW > > The GSA policy substructure contains SA parameters that are > > used with this group. > > > > I expect Madison can guide us to the most optimal wording here. > > 6) Adding Valery’s second proposal here to consolidate AUTH48 threads: > > > NEW > > The GSA policy substructure contains a set of parameters for a single SA > > inside the group. > > Would the following text work for this sentence (and retain the meaning of > the original text)? > > Perhaps: > The GSA policy substructure contains parameters for a single SA that is > used with this group. > > >> 68) Section 9.2, Table 19 > >> > >> CURRENT: > >> +=======+=========================+==========+===========+ > >> | Value | Next Payload Type | Notation | Reference | > >> +=======+=========================+==========+===========+ > >> | 33 | Security Association | SA | [RFC7296] | > >> | +-------------------------+----------+-----------+ > >> | | Security Association - | SAg | RFC 9838 | > >> | | GM Supported Transforms | | | > >> +-------+-------------------------+----------+-----------+ > >> > >> Shouldn't for consistency "RFC 9838" be shown in square brackets and > with no space in between too? > >> > >> NEW: > >> +=======+=========================+==========+===========+ > >> | Value | Next Payload Type | Notation | Reference | > >> +=======+=========================+==========+===========+ > >> | 33 | Security Association | SA | [RFC7296] | > >> | +-------------------------+----------+-----------+ > >> | | Security Association - | SAg | [RFC9838] | > >> | | GM Supported Transforms | | | > >> +-------+-------------------------+----------+-----------+ > > 7) "RFC 9838" is intentional here (rather than [RFC9838]) since we > typically do not include self-references in RFCs. This pattern is common, > especially in the IANA Considerations section. > > 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 > > Update diffs: > 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) > > Diff files showing most recent changes: > https://www.rfc-editor.org/authors/rfc9838-lastdiff.html > https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by > side) > > For the AUTH48 status page, please see: > https://www.rfc-editor.org/auth48/rfc9838. > > Thank you! > > Madison Church > RFC Production Center > > >> > >> > >> Thank you! > >> > >> Regards, > >> Valery. > >> > >>> 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]
