Hi Madison, Brian, and Deb, thank you for this update.
> 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. Please see inline (I trimmed the message for readability). > >>> 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. OK, I got it. Thank you for this clarification. > >> 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. Thank you! > >> 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! I would say that they really are (at least for me) :-) > 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. Since I'm definitely not an expert in English grammar, I relay on your decision what is best in this case. I'm happy with either variant as they both are clear in my opinion, so for me this is really a nit :-) But I know how important articles can be in some cases, that's why I asked this question. > >> 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. Fine by me, but let's wait for Brian's opinion. > >> 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. Got it, thank you for this information. I noticed that the following requesting change wasn't done: > 54) Section 4.4.1 > > CURRENT: > Group policies are comprised of two types: GSA policy and GW policy. > > Perhaps it is not consistent, but I think that we should re-expand GW here > (and perhaps GSA too). > GW is defined in the very beginning and is not used up to this point, thus I > think it would > be helpful for readers to remind what it is. > > NEW: > Group policies are comprised of two types: group SA (GSA) policy and > group-wide (GW) policy. While I admit that the proposed text re-expanded the terms that have already been expanded, the rationale for it is that this expansion was ~30 pages before, and terms were not used since that, so re-expansion may help readers to refresh their memory. I don't insist, but I think this is helpful. Brian, Deb, your opinion? 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 > > 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]
