Hi Valery and Brian, Thank you for your replies! We have updated the document accordingly and have noted both approvals on the AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9838). Now that we have all author approvals, we will send updates to IANA shortly.
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) https://www.rfc-editor.org/authors/rfc9838-lastdiff.html https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by side) Thank you! Madison Church RFC Production Center > On Oct 28, 2025, at 3:13 AM, Valery Smyslov <[email protected]> wrote: > > Hi Madison and Brian, > > thank you for this update. > > > While re-reading the text, I found one more unfixed instance of incorrect use > of "GSA": > > Section 4.4.2.2.1. > > CURRENT: > When > the lifetime expires, the GSA and all associated keys MUST be > deleted. > > NEW: > When > the lifetime expires, the group SA and all associated keys MUST be > deleted. > > > I approve the publication provided that this is fixed. > > Thank you all for your patience and cooperation! > > Regards, > Valery. > > >> Hi Brian and Valery, >> >> Thank you for your replies! We have updated the document with Valery’s >> “Perhaps 5” suggestion. That said, we >> believe there are no further questions remaining. >> >> Once we receive approvals from both authors, we will send updates along to >> IANA! >> >> 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 >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9838-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) >> https://www.rfc-editor.org/authors/rfc9838-auth48diff.html (AUTH48 changes) >> https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by >> side) >> https://www.rfc-editor.org/authors/rfc9838-lastdiff.html (most recent >> changes) >> https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by side) >> >> Thank you! >> Madison Church >> RFC Production Center >> >> >>> On Oct 23, 2025, at 10:47 AM, Brian Weis <[email protected]> wrote: >>> >>> Hi Valery, >>> >>> I’m quite happy with your “Perhaps 5” text. Let’s go with that. I think >>> this might be the last wording issue. :-) >>> >>> Thanks, >>> Brian >>> >>>> On Oct 22, 2025, at 10:09 PM, Valery Smyslov <[email protected]> wrote: >>>> >>>> Hi Brian, >>>> please see inline. >>>> Hi Valery, >>>> One reply is inline. >>>> >>>> >>>>> On Oct 22, 2025, at 11:54 AM, Valery Smyslov <[email protected]> wrote: >>>>> Hi Brian, >>>>> >>>>> please find my comments inline. >>>>> >>>>> >>>>>> Hi Madison, >>>>>> >>>>>> >>>>>> >>>>>>> On Oct 21, 2025, at 2:30 PM, Madison Church <[email protected] >>>>>> >>>>>> editor.org> wrote: >>>>>> >>>>>>> >>>>>>> Hi Brian, Valery, and *Deb, >>>>>>> >>>>>>> *Deb - Please review and approve the added text to Section 1.2 (Group SA >>>>>> >>>>>> definition). This change may be viewed here: https://www.rfc- >>>>>> editor.org/authors/rfc9838-lastdiff.html. >>>>>> >>>>>>> >>>>>>> Brian and Valery - Thank you both for your detailed replies! We have >>>>>> >>>>>> incorporated the requested updates. See below for a few (final) proposed >>>>>> changes. Aside from the following, we believe there are no remaining >>>>>> inquiries >>>>>> that are outstanding. Please review the document carefully to ensure >>>>>> satisfaction as we do not make changes once it has been published as an >>>>>> RFC. >>>>>> Contact us with any further updates or with your approval of the >>>>>> document in >>>>>> its current form. We will await approvals from each author prior to >>>>>> asking >>>>>> IANA to make their updates. >>>>>> >>>>>> Whew! The changes all look fine to me, thanks. >>>>>> >>>>>> I’ve added some replies your questions below, which should be addressed >>>>>> before approval. >>>>>> >>>>>> >>>>>>> >>>>>>> We spotted 4 additional instances of "GSA policy" and 2 additional >>>>>>> instances >>>>>> >>>>>> of "GSA attributes" that were not included in the list of updates. >>>>>> Should these >>>>>> instances be updated to "group SA policy" and "group SA attributes" as >>>>>> well? >>>>>> Or should they remain as is? >>>>> >>>>> >>>>> Oh, this is my fault, I somehow missed them :-( >>>>> >>>>> >>>>>>> Section 4.4.1 >>>>>>> >>>>>>> 1) Current: >>>>>>> Depending on the employed security protocol, GSA policies may further >>>>>>> be classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) >>>>>>> SA >>>>>> >>>>>> policy. >>>>>> >>>>>>> >>>>>>> Perhaps: >>>>>>> Depending on the employed security protocol, group SA policies may >>>>>>> further be classified as Rekey SA (GSA KEK) policy and Data-Security >>>>>>> (GSA >>>>>> >>>>>> TEK) SA policy. >>>>>> >>>>>> I believe that “GSA policies” is referring to “Group Policies” in Figure >>>>>> 14, so I >>>>>> would suggest the following. >>>>>> >>>>>> Perhaps 2: >>>>>> Depending on the employed security protocol, Group Policies may further >>>>>> be >>>>>> classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA >>>>>> policy. >>>>> >>>>> >>>>> No, this text clarifies the types of SAs that can be considered as "group >>>>> SAs" >>>>> and for which group SA policy can be provided. Thus, I think that >>>>> Madison's proposal is correct. >>>>> >>>>> Along with the two preceding sentences the text is: >>>>> >>>>> Group policies are comprised of two types: group SA policy and group- >>>>> wide (GW) policy. Group SA policy defines parameters for the >>>>> Security Association of the group. Depending on the employed >>>>> security protocol, group SA policies may further be classified as Rekey >>>>> SA >>>>> (GSA KEK) policy and Data-Security (GSA TEK) SA policy. >>>>> >>>>> which gives all the context. >>>> >>>> Ok, that’s fine. But now I think that there’s a typo in this sentence, >>>> which is what tripped me up. The previous sentence refers to a >>>> plurality of security policies, and so should this one. Note the change >>>> below from “security protocol” to “security protocols”. >>>> Perhaps 3: >>>> Depending on the employed security protocols, Group Policies may further be >>>> classified as Rekey SA (GSA KEK) policy and Data-Security (GSA TEK) SA >>>> policy. >>>> I have no problem with this change, but the text above still >>>> talks about "Group Policy" and not >> about "group SA policy". >>>> I believe this is a typo (since you agreed with my previous >>>> message). We classify Group >> Policies as "group SA policies" and "group-wide policy" above >>>> and then further classify the former as "Rekey SA policy" and >>>> "Data-Security SA policy". >>>> Thus, I think the text should be: >>>> Perhaps 4. >>>> Depending on the employed security protocols, group SA policies may >>>> further be >>>> classified as Rekey SA (GSA KEK) policies and Data-Security (GSA TEK) SA >>>> policies. >>>> (note, that I used plural form everywhere). >>>> Or instead: >>>> Perhaps 5. >>>> Depending on the employed security protocol, a group SA policy may be >>>> either a Rekey SA (GSA KEK) policy or a Data-Security (GSA TEK) SA policy. >>>> (Note that I used singular form everywhere and an "a" article to show that >>>> there may be two types of group SA >> policies). >>>> Which variant is better in your opinion? Of do you have a better one in >>>> mind? >>>> As for me, I slightly prefer the last variant. >>>> Regards, >>>> Valery. >>>> Thanks, >>>> Brian >>>> >>>> >>>>> >>>>> >>>>>>> 2) Current (2 instances): >>>>>>> The format of the substructures is defined in Section 4.4.2 (for GSA >>>>>>> policy) and in Section 4.4.3 (for GW policy). The first octet of the >>>>>>> substructure unambiguously determines its type; it is zero for GW >>>>>>> policy and non-zero (actually, it contains a Security Protocol >>>>>>> Identifier) for GSA policies. >>>>>>> >>>>>>> Perhaps: >>>>>>> The format of the substructures is defined in Section 4.4.2 (for group >>>>>>> SA >>>>>>> policy) and in Section 4.4.3 (for GW policy). The first octet of the >>>>>>> substructure unambiguously determines its type; it is zero for GW >>>>>>> policy and non-zero (actually, it contains a Security Protocol >>>>>>> Identifier) for group SA policies. >>>>>> >>>>>> >>>>>> I believe this is a correct change. >>>>> >>>>> >>>>> I agree. >>>>> >>>>> >>>>>>> Section 4.4.2 >>>>>>> >>>>>>> 1) Current: >>>>>>> Section 4.4.2.2 defines attributes used in GSA policy substructure. >>>>>>> >>>>>>> Perhaps: >>>>>>> Section 4.4.2.2 defines attributes used in group SA policy substructure. >>>>>> >>>>>> >>>>>> The update seems correct. However, I would not object to also adding >>>>>> “the” >>>>>> before “group SA", which was missing in the original text i.e., >>>>>> >>>>>> Perhaps 2: >>>>>> … “used in the group SA …" >>>>> >>>>> >>>>> I agree. >>>>> >>>>> >>>>>>> Section 4.4.2.2 >>>>>>> >>>>>>> 1) Current: >>>>>>> Unlike security parameters distributed via transforms, which are >>>>>>> expected not to change over time (unless the policy changes), the >>>>>>> parameters distributed via GSA attributes may depend on the time the >>>>>>> provision takes place, on the existence of others group SAs, or on other >>>>>> >>>>>> conditions. >>>>>> >>>>>>> >>>>>>> Perhaps: >>>>>>> Unlike security parameters distributed via transforms, which are >>>>>>> expected not to change over time (unless the policy changes), the >>>>>>> parameters distributed via group SA attributes may depend on the time >>>>>>> the provision takes place, on the existence of others group SAs, or on >>>>>>> other >>>>>> >>>>>> conditions. >>>>>> >>>>>> This also seems correct. However, I think there’s a slight typo in the >>>>>> last line of >>>>>> the original text (“other” should not be plural). >>>>>> >>>>>> Perhaps 2: >>>>>> … existence of other group SAs ... >>>>> >>>>> >>>>> Yes. >>>>> >>>>> >>>>>>> 2) Current: >>>>>>> This document creates a new IKEv2 IANA registry for the types of GSA >>>>>>> attributes, which has been initially populated as described in Section >>>>>>> 9. >>>>>>> >>>>>>> Perhaps: >>>>>>> This document creates a new IKEv2 IANA registry for the types of group >>>>>>> SA attributes, which has been initially populated as described in >>>>>>> Section 9. >>>>>> >>>>>> >>>>>> This seems correct to me. >>>>> >>>>> >>>>> Exactly. >>>>> >>>>> Thank you! >>>>> >>>>> Regards, >>>>> Valery. >>>>> >>>>> P.S. I seem to realize how I missed these 6 cases - I simply searched the >>>>> draft text >>>>> for "GSA policy", "GSA attribute" and forgot that there may be plural >>>>> form "policies" >>>>> and the searched text may be also split by line break. Alas. >>>>> >>>>> >>>>> >>>>>> Many thanks! >>>>>> Brian >>>>>> >>>>>> >>>>>>> >>>>>>> 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 >>>>>>> >>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>> https://www.rfc-editor.org/authors/rfc9838-diff.html (comprehensive >>>>>> >>>>>> changes) >>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) >>>>>>> https://www.rfc-editor.org/authors/rfc9838-auth48diff.html (all AUTH48 >>>>>> >>>>>> changes) >>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9838-auth48rfcdiff.html (side by >>>>>> >>>>>> side) >>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9838-lastdiff.html (diff showing >>>>>>> latest >>>>>> >>>>>> updates) >>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9838-lastrfcdiff.html (side by >>>>>>> side) >>>>>>> >>>>>>> For the AUTH48 status of this document, please see: >>>>>>> https://www.rfc-editor.org/auth48/rfc9838 >>>>>>> >>>>>>> Thank you! >>>>>>> Madison Church >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Oct 21, 2025, at 1:44 AM, Valery Smyslov <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Brian, >>>>>>>> >>>>>>>> >>>>>>>>> Hi Valery, >>>>>>>>> >>>>>>>>> These changes look fine to me, if everyone agrees that making this >>>>>>>>> much change is acceptable. Certainly they clean up inconsistence >>>>>> >>>>>> regarding “GSA”. >>>>>> >>>>>>>>> >>>>>>>>> However, it strikes me that the document is now so populated with >>>>>>>>> the term “group SA”, so it should probably be defined in Section 1.2. >>>>>>>>> >>>>>>>>> Possibly: >>>>>>>>> >>>>>>>>> NEW >>>>>>>>> Group SA: A Data-Security SA or Rekey SA that is shared as part of >>>>>>>>> Group >>>>>> >>>>>> policy. >>>>>> >>>>>>>> >>>>>>>> Good idea! >>>>>>>> >>>>>>>> I think it should be inserted between the "Rekey SA" definition and the >>>>>> >>>>>> "Group Security Association (GSA)" definition. >>>>>> >>>>>>>> And I also think that "Group policy" should be "group policy" to be >>>>>> >>>>>> consistent with other uses of this words. >>>>>> >>>>>>>> >>>>>>>> Thus (a detailed change request for Madison): >>>>>>>> >>>>>>>> OLD: >>>>>>>> Rekey SA: >>>>>>>> A single multicast SA between the GCKS and all of the GMs. This >>>>>>>> SA is used for multicast transmission of key management messages >>>>>>>> from the GCKS to all GMs. >>>>>>>> >>>>>>>> Group Security Association (GSA): >>>>>>>> A collection of Data-Security SAs and Rekey SAs necessary for a GM >>>>>>>> to receive key updates. A GSA describes the working policy for a >>>>>>>> group. Refer to the MSEC Group Key Management Architecture >>>>>>>> [RFC4046] for additional information. >>>>>>>> >>>>>>>> >>>>>>>> NEW: >>>>>>>> Rekey SA: >>>>>>>> A single multicast SA between the GCKS and all of the GMs. This >>>>>>>> SA is used for multicast transmission of key management messages >>>>>>>> from the GCKS to all GMs. >>>>>>>> >>>>>>>> Group SA: >>>>>>>> A Data-Security SA or Rekey SA that is shared as part of group >>>>>>>> policy. >>>>>>>> >>>>>>>> Group Security Association (GSA): >>>>>>>> A collection of Data-Security SAs and Rekey SAs necessary for a GM >>>>>>>> to receive key updates. A GSA describes the working policy for a >>>>>>>> group. Refer to the MSEC Group Key Management Architecture >>>>>>>> [RFC4046] for additional information. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Valery. >>>>>>>> >>>>>>>> >>>>>>>>> Hope that helps, >>>>>>>>> Brian >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Oct 17, 2025, at 12:43 AM, Valery Smyslov <[email protected]> wrote: >>>>>>>>>> >>>>>>>>>> Hi Deb, Brian, Madison, >>>>>>>>>> >>>>>>>>>> taking into consideration Deb’s opinion, I think that for the >>>>>>>>>> purpose of making the abbreviations unambiguous, >>>>>>>>> >>>>>>>>> the simplest change would be to >>>>>>>>> >>>>>>>>>> just replace “GSA” with “group SA” for “GSA policy” (14 instances), >>>>>>>>>> “GSA transforms” (3 instances) and “GSA >>>>>>>>> >>>>>>>>> attributes” (10 instances), >>>>>>>>> >>>>>>>>>> with no change to “GSA payload” as Brian rightly noticed that this >>>>>>>>>> is a >>>>>> >>>>>> correct term. >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I checked the draft and here the concrete instances to change I >>>>>>>>>> found: >>>>>>>>>> >>>>>>>>>> For "GSA Policy": >>>>>>>>>> >>>>>>>>>> 1) Section 4.4.1. (2 instances) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> Group policies are comprised of two types: GSA policy and GW policy. >>>>>>>>>> GSA policy defines parameters for the Security Association of the >>>>>>>>>> group. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> Group policies are comprised of two types: group SA policy and group- >>>>>> >>>>>> wide (GW) policy. >>>>>> >>>>>>>>>> Group SA policy defines parameters for the Security Association of >>>>>>>>>> the group. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) Section 4.4.2. (4 instances) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> The GSA policy substructure contains parameters for a single SA >>>>>>>>>> that is used with this group. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Figure 15: GSA Policy Substructure Format >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> The GSA policy fields are defined as follows: >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Section 4.4.2.1 describes >>>>>>>>>> using IKEv2 transforms in GSA policy substructure. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> The group SA policy substructure contains parameters for a single >>>>>>>>>> SA that is used with this group. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Figure 15: Group SA Policy Substructure Format >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> The group SA policy fields are defined as follows: >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Section 4.4.2.1 describes >>>>>>>>>> using IKEv2 transforms in the group SA policy substructure. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) Section 4.4.2.1. (3 instances) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> GSA policy is defined by the means of transforms in the GSA policy >>>>>>>>>> substructure. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Exactly one instance of each mandatory Transform Type and at most >>>>>>>>>> one instance of each optional Transform Type MUST be present in the >>>>>>>>>> GSA policy substructure. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> Group SA policy is defined by the means of transforms in the group >>>>>>>>>> SA policy substructure. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Exactly one instance of each mandatory Transform Type and at most >>>>>>>>>> one instance of each optional Transform Type MUST be present in the >>>>>>>>>> group SA policy substructure. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 4) Section 4.4.2.2. (1 instance), see also 11) below. >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> GSA attributes are generally used to provide GMs with additional >>>>>>>>>> parameters for the GSA policy. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> Group SA attributes are generally used to provide GMs with >>>>>>>>>> additional parameters for the group SA policy. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5) Section 4.4.2.2.1. (1 instance) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> A single attribute of this type MUST be included into any GSA >>>>>>>>>> policy substructure if multicast rekey is employed by the GCKS. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> A single attribute of this type MUST be included into any group SA >>>>>>>>>> policy substructure if multicast rekey is employed by the GCKS. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5) Section 4.4.2.2.2. (1 instance) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> In this case this attribute will be included into the GSA policy >>>>>>>>>> when the GM is registered. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> In this case this attribute will be included into the group SA >>>>>>>>>> policy when the GM is registered. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 6) Section 4.4.2.2.3. (1 instance) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> The length of the attribute data is determined by the SPI Size >>>>>>>>>> field in the GSA policy substructure the attribute resides in (see >>>>>>>>>> Section 4.4.2), and the attribute data contains the SPI as it would >>>>>>>>>> appear on the network. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> The length of the attribute data is determined by the SPI Size >>>>>>>>>> field in the group SA policy substructure the attribute resides in >>>>>>>>>> (see Section 4.4.2), and the attribute data contains the SPI as it >>>>>>>>>> would appear on the network. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 7) Section 4.5.4 (1 instance) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> In addition, if the GCKS plans >>>>>>>>>> to use the multicast Rekey SA for group rekey, then it MUST specify >>>>>>>>>> the key wrap algorithm in the GSA policy for the Rekey SA inside >>>>>>>>>> the GSA payload. >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> In addition, if the GCKS plans >>>>>>>>>> to use the multicast Rekey SA for group rekey, then it MUST specify >>>>>>>>>> the key wrap algorithm in the group SA policy for the Rekey SA >>>>>>>>>> inside the GSA payload. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For "GSA Transforms": >>>>>>>>>> >>>>>>>>>> 8) Section 4.4.2. (2 instances) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> | | >>>>>>>>>> ~ <GSA Transforms> ~ >>>>>>>>>> | | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> GSA Transforms (variable): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> | | >>>>>>>>>> ~ <Group SA Transforms> ~ >>>>>>>>>> | | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Group SA Transforms (variable): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 9) Section 4.4.2.1. (1 instance) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> 4.4.2.1. GSA Transforms >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> 4.4.2.1. Group SA Transforms >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> For "GSA Attributes": >>>>>>>>>> >>>>>>>>>> 10) Section 4.4.2. (2 instances) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> | | >>>>>>>>>> ~ <GSA Attributes> ~ >>>>>>>>>> | | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> GSA Attributes (variable): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> | | >>>>>>>>>> ~ <Group SA Attributes> ~ >>>>>>>>>> | | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Group SA Attributes (variable): >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 11) Section 4.4.2.2. (4 instances), see also 4) above >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> 4.4.2.2. GSA Attributes >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> GSA attributes are generally used to provide GMs with additional >>>>>>>>>> parameters for the GSA policy. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> |Value| GSA Attributes |Format|Multi-Valued| Used in | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Table 5: GSA Attributes >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> 4.4.2.2. Group SA Attributes >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Group SA attributes are generally used to provide GMs with >>>>>>>>>> additional parameters for the group SA policy. >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> |Value| Group SA Attributes |Format|Multi-Valued| Used in | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> Table 5: Group SA Attributes >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 12) Section 5 (2 instances) >>>>>>>>>> CURRENT: >>>>>>>>>> | GSA Attributes (Section 4.4.2.2) | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> | GSA Attributes (Section 4.4.2.2) | >>>>>>>>>> >>>>>>>>>> NEW: >>>>>>>>>> | Group SA Attributes (Section 4.4.2.2) | >>>>>>>>>> >>>>>>>>>> [...] >>>>>>>>>> >>>>>>>>>> | Group SA Attributes (Section 4.4.2.2) | >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 13) Section 9.1 (2 instances) >>>>>>>>>> >>>>>>>>>> CURRENT: >>>>>>>>>> 3. IANA has created the "Group SA Attributes" registry. The >>>>>>>>>> registration >>>>>>>>>> policy for this registry is Expert Review [RFC8126]. The initial >>>>>>>>>> values of the registry are as follows: >>>>>>>>>> >>>>>> +===========+======================+======+======+============+ >>>>>> >>>>>>>>>> |Value |Group SA Attributes |Format|Multi-|Used in | >>>>>>>>>> | | | |Valued|Protocol | >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Is this acceptable? Brian, Deb, your opinion? >>>>>>>>>> >>>>>>>>>> And this would require to update IANA registries, since the name of >>>>>>>>>> one >>>>>> >>>>>> is changed... >>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Valery. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I may not be tracking this issue correctly (and please correct me >>>>>>>>>>> if I get >>>>>> >>>>>> this wrong). >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I would make acronyms (like GSA) consistent within this >>>>>>>>>>> specification. I would not worry, or consider what >>>>>>>>> >>>>>>>>> other specifications use an acronym for some other expansion >>>>>>>>> >>>>>>>>>>> (heck, I see GSA and think 'General Services Administration' - a US >>>>>>>>>>> Fed >>>>>> >>>>>> organization). >>>>>> >>>>>>>>>>> >>>>>>>>>>> Deb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Oct 16, 2025 at 5:28 PM Brian Weis >>>>>> >>>>>> <mailto:[email protected]> wrote: >>>>>> >>>>>>>>>> HI Madison, Valery, Deb, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Oct 9, 2025, at 7:29 AM, Madison Church >>>>>> >>>>>> <mailto:[email protected]> wrote: >>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi Valery, >>>>>>>>>>> >>>>>>>>>>> Thank you for your reply! Please see inline. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Oct 7, 2025, at 3:56 AM, Valery Smyslov <mailto:[email protected]> >>>>>> >>>>>> wrote: >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Hi Madison, >>>>>>>>>>>> >>>>>>>>>>>> thank you for this update, please see inline. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hi Valery and Brian, >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you for your replies! We have posted updated files below. >>>>>>>>>>>>> We believe that there is now only one >>>>>>>>> >>>>>>>>> outstanding >>>>>>>>> >>>>>>>>>>>>> item to address (see inline). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I see no issue with re-expanding the terms, but if Madison >>>>>>>>>>>>>> thinks it >>>>>> >>>>>> isn’t needed then let’s leave it be. >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Thank you for pointing this out! This was actually meant to >>>>>>>>>>>>> be included in the followup questions sent on >>>>>>>>> >>>>>>>>> 10/2, >>>>>>>>> >>>>>>>>>>>>> but must have gotten lost due to the number of changes in the >>>>>> >>>>>> original thread. Apologies for missing this! >>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> While making updates to this document, we noticed that there >>>>>>>>>>>>> seems to be two different expansions for GSA (Group Security >>>>>>>>>>>>> Association and group SA). Is this intentional, or may we make >>>>>>>>>>>>> this consistent by replacing instances of "group SA" with the >>>>>>>>>>>>> abbreviation "GSA"? If yes, may we also make the following >>>>>>>>>>>>> adjustment to >>>>>>>>> >>>>>>>>> the >>>>>>>>> >>>>>>>>>>>>> "NEW" text as shown below? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This is a very good point and indeed a point for some confusion. >>>>>>>>>>>> It is not intentional, the reason is the lack of >>>>>>>>> >>>>>>>>> words >>>>>>>>> >>>>>>>>>>>> in authors' vocabulary (mostly me to blame) :-) >>>>>>>>>>>> >>>>>>>>>>>> We have the following meanings: >>>>>>>>>>>> >>>>>>>>>>>> - GSA (Group Security Association) - a collection of individual >>>>>>>>>>>> Security Associations (both Data-Security SAs >>>>>>>>> >>>>>>>>> and Rekey SAs) >>>>>>>>> >>>>>>>>>>>> as defined in Section 1.2 (we also have GSA (Group Security >>>>>>>>>>>> Association) payload - this is just a name of a >>>>>>>>> >>>>>>>>> payload). >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> - as for "group SA", - in the document this is used to refer to >>>>>>>>>>>> an individual Security Association within GSA (an >>>>>>>>> >>>>>>>>> SA that belongs to a group). >>>>>>>>> >>>>>>>>>>>> Perhaps this is a bad choice of words, but that is that. >>>>>>>>>>>> Unfortunately, >>>>>> >>>>>> the abbreviation is the same - GSA... >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I believe Brian is more experienced in the roots of these terms >>>>>>>>>>>> and can >>>>>> >>>>>> comment on this. >>>>>> >>>>>>>>>> >>>>>>>>>> As mentioned in Section 1,"GSA (Group Security Association)" >>>>>>>>>> matches the definition in RFC 3740 (The >>>>>>>>> >>>>>>>>> Multicast Group Security Architecture), so this is indeed the most >>>>>>>>> correct >>>>>> >>>>>> use of the GSA acronym. >>>>>> >>>>>>>>>> >>>>>>>>>> Then RFC 4046 (Multicast Security (MSEC) Group Key Management >>>>>>>>>> Architecture) introduced the confusing >>>>>>>>> >>>>>>>>> “group SA (GSA)” acronym, which somehow snuck into this document. I >>>>>>>>> note that GDOI (RFC 6407), the predecessor to G-IKEv2, does not use >>>>>>>>> that >>>>>> >>>>>> term for “group SA”. >>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> Thus, we have: >>>>>>>>>>>> - GSA - Group Security Association >>>>>>>>>>>> - GSA policy - group Security Association policy. >>>>>>>>>>>> >>>>>>>>>>>> This is indeed confusing. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps we can replace "GSA policy" with "group SA policy" for >>>>>>>>>>>> clarity (14 instances)? Brian, Deb, your >>>>>>>>> >>>>>>>>> opinion? >>>>>>>>> >>>>>>>>>>>> But there are still "GSA transforms" (meaning group SA >>>>>>>>>>>> transforms) and "GSA Attributes" (group SA >>>>>>>>> >>>>>>>>> attributes)... >>>>>>>>> >>>>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> There’s also the “GSA Payload”, but because it lists policy for a >>>>>>>>>> collection of SAs, which matches the intent of >>>>>>>>> >>>>>>>>> the original definition. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you for the helpful explanation! We will wait for Brian’s >>>>>>>>>>> response/comments before making any updates >>>>>>>>> >>>>>>>>> to the expansion of GSA. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you! >>>>>>>>>>> >>>>>>>>>>> Madison Church >>>>>>>>>>> RFC Production Center >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> Perhaps: >>>>>>>>>>>>> Group policies are comprised of two types: Group Security >>>>>>>>>>>>> Association (GSA) policy and group-wide (GW) >>>>>>>>> >>>>>>>>> policy. >>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Based on the distinction described above I think that the correct >>>>>> >>>>>> expanding here should be: >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> Group policies are comprised of two types: group SA (GSA) policy >>>>>>>>>>>> and >>>>>> >>>>>> group-wide (GW) policy. >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Rationale - the GSA policy here describes a single SA within a GSA. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This would be the simplest change, and I do not believe that >>>>>>>>>> implementors would be confused by the duplicate >>>>>>>>> >>>>>>>>> use of “GSA". If we >>>>>>>>> >>>>>>>>>> were earlier on in the document process I might have suggested a >>>>>>>>>> term to more cleanly delineate this policy >>>>>>>>> >>>>>>>>> element, but not now. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I think in all three cases Valery mentioned (GSA policy, GSA >>>>>>>>>> transforms, GSA Attributes) the term “GSA” does >>>>>>>>> >>>>>>>>> not modify >>>>>>>>> >>>>>>>>>> the word following, but is an equal part of the name of the object >>>>>>>>>> being referenced, if that makes sense. As >>>>>>>>> >>>>>>>>> such, I don’t see >>>>>>>>> >>>>>>>>>> any problem leaving them as is, and simply add Valery’s NEW text >>>>>>>>>> above. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Brian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Valery. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Please review the document carefully to ensure satisfaction as >>>>>>>>>>>>> we do not make changes once it has been published as an RFC. >>>>>>>>>>>>> Contact us with any further updates or with your approval of the >>>>>>>>>>>>> document in its >>>>>>>>> >>>>>>>>> current >>>>>>>>> >>>>>>>>>>>>> form. We will await approvals from each author prior to moving >>>>>> >>>>>> forward in the publication process. >>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Updated files have been posted below (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 >>>>>>>>>>>>> >>>>>>>>>>>>> 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) >>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9838-lastdiff.html (most >>>>>>>>>>>>> recent updates only) >>>>>>>>>>>>> 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 > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
