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