Hi Madison, I approve. Many thanks!
Thanks, Brian > On Oct 24, 2025, at 6:41 AM, Madison Church <[email protected]> > wrote: > > 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]
