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]
