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]
