Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file.
1) <!-- [rfced] Because this document obsoletes RFC 6407, please review the errata reported for RFC 6407 (https://www.rfc-editor.org/errata_search.php?rfc=6407) and let us know if you confirm our opinion that none of them are relevant to the content of this document. --> 2) <!-- [rfced] Please note that the title of the document has been updated to expand abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Original: Group Key Management using IKEv2 Current: Group Key Management Using the Internet Key Exchange Protocol Version 2 (IKEv2) --> 3) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 4) <!-- [rfced] Please review whether any of the notes in this document should be in the <aside> element. It is defined as "a container for content that is semantically less important or tangential to the content that surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). --> 5) <!--[rfced] As the full titles of RFCs 3740, 5374, and 6407 are included in Section 1, we removed the titles from the following text in Section 1.2. Please let us know of any objections. Original: The following key terms are used throughout this document (mostly borrowed from the Multicast Group Security Architecture [RFC3740], Multicast Extensions to the Security Architecture [RFC5374], and the Group Domain of Interpretation (GDOI) [RFC6407]). Current: The following key terms are used throughout this document (mostly borrowed from [RFC3740], [RFC5374], and [RFC6407]). --> 6) <!-- [rfced] Should the following sentence be rephrased as shown below to clarify "IKE SA"? Current: G-IKEv2 MAY also use TCP transport for registration (unicast) IKE SA, as defined in TCP Encapsulation of IKEv2 and IPsec [RFC9329]. Perhaps: G-IKEv2 MAY also use TCP transport for the registration (unicast) of IKE SA, as defined in TCP Encapsulation of IKEv2 and IPsec [RFC9329]. --> 7) <!-- [rfced] Please review Table 1 in Section 2.2. We note that there is some variation between the payload names used in this table and those used in RFC 7296. For example, in RFC 7296, "HDR" is "IKE header (not a payload)" and "SK" is "Encrypted and Authenticated". Please let us know if we should update this table to match what appears in RFC 7296. In addition, we note the following variations in Table 1 and the running text. Should the payload for "IDg" be updated as "Group Identification" to match Table 18 (i.e., the "IKEv2 Payload Types" IANA registry)? Please let us know how we may make these consistent. IDg: Identification - Group (Table 1) vs. Group Identification (IDg) vs. Group ID (IDg) vs. group IDg vs. group ID --> 8) <!--[rfced] In the following, should "Data-Security SAs" be singular since "TEK" is singular? Also, are all of these items optional (option A), or are only the Rekey SA and Group-wide policy optional (option B)? Original: This policy describes the optional Rekey SA (KEK), Data-Security SAs (TEK), and optional Group-wide (GW) policy. Perhaps A: This policy describes the Rekey SA (KEK), Data-Security SA (TEK), and Group-wide (GW) policy, which are all optional. or Perhaps B: This policy describes the Data-Security SA (TEK), optional Rekey SA (KEK), and optional Group-wide (GW) policy. --> 9) <!-- [rfced] How may we update the sentence below to clarify the second and third instances of "Transforms"? Original: * The GCKS could store the list of Transforms, with the goal of migrating the group policy to a different Transforms when all of the group members indicate that they can support that Transforms. Perhaps A: * The GCKS could store the list of Transforms with the goal of migrating the group policy to a different Transform when all of the group members indicate that they can support that Transform. or Perhaps B: * The GCKS could store the list of Transforms with the goal of migrating the group policy to a different Transforms list when all of the group members indicate that they can support that Transforms list. --> 10) <!--[rfced] How may we clarify this sentence. Should "KEK" be plural like "TEKs"? Does the GCKS delete the TEKs and/or exclude the group members as shown below? Original: Rekeying is an operation whereby the GCKS provides replacement TEKs and KEK, deleting TEKs, and/or excluding group members. Perhaps: Rekeying is an operation whereby the GCKS provides replacement TEKs and KEKs, deletes TEKs, and/or excludes group members. --> 11) <!--[rfced] Should "a Data-Security SAs" be singular or plural in this sentence (e.g., "a new Data-Security SA" or "new Data-Security SAs")? Original: The GSA may contain a new Rekey SA and/or a new Data- Security SAs Section 4.4. Perhaps: The GSA may contain a new Rekey SA and/or a new Data- Security SA (Section 4.4). --> 12) <!-- [rfced] FYI: We updated "that with" to "with the" as follows. Original: The RESERVED field in the reconstructed Encrypted Payload header MUST be set to the value of the RESERVED field in the Encrypted Fragment payload header from the first fragment (that with Fragment Number equal to 1). Current: The RESERVED field in the reconstructed Encrypted Payload header MUST be set to the value of the RESERVED field in the Encrypted Fragment payload header from the first fragment (with the Fragment Number equal to 1). --> 13) <!-- [rfced] We added parentheses to this sentence for ease of reading. Please let us know of any objections. Original: If the message includes Delete payload for existing Data-Security SA, then after installing a new Data-Security SA the old one, identified by the Protocol and SPI fields in the Delete payload, MUST be silently deleted after waiting DEACTIVATION_TIME_DELAY interval regardless of its expiration time. Current: If the message includes a Delete payload for an existing Data-Security SA, then after installing a new Data-Security SA, the old one (identified by the Protocol and SPI fields in the Delete payload) MUST be silently deleted after waiting the DEACTIVATION_TIME_DELAY interval regardless of its expiration time. --> 14) <!-- [rfced] We have updated this sentence to use "AES CCM" (per RFC 4309) rather than "AES-CCM". Please let us know any objections. Original: Several counter-based modes of operation have been specified for ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES-CCM [RFC4309], ChaCha20-Poly1305 [RFC7634], AES-GMAC [RFC4543]) and AH (e.g., AES- GMAC [RFC4543]). Current: Several counter-based modes of operation have been specified for ESP (e.g., AES-CTR [RFC3686], AES-GCM [RFC4106], AES CCM [RFC4309], ChaCha20-Poly1305 [RFC7634], and AES-GMAC [RFC4543]) and AH (e.g., AES- GMAC [RFC4543]). --> 15) <!--[rfced] Please clarify what "literature" refers to here. Original: Group management algorithms providing forward and backward access control other than LKH have been proposed in the literature, including OFT [OFT] and Subset Difference [NNL]. Perhaps: Group management algorithms providing forward and backward access control other than LKH have been proposed in other specifications, for example, OFT [OFT] and Subset Difference [NNL]. --> 16) <!-- [rfced] May we update "if they are take place" for clarity in the sentence below? Original: For the unicast IKE SA (used for the GM registration and for the GSA_INBAND_REKEY exchanges, if they are take place) the GSK_w is computed as follows: Perhaps: For the unicast IKE SA (used for the GM registration and for GSA_INBAND_REKEY exchanges if they appear), the GSK_w is computed as follows: --> 17) <!--[rfced] Is "null termination" correct, or should it be "NUL termination"? Current: where the string "Key Wrap for G-IKEv2" is 20 ASCII characters without null termination. --> 18) <!-- [rfced] We have replaced "it" with "GM" for clarity and removed "this GM" to avoid redundancy. Please let us know if this is not correct. Original: This situation may only happen at the time the GM is registering to the group, when the GCKS is providing it with its personal key and the other keys from the key tree that are needed for this GM. Current: This situation may only happen at the time the GM is registering to the group, when the GCKS is providing the GM with its personal key and the other keys from the key tree that are needed. --> 19) <!-- [rfced] In this sentence, is GSK_e used for the Encryption Algorithm and GSK_a for the Integrity Algorithm (option A), or are GSK_e and GSK_a used for both the Encryption Algorithm and the Integrity Algorithm (option B)? Original: where GSK_e and GSK_a are the keys used for the Encryption Algorithm and the Integrity Algorithm transforms for the corresponding SA and GSK_w is a default KWK for this SA. Perhaps A: where GSK_e and GSK_a are the keys used for the Encryption Algorithm and the Integrity Algorithm transforms, respectively, for the corresponding SA and GSK_w is a default KWK for this SA. or Perhaps B: where GSK_e and GSK_a are the keys used for both the Encryption Algorithm and the Integrity Algorithm transforms for the corresponding SA and GSK_w is a default KWK for this SA. --> 20) <!-- [rfced] FYI - We have updated the following sentence to reduce the repetition of "payload" and to match use in Table 1. Please let us know any objections. Original: The Security Association - GM Supported Transforms Payload (SAg) payload declares which Transforms a GM is willing to accept. Current: The Security Association - GM Supported Transforms (SAg) payload declares which Transforms a GM is willing to accept. --> 21) <!-- [rfced] Should "Last Substruc" be "Last Substruct" or "Last Substructure" in the sentence below? Or is "Last Substruc" correct here? Original: The "Last Substruc" field in each Transform Substructure is set to 3 except for the last Transform Substructure, where it is set to 0. Perhaps: The "Last Substructure" field in each Transform Substructure is set to 3 except for the last Transform Substructure, where it is set to 0. --> 22) <!-- [rfced] May we restructure the text below as follows for readability? Current: This transform ID defines the following properties. Sequence numbers are 32-bit in size and are transmitted in the Sequence Number field of AH and ESP packets. The value of sequence numbers is not guaranteed to be unique for the duration of an SA, thus they are not suitable for replay protection. This transform ID MUST be used by the GCKS in case of multi-sender multicast Data-Security SAs utilizing protocols ESP or AH to inform the GMs that the replay protection is not expected to be possible. The GCKS MAY also use this transform ID for single-sender multicast Data-Security SAs if replay protection is not needed (e.g. it is done on application level). Perhaps: This transform ID defines the following properties: * Sequence numbers are 32 bits in size and are transmitted in the Sequence Number field of AH and ESP packets. * The value of sequence numbers is not guaranteed to be unique for the duration of an SA, thus they are not suitable for replay protection. * This transform ID MUST be used by the GCKS in the case of multi-sender multicast Data-Security SAs utilizing protocols ESP or AH to inform the GMs that the replay protection is not expected to be possible. * The GCKS MAY also use this transform ID for single-sender multicast Data-Security SAs if replay protection is not needed (e.g., it is done on the application level). --> 23) <!--[rfced] May we rephrase this sentence as shown below for clarity (i.e., remove "in these cases" to reduce redundancy)? Note that we included the lead-in sentence for context. Lead-in sentence: A single attribute of this type is included into the GSA KEK policy substructure if the initial Message ID of the Rekey SA is non-zero. Original: Note, that it is always the case if GMs join the group after some multicast rekey operations have already taken place, so in these cases this attribute will be included into the GSA policy when the GM is registered. Perhaps: Note that this is always the case if GMs join the group after some multicast rekey operations have already taken place, so this attribute will be included into the GSA policy when the GM is registered. --> 24) <!-- [rfced] We have rephrased the sentence below as follows for clarity. Please let us know any objections. Original: The GM MAY store these values and if later the GM starts receiving messages with one of these SPIs without seeing a rekey message over the current Rekey SA, this may be used as an indication, that the rekey message got lost on its way to this GM. Current: The GM MAY store these values. Later on, if the GM starts receiving messages with one of these SPIs without seeing a rekey message over the current Rekey SA, then it may be used as an indication that the rekey message got lost on its way to this GM. --> 25) <!-- [rfced] Is the space in the parentheses intentional in the text below, or should "( octet)" be updated as "(0 octet)" per the description? Note that there are two instances (Sections 4.4.3 and 4.5.3). Original: * RESERVED ( octet) - MUST be zero on transmission, MUST be ignored on receipt. --> 26) <!--[rfced] "Length" vs. "Payload Length" a) We note that Figure 16 uses "Payload Length" whereas Figures 17, 18, 19, 20, and 21 use "Length". Is this variance okay, or is an update needed to Figure 16 for consistency? b) In Section 4.5, we note "Length" in Figure 19 but "Payload Length" in the description. We updated the description to reflect "Length" as shown below. If that is not correct, please let us know. Original: Next Payload, C, RESERVED, and Payload Length fields: Comprise the IKEv2 Generic Payload Header and are defined in Section 3.2 of [RFC7296]. Current: Next Payload, C, RESERVED, and Length fields: Comprise the IKEv2 Generic Payload Header and are defined in Section 3.2 of [RFC7296]. --> 27) <!-- [rfced] May we rephrase the following text to simplify the sentence structure? Also, does "the following SPI" refer to the SPI in Figure 20? Original: For this reason two types of key bags are defined - Group Key Bag and Member Key Bag. The type is unambiguously determined by the first byte of the key bag substructure - for member key bag it is zero and for group key bag it represents the protocol number, which along with the following SPI, identify the SA associated with the keys in the bag. Perhaps: For this reason, two types of key bags are defined: Group Key Bag and Member Key Bag. The type is unambiguously determined by the first byte of the key bag substructure; for a Member Key Bag, it is zero. The Group Key Gag is represented by the protocol number, and the protocol number along with the SPI (see Figure 20) identify the SA that is associated with the keys in the bag. --> 28) <!-- [rfced] Please review Table 7 and let us know if the format appears as intended. Specifically, are the "Multi-Valued" and "Used in Protocol" columns correctly formatted? --> 29) <!-- [rfced] FYI - We rephrased the text below for better sentence flow. Please let us know of any objections. Original: If the key bag is for a Rekey SA (GIKE_UPDATE protocol), then in the GSA_AUTH, GSA_REGISTRATION and GSA_INBAND_REKEY exchanges exactly one SA_KEY attribute MUST be present. Current: If the key bag is for a Rekey SA (GIKE_UPDATE protocol), then exactly one SA_KEY attribute MUST be present in the GSA_AUTH, GSA_REGISTRATION, and GSA_INBAND_REKEY exchanges. --> 30) <!-- [rfced] In Section 4.5.3.2, since there is only one list item in this unordered list, would it be appropriate to remove the bullet and make it into a paragraph? Original: * If digital signatures are used for the GSA_REKEY message authentication then the content of the AUTH_KEY attribute is a public key used for digital signature authentication. The public key MUST be represented as DER-encoded ASN.1 object SubjectPublicKeyInfo, defined in Section 4.1.2.7 of "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280]. The algorithm field inside the SubjectPublicKeyInfo object MUST match the content of the Signature Algorithm Identifier attribute in the Group Controller Authentication Method transform. When the id-RSASSA- PSS object identifier appears in the algorithm field of the SubjectPublicKeyInfo object, then the parameters field MUST include the RSASSA-PSS-params structure. Perhaps: If digital signatures are used for the GSA_REKEY message authentication, then the content of the AUTH_KEY attribute is a public key used for digital signature authentication. The public key MUST be represented as DER-encoded ASN.1 object SubjectPublicKeyInfo, defined in Section 4.1.2.7 of [RFC5280]. The algorithm field inside the SubjectPublicKeyInfo object MUST match the content of the Signature Algorithm Identifier attribute in the Group Controller Authentication Method transform. When the id-RSASSA-PSS object identifier appears in the algorithm field of the SubjectPublicKeyInfo object, then the parameters field MUST include the RSASSA-PSS-params structure. --> 31) <!-- [rfced] The following sentence is hard to parse. Would either of the following proposals improve readability and retain the sentence's original meaning? Original: Note, that the restrictions are defined per a substructure corresponding attributes are defined for and not per whole G-IKEv2 message. Perhaps A: Note that the restrictions are defined per a substructure corresponding to the attributes that are defined and not per a whole G-IKEv2 message. or Perhaps B: Note that the restrictions are defined per a substructure for which corresponding attributes are defined and not per a whole G-IKEv2 message. --> 32) <!--[rfced] How may we update this sentence to clarify "and more these attributes MAY be present"? Perhaps "one or more SA_KEY attributes MAY be present in a GSA_REKEY exchange"? Current: For a Data-Security SA, exactly one SA_KEY attribute MUST be present. For a Rekey SA, one SA_KEY attribute MUST be present in all cases and more these attributes MAY be present in a GSA_REKEY exchange. Perhaps: For a Data-Security SA, exactly one SA_KEY attribute MUST be present. For a Rekey SA, one SA_KEY attribute MUST be present in all cases and one or more SA_KEY attributes MAY be present in a GSA_REKEY exchange. --> 33) <!--[rfced] How may we clarify this sentence? Is the sender proven to be a member of the group when the GM "decrypts and verifies the ICV"? Original: An implicit authentication can also be used, in which case, the ability of the GM to decrypt and to verify ICV of the received message proved that a sender of the message is a member of the group. Perhaps: An implicit authentication can also be used, in which case the GM decrypts and verifies the ICV of the received message to prove that a sender of the message is a member of the group. --> 34) <!-- [rfced] We have included some specific questions about the IANA text below. In addition to responding to those questions, please review all of the IANA-related updates carefully, including the IANA values in the running text, and let us know if any further updates are needed. Please refer to the following URL to view the IANA registries: <https://www.iana.org/assignments/ikev2-parameters/> a) For Tables 3-7 and 11-16, may we order the "Value" columns first to match the corresponding IANA registries? b) FYI: For Tables 11-16, we updated "Private Use" to "Reserved for Private Use" to match the corresponding IANA registries. c) Please clarify the text below. Was "new registrations" perhaps intended rather than "changes and additions to the unassigned range"? Note that there are multiple instances. Original: Changes and additions to the unassigned range of this registry are by the Expert Review Policy [RFC8126]. Perhaps: In this registry, new registrations are to be made by Expert Review [RFC8126]. d) May we update the title of the "Group-wide Policy Attributes" registry to "Group-Wide Policy Attributes" (i.e., make "wide" uppercase as it's an adjective within a hyphenated compound)? e) FYI: For clarity, we added the "Reference" column to Table 19 to show that the "Security Association" Payload Type was registered by RFC 7296. If this is not desired, please let us know. f) Is it helpful for the reader if the history of the SENDER_REQUEST_ID registration is included? If so, should an informative reference to "draft-yeung-g-ikev2-07" (e.g., "[G-IKEV2]") be added (option A)? Or if the history isn't necessary, is option B preferred? Original: The Notify type with the value 16429 was allocated earlier in the development of G-IKEv2 document in the "IKEv2 Notify Message Status Types" registry with the name SENDER_REQUEST_ID. This document renames it as follows: Perhaps A: An earlier draft of this document [G-IKEV2] registered the Notify type 16429 with the name SENDER_REQUEST_ID. Per this document, IANA has updated the "IKEv2 Notify Message Status Types" registry as follows: or Perhaps B: IANA has registered the following in the "IKEv2 Notify Message Status Types" registry: --> 35) <!-- [rfced] May we replace "so after all" with "and thus" in the sentence below for improved clarity? Current: Similarly, when other GMs will be joining the group, they will be provided with the corresponding keys, so after all, the GMs will have the following Working Key Paths: Perhaps: Similarly, when other GMs join the group, they will be provided with the corresponding keys and thus the GMs will have the following Working Key Paths: --> 36) <!-- [rfced] Abbreviations a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. b) We note that some abbreviations are expanded multiple times throughout the document. If there are no objections, we will update terms to use their abbreviations after their first expansions for consistency. One example (see the document for more examples): Group Member -> GM --> 37) <!-- [rfced] Terminology a) Please review the following terms for capitalization and let us know which form you prefer (uppercase or lowercase) for consistency. Data-Security vs. data-security [Note: Only two instances of "data-security" are lowercase; should they be uppercase?] Group Member vs. group member Group Receiver vs. group receiver Group Sender vs. group sender Group-wide policy vs. group-wide policy GSA registration exchange vs. GSA_REGISTRATION exchange Header vs. header (when referring to specific headers, e.g., Payload Header vs. IKE header) Key Bag vs. key bag Key information vs. key information Key Wrap Algorithm vs. key wrap algorithm Notify Message vs. Notify message vs. notify message Security Association vs. security association [Note: should the security association policy be uppercase (e.g., "Security Association policy")? Transform(s) vs. transform(s) Transform ID vs. transform ID b) We note that the following terms are used inconsistently. Please review and let us know which form you prefer to use throughout the document. Data-Security GSA TEK vs. GSA TEK vs. Data-Security SA policy (GSA TEK) [Note: Are any of these terms the same?] group key management vs. group key management protocol Multicast Security (MSEC) Group Key Management Architecture vs. Multicast Security (MSEC) key management architecture c) FYI: We updated the text to reflect the forms on the right for consistency. Please let us know of any objections. G-IKEv2 Rekey -> G-IKEv2 rekey GKCS -> GCKS group key bag -> Group Key Bag group security association -> Group Security Association GSA Policy -> GSA policy= IKEv2 Intermediate exchange -> IKEv2 Intermediate Exchange (per RFC 9242) member Key Bag and member key bag -> Member Key Bag NO_PROPOSAL_CHOSEN Notification -> NO_PROPOSAL_CHOSEN notification protocol ID -> Protocol ID Rekey message -> rekey message rekey SA -> Rekey SA Security Association Payload -> Security Association payload (per RFC 7296) Secure Password authentication -> secure password authentication (per RFC 6467) --> 38) <!-- [rfced] Some figures and tables were updated during the formatting process and do not have titles. Would you like to add titles to the figures and tables below for consistency throughout the document? If so, please let us know the desired text. Current: Figure 10 Figure 15 Figure 16 Figure 24 Figure 27 Figure 31 Tables 3-8 Tables 11-25 --> 39) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the term "man-in-the-middle" should be updated. --> Thank you. Madison Church and Karen Moore RFC Production Center On Sep 11, 2025, at 7:14 PM, RFC Editor via auth48archive <auth48archive@rfc-editor.org> wrote: *****IMPORTANT***** Updated 2025/09/11 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9838.xml https://www.rfc-editor.org/authors/rfc9838.html https://www.rfc-editor.org/authors/rfc9838.pdf https://www.rfc-editor.org/authors/rfc9838.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9838-diff.html https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9838-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9838 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9838 (draft-ietf-ipsecme-g-ikev2-23) Title : Group Key Management using IKEv2 Author(s) : V. Smyslov, B. Weis WG Chair(s) : Yoav Nir, Tero Kivinen Area Director(s) : Deb Cooley, Paul Wouters -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
