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]
