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]
