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 <[email protected]> wrote: > HI Madison, Valery, Deb, > > > On Oct 9, 2025, at 7:29 AM, Madison Church <[email protected]> > wrote: > > > > Hi Valery, > > > > Thank you for your reply! Please see inline. > > > >> On Oct 7, 2025, at 3:56 AM, Valery Smyslov <[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]
