Hi Madison and Karen,
sorry for the follow-up message, just want to document one more issue,
I found (the numeration continues):
48) Section 9.1, list item #3.
The table for GSA Attributes incorrectly indicates the "Unassigned" range -
value "4" is missing from both assigned values and from unassigned range.
CURRENT:
|Unassigned |5-16383 | |
NEW:
|Unassigned |4-16383 | |
Note that the IANA registry page contains the same incorrect table.
Regards,
Valery.
> Hi Madison and Karen,
>
> thank you, please find my answers inline. I have not yet reviewed all the
> changes (via diff)
> and have not check whether IANA Considerations section matches IANA page.
> The amount of changes is significant, so I plan to do this after you process
> this message.
>
> Note that my co-author (Brian Weis) may express his own opinion on some
> topics.
>
> > 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.
> > -->
>
> Confirmed.
>
>
> > 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)
> > -->
>
> This is OK.
>
>
> > 3) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search. -->
>
> multicast
> security
> IPsec
> GDOI
> MSEC
>
>
> > 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).
> > -->
>
> I'm not sure I understand the visual effect of <aside> element (I guess this
> is an xml2rfc v3 feature).
> Can you point me to RFCs that use this element?
>
> And do you have some parts of this document in mind that
> this element can be useful for?
>
>
> > 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]).
> > -->
>
> Fine with me, thank you..
>
>
> > 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].
> > -->
>
> No, this makes it meaningless. I seem to guess what the problem
> with the sentence is (the lack of article, as my usual problem),
> but in this case the correct change would be:
>
> NEW:
> G-IKEv2 MAY also use TCP transport for the IKE SA used for registration
> (which is unicast),
> 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.
>
> I think that the description of HDR should
> match that in RFC 7296 ("IKE header (not a payload)".
>
> Regarding SK I prefer the description to be:
>
> NEW:
> "Encrypted and Authenticated (also known as Encrypted)"
>
> The reason is that this payload is almost always referred to as
> "Encrypted" (even in RFC7296), while it is officially named
> "Encrypted and Authenticated". This document also
> refers to this payload to as "Encrypted", thus we should
> only clarify that these names define the same payload.
>
>
> > 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.
>
> Yes, please change the name in the Table 1 of to match that in the Table 18.
>
> CURRENT:
> Identification - Group
>
> NEW:
> Group Identification
>
>
> > Group Identification (IDg) vs.
>
> This is the correct payload name.
>
>
> > Group ID (IDg) vs.
>
> I found a single occurrence of "Group ID (IDg)" - in Section 2.2 below Table
> 1:
>
> CURRENT:
> Group ID (IDg):
>
> NEW:
> Group Identification (IDg):
>
>
> > group IDg vs.
>
> I found a single occurrence of "group IDg" - in Section 2.3.2:
>
> CURRENT:
> The group member SHOULD notify the GCKS by sending
> IDg and the Notify type NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED as
> shown below. In this case, the GCKS MUST remove the GM from the
> group IDg.
>
> Please, update this text as follows:
>
> NEW:
> The group member SHOULD notify the GCKS by sending
> IDg and the Notify type NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED as
> shown below. In this case, the GCKS MUST remove the GM from the
> group denoted in IDg.
>
>
> > group ID
>
> I found a single occurrence of "group ID" - in Section 4.7.1:
>
> Please, update this para as follows:
>
> CURRENT:
> INVALID_GROUP_ID (45) is a new error type notification that indicates
> that the group ID sent during the registration process is invalid.
>
> NEW:
> INVALID_GROUP_ID (45) is a new error type notification that indicates
> that the IDg payload sent during the registration process denotes invalid
> group.
>
> > -->
>
>
> > 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.
> > -->
>
> I propose the following text instead:
>
> NEW:
> This policy describes one or more Data-Security SAs (TEK), zero or one
> Rekey SA (KEK),
> and zero or one Group-wide (GW) policy.
>
> I realize that TEK is still in a singular form, but I hope this is acceptable.
> Let me know if this must be changed by all means.
>
>
> > 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.
> > -->
>
> I propose the following clarification:
>
> NEW:
> * The GCKS could store the list of transforms with the goal of
> migrating the group policy from the current set of transforms to
> a different one once all of the group members indicate that they
> can support transforms from the new set.
>
>
> > 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.
> > -->
>
> There may be several TEKs (one or more), but only one KEK.
> Perhaps:
>
> NEW:
> Rekeying is an operation whereby the GCKS provides
> replacement TEK(s) and KEK, deleting TEK(s), and/or
> excluding 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).
> > -->
>
> There may be zero or more Data-Security SAs but no more than one Rekey SA,
> and at list one SA of any type must be present. Perhaps:
>
> NEW:
> The GSA may contain a new Rekey SA and/or new Data-
> Security SA(s) 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).
> > -->
>
> This change is fine, thank you.
>
>
> > 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.
> > -->
>
> This change is fine, thank you.
>
>
> > 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]).
> > -->
>
> Hmm, obviously, I should have no objections to this as RFC 4309 uses this form
> but actually this is a big surprise for me: the lack of consistency in naming
> :-)
>
> And a number of RFCs related to IPsec (I suspect there are others too)
> actually use "AES-CCM" form
> (RFC8247, RFC7321). Thus, I have no position and rely on AD's decision on
> this.
>
>
> > 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].
> > -->
>
> I think we may change it to:
>
> NEW:
> Group management algorithms providing forward and backward access
> control other than LKH have also been proposed,
> 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:
> > -->
>
> Yes, thank you.
>
>
> > 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.
> > -->
>
> This text is borrowed verbatim from RFC 7296 (Section 2.15),
> thus I believe should remain unchanged.
>
>
> > 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.
> > -->
>
> I'm fine with this change, thank you.
>
>
> > 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.
> > -->
>
> Option A is correct.
>
>
> > 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.
> > -->
>
> No objections, thank you.
>
>
> > 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.
> > -->
>
> The original text is correct. It refers to the field name (weird, I agree),
> defined in RFC 7296, Section 3.3.2.
>
>
> > 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).
> > -->
>
> Actually, only two first bullet define the properties, the last two
> just explain how to use this transform ID. I propose instead the following
> variants.
>
> Option A - split para and do not add list:
>
> NEW (Option A):
> 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 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).
>
> Option B - use list for properties only:
>
> NEW (Option B):
> 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 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).
>
> I have no preferences, but perhaps option B looks a bit neater.
>
>
> > 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.
> > -->
>
> I think it can be rephrased for clarity:
>
> NEW:
> Note that it is always true if a GM joins the group after some
> multicast rekey operations have already taken place in this group.
> In this case 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.
> > -->
>
> This change is OK, thank you.
>
>
> > 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.
> > -->
>
> This is a typo, it must be:
>
> NEW:
> * RESERVED (1 octet): MUST be zero on transmission and MUST be ignored
> on receipt.
>
> in both places ("1 octet" is the size of the field).
>
> I also noticed that in Section 4.4.3 the style of field descriptions differs
> from that in other places - in Section 4.4.3 a description starts on the same
> line as the field name, while in all other places it starts on the next line.
> Can we make this consistent across the document?
>
>
> > 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?
>
> Thank you for bringing this to my attention.
>
> This variance is OK (but see below). Figure 16 depicts a payload,
> generic payload header is defined in Section 3.2 of RFC 7296
> and the length there is denoted as "Payload Length".
> Other figures (except for 19) define various substructures inside
> payloads that are not payloads themselves and use
> more generic "Length" name for the field.
>
> However, Figure 19 also depicts a payload, but this is related to the next
> item...
>
>
> > 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].
> > -->
>
> Since Figure 19 depicts a payload, the correct name of the field is "Payload
> Length".
>
> Please, revert the above change and also change the name in the figure
> from "Length" to "Payload Length":
>
> NEW:
> | Next Payload |C| RESERVED | Payload Length |
>
>
> > 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.
> > -->
>
> I think that this text hides the point that the first byte of key bag
> substructure
> allows to distinguish between member key bag and group key bag (and there
> is also a typo "Group Key Gag"). Instead, I propose the following change
> (based on your text):
>
> NEW:
> 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 and for a Group
> Key Bag it is a protocol number, which is always non-zero.
> For a Group Key Bag the protocol number along with the SPI (see Figure 20)
> identify the SA that is associated with the keys in this 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?
> > -->
>
> The format is correct and is intentional. The idea is that we actually have
> 2 lines for SA_KEY - in case in is used in GIKE_UPDATE it is multi-valued,
> in case it is used in AH and ESP - it is single-valued.
>
> The same format is used in Table 15.
>
> We discussed this with IANA and they created the table with exactly
> this format.
>
>
> > 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.
> > -->
>
> Fine, thank you.
>
>
> > 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.
> > -->
>
> I'd rather keep the list even that it is redundant here - it shows that
> the content of the AUTH_KEY Attribute depends on authentication method,
> even that the current document defines only one.
>
> Perhaps we can add a bullet here to make using list justified:
>
> NEW (a new bullet in the list):
> * In case of implicit authentication the AUTH_KEY Attribute is not used
> and MUST be absent (see Section 2.4.1).
>
>
> (note, that this is not a new requirement, this is only a paraphrase
> of what the last sentence in 2.4.1 says).
>
>
> > 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.
> > -->
>
> Option B is correct, please use it to improve readability.
>
>
> > 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.
> > -->
>
> I would propose a different text change (also relates to item 42d below):
>
> NEW:
> For a Data-Security SA, exactly one SA_KEY attribute MUST be
> present. For a Rekey SA, at least one SA_KEY attribute MUST be present
> and, in case of GSA_REKEY pseudo-exchange, additional SA_KEY attributes
> MAY be present.
>
>
> > 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.
> > -->
>
> This is not incorrect, but the original text tries to stress that
> the authentication is implicit: the receiver will decrypt
> the message and verify its ICV just to get this message
> for application and not to (explicitly) authenticate the sender.
> The proposed text sounds like this is the goal.
>
> Perhaps the following text is clearer:
>
> NEW:
> An implicit authentication can also be used, in which case,
> the ability of the GM to decrypt and to verify ICV of
> incoming messages is used as a proof that the sender
> knows group keys and therefore 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?
>
> Yes.
>
>
> > b) FYI: For Tables 11-16, we updated "Private Use" to "Reserved
> > for Private Use" to match the corresponding IANA registries.
>
> OK, thank you.
>
>
> > 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].
>
> Perhaps use even simpler form?
>
> NEW (proposed):
> The registration policy for this registry is 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)?
>
> Sure.
>
>
> > 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.
>
> I don't think this is necessary, because the text above says that this
> definition
> is updated and not created. In IPsec documents we usually omit "Reference"
> column in IANA considerations, the IANA kindly adds it for us, let us keep
> this tradition :-)
>
>
> > 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:
> > -->
>
> I prefer option A. This name existed in IANA registry for decade,
> so it is better to keep the history. Just one minor suggestion -
> can we be more specific and say "renamed" instead of "updated"?
>
> NEW (proposed):
> An earlier draft of this document [G-IKEV2] registered the Notify
> type 16429 in the "IKEv2 Notify Message Status Types" registry with
> the name SENDER_REQUEST_ID. Per this document,
> IANA has renamed it as follows:
>
>
> > 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:
> > -->
>
> No objections.
>
>
> > 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.
>
> OK.
>
>
> > 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
> > -->
>
> No objections.
>
>
> > 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?]
>
> Please keep them as is - these occurrences are not related to SA,
> but to keys and to subsystem. I think it is OK that they are lowercase.
>
>
> > Group Member vs. group member
> > Group Receiver vs. group receiver
> > Group Sender vs. group sender
>
> For these please use lowercase form (unless in captions or when abbreviation
> is expanded).
>
>
> > Group-wide policy vs. group-wide policy
>
> I believe the current usage of this term is correct - uppercase
> form is used when abbreviation is given, otherwise lowercase form is used.
>
>
> > GSA registration exchange vs. GSA_REGISTRATION exchange
>
> It's OK, the former is just a clarification of the purpose of exchange,
> the latter is an IANA-given name of this exchange.
>
>
> > Header vs. header (when referring to specific headers, e.g., Payload
> > Header vs. IKE header)
>
> Please use lowercase form (unless it is "Authentication Header" where it must
> be uppercase).
>
>
> > Key Bag vs. key bag
>
> I believe the current use of this term is mostly correct - lowercase form is
> used
> unless this is a name of some structure (like Group Key Bag), in which case
> an uppercase form is used.
>
> There is one place that violates this rule, please correct.
>
> Section 4.5:
>
> CURRENT:
> Key Bags (variable):
> A set of Key Bag substructures.
>
> NEW:
> Key Bags (variable):
> A set of key bag substructures.
>
>
> > Key information vs. key information
>
> Please use lowercase form everywhere.
>
>
> > Key Wrap Algorithm vs. key wrap algorithm
>
> I believe the current use is correct - uppercase form is used
> only as a name of corresponding transform, otherwise lowercase
> form is used.
>
>
> > Notify Message vs. Notify message vs. notify message
>
> Please, make the following changes:
>
> Section 4.7
>
> CURRENT:
> There are additional Notify Message types introduced by G-IKEv2 to
> communicate error conditions and status (see Section 9).
>
> NEW:
> There are additional Notify Message types introduced by G-IKEv2 to
> communicate error conditions and status (see Section 9).
>
>
> Section 2.3.3
>
> CURRENT:
> A GM intending to emit data traffic MUST send a
> GROUP_SENDER Notify message type.
>
> NEW:
> A GM intending to emit data traffic MUST send a
> GROUP_SENDER notification.
>
>
> Section 2.3.4 (3 instances)
>
> CURRENT:
> If the GCKS fails to authorize the GM, it
> responds with an AUTHORIZATION_FAILED Notify message type. The GCKS
> may also respond with an INVALID_GROUP_ID notify message if the
> requested group is unknown to the GCKS or with an REGISTRATION_FAILED
> notify message if there is a problem with the requested group (e.g.,
> if the capacity of the group is exceeded).
>
> NEW:
> If the GCKS fails to authorize the GM, it
> responds with an AUTHORIZATION_FAILED notification. The GCKS
> may also respond with an INVALID_GROUP_ID notification if the
> requested group is unknown to the GCKS or with an REGISTRATION_FAILED
> notification if there is a problem with the requested group (e.g.,
> if the capacity of the group is exceeded).
>
>
> (all to be aligned with RFC 7296, which mostly use "notification")
>
>
> > Security Association vs. security association
>
> Please use only uppercase form (as per RFC 7296).
>
>
> > [Note: should the security association policy be uppercase
> > (e.g., "Security Association policy")?
>
> Yes.
>
>
> > Transform(s) vs. transform(s)
> > Transform ID vs. transform ID
>
> These are related. Please use "Transform Type(s)" and "Transform ID(s)"
> (all in uppercase), but "transform(s)" (lowercase) otherwise.
> There seems to be quite a lot of changes, sorry :-(
>
>
> > 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)
> > -->
>
> OK, thank you.
>
>
> > 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
>
> I think that numbering of these figures is not needed.
> In RFC 7296 similar figures (Sections 2.14, 2.15) are not numbered.
>
>
> > Figure 16
> > Figure 24
> > Figure 27
>
> This figures have titles. I believe they are listed here by mistake.
>
>
> Figure 23 has no title.
> Please add the following title:
>
> NEW:
> Figure 23: Example of a KD Payload
>
>
> Figure 26 has no title.
> Please add the following title:
>
> NEW:
> Figure 26: Key Paths for all GMs
>
>
> Figure 30 has no title.
> Please add the following title:
>
> NEW:
> Figure 30: Key Paths for all GMs after Exclusion of a GM
>
>
> > Figure 31
>
> Figure 31 is missing in the document. I believe it is listed here by mistake.
>
>
> > Tables 3-8
>
> For Table 3 add the following title:
>
> NEW:
> Table 3: Group Controller Authentication Method Transform IDs
>
>
> For Table 4 add the following title:
>
> NEW:
> Table 4: Key Wrap Algorithm Transform IDs
>
>
> For Table 5 add the following title:
>
> NEW:
> Table 5: GSA Attributes
>
>
> For Table 6 add the following title:
>
> NEW:
> Table 6: GW Policy Attributes
>
>
> For Table 7 add the following title:
>
> NEW:
> Table 7: Group Key Bag attributes
>
>
> For Table 8 add the following title:
>
> NEW:
> Table 8: Member Key Bag attributes
>
>
> > Tables 11-25
>
> I don't think these tables need titles. Looking at recent RFCs in IPsecME WG,
> all tables in IANA considerations are untitled. I'd rather they don't have
> numbers too,
> but as far as I know this is unavoidable for tables with the current xml2rfc
> version :-)
>
> > -->
>
>
> > 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. -->
>
> I believe we can use "person-in-the-middle" instead.
> I failed to find other issues with inclusive language guide in the text.
>
> I also have some issues.
>
> 40) Not all new IANA registries added to
> https://www.iana.org/assignments/ikev2-parameters/ikev2-
> parameters.xhtml
> are properly filled in. In particular, the "Reserved for Private Use" ranges
> in the "GSA Attributes",
> the "Group-wide Policy Attributes" and the "Member Key Bag Attributes"
> registries do not
> reference to this document (while the "Group Key Bag Attributes" registry
> does).
>
> 41) A typo in Appendix A.3:
>
> CURRENT:
> If the GCKS performs a simple SA rekey without changing group
> membership, it will only send a Group Key Gag in the KD payload with
> a new SA key encrypted with the default KWK.
>
> NEW:
> If the GCKS performs a simple SA rekey without changing group
> membership, it will only send a Group Key Bag in the KD payload with
> a new SA key encrypted with the default KWK.
>
> (should be "Key Bag" instead of "Key Gag").
>
> 42) The draft incorrectly calls the GSA_REKEY pseudo-exchange
> as "GSA_REKEY exchange" in few places. This is the result of careless
> editing from my side, this is better to fix:
>
> a) Section 4.5.2
>
> CURRENT:
> (*): Multiple SA_KEY attributes may only appear for the GIKE_UPDATE
> protocol in the GSA_REKEY exchange if the GCKS uses the group key
> management method that allows excluding GMs from the group (like
> LKH).
>
> NEW:
> (*): Multiple SA_KEY attributes may only appear for the GIKE_UPDATE
> protocol in the GSA_REKEY pseudo-exchange if the GCKS uses the group key
> management method that allows excluding GMs from the group (like
> LKH).
>
> b) Section 4.5.2
>
> CURRENT:
> In the GSA_REKEY
> exchange, at least one SA_KEY attribute MUST be present, and more
> attributes MAY be present (depending on the key management method
> employed by the GCKS).
>
> NEW:
> In the GSA_REKEY
> pseudo-exchange, at least one SA_KEY attribute MUST be present, and more
> attributes MAY be present (depending on the key management method
> employed by the GCKS).
>
>
> c) Section 4.5.3.3
>
> CURRENT:
> This attribute MUST NOT appear in the rekey operations (in the
> GSA_REKEY or GSA_INBAND_REKEY exchanges).
>
> NEW:
> This attribute MUST NOT appear in the rekey operations (in the
> GSA_REKEY pseudo-exchange or in the GSA_INBAND_REKEY exchange).
>
>
> d) Section 5 (see also item 32)
>
> CURRENT:
> (2): 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.
>
> NEW:
> (2): 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 pseudo-exchange.
>
>
> e) Section 5
>
> CURRENT:
> The AUTH_KEY attribute MUST be present in the
> GSA_REKEY exchange if the GCKS employs an authentication method
> based on digital signatures and wants to change the public key
> for the following multicast rekey operations.
>
> NEW:
> The AUTH_KEY attribute MUST be present in the
> GSA_REKEY pseudo-exchange if the GCKS employs an authentication
> method
> based on digital signatures and wants to change the public key
> for the following multicast rekey operations.
>
>
> 43) Section 1, typo, missing hyphen in "pseudo-exchange".
>
> CURRENT:
> Refreshing the group keys can be performed either in a unicast mode
> via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a
> specific IKE SA between a GM and a GCKS or in a multicast mode with
> the GSA_REKEY pseudo exchange (Section 2.4.1) when new keys are being
> distributed to all GMs.
>
> NEW:
> Refreshing the group keys can be performed either in a unicast mode
> via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a
> specific IKE SA between a GM and a GCKS or in a multicast mode with
> the GSA_REKEY pseudo-exchange (Section 2.4.1) when new keys are being
> distributed to all GMs.
>
>
> 44) Please change "Generic Payload" to "generic payload" (make lowercase)
> to match RFC 7296 (2 instances in the document - in Sections 4.4 and 4.5).
>
>
> 45) Please change "Payload Header" to "payload header" (make lowercase)
> to match RFC 7296 (1 instance in Section 2.4.1.1.)
>
>
> 46) Section 4.4
>
> CURRENT:
> The GSA payload is used by the GCKS to assert security attributes for
> both Rekey and Data-Security SAs.
>
> NEW:
> The Group Security Association (GSA) payload is used by the GCKS to assert
> security attributes for
> both Rekey and Data-Security SAs.
>
>
> 47) Section 4.4
>
> CURRENT:
> The Security Association payload fields are defined as follows:
>
> NEW:
> The Group Security Association payload fields are defined as follows:
>
>
> I also have a proposal. The draft references
> draft-ietf-ipsecme-ikev2-qr-alt-10,
> which is currently in the RFC Editor queue in the state "AUTH48".
> While it is only informatively referenced, I think that it would be better if
> it is referenced
> as RFC and not as I-D. Can you please make this possible (I think it would
> require adding
> draft-ietf-ipsecme-ikev2-qr-alt-10 to C532 cluster).
>
> Regards,
> Valery.
>
>
> > Thank you.
> >
> > Madison Church and Karen Moore
> > RFC Production Center
> >
> >
> > On Sep 11, 2025, at 7:14 PM, RFC Editor via auth48archive
> > <[email protected]> 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
> >
> > * [email protected] (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).
> >
> > * [email protected], 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,
> > [email protected] 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 -- [email protected]
> > To unsubscribe send an email to [email protected]
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
