Hi Valery and Brian, Now that IANA updates have been completed, we will begin the publication process for this document (along with RFC-to-be 9827, as requested).
Thank you, and happy IETF week! Madison Church RFC Production Center > On Nov 2, 2025, at 1:42 PM, Madison Church <[email protected]> > wrote: > > Hi Sabrina, > > The changes look good! Thank you! > > Madison Church > RFC Production Center > >> On Oct 28, 2025, at 7:05 PM, Sabrina Tanamal via RT <[email protected]> >> wrote: >> >> Hi Madison, >> >> Thank you for pointing out some of the errors below. These have been fixed >> and updated: >> >> https://www.iana.org/assignments/ikev2-parameters >> >> Thanks, >> Sabrina >> >> On Tue Oct 28 15:33:20 2025, [email protected] wrote: >>> IANA, >>> >>> Please make the following changes to match the updated document (RFC >>> 9838). >>> >>> 1) Update the title of the "Group-wide Policy Attributes" registry >>> (https://www.iana.org/assignments/ikev2-parameters/ikev2- >>> parameters.xhtml#group-wide-policy-attributes) to "Group-Wide Policy >>> Attributes". >>> >>> 2) The "Reserved for Private Use" ranges in the "GSA Attributes", >>> "Group-wide Policy Attributes", and "Member Key Bag Attributes" >>> registries do not reference this document (while the "Group Key Bag >>> Attributes" registry does; see https://www.iana.org/assignments/ikev2- >>> parameters/ikev2-parameters.xhtml#group-key-bag-attributes). Please >>> update the reference column of the three registries listed above to >>> include this document as a reference for the "Reserved for Private >>> Use" ranges. >>> >>> 3) For the "GSA Attributes" registry, please update the following: >>> a) Update the "Unassigned" range to "4-16383" (originally "5- >>> 16383"). >>> b) Update the registry title to "Group SA Attributes" >>> (originally "GSA Attributes"). >>> c) Update the title of the "GSA Attributes" column to "Group >>> SA Attributes". >>> >>> For a visual of these updates, please see: https://www.rfc- >>> editor.org/authors/rfc9838-auth48rfcdiff.html. >>> >>> Thank you! >>> >>> Madison Church >>> RFC Production Center >>> >>>> On Oct 28, 2025, at 9:32 AM, Madison Church <[email protected] >>>> editor.org> wrote: >>>> >>>> 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]
