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. 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]
