It all looks fantastic to me. A ton of work has gone into this and I
appreciate it.
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.
While 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.
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]
