IKEv2 support for per-resource Child SAs
draft-ietf-ipsecme-multi-sa-performance-08

[Ballot comment]
```
19   Version 2 (IKEv2) to support the negotiation of multiple Child SAs
```

Expand SA on first use, even though the term is defined in RFC7296?

Its possible TSi/TSr might also be helpful to expand for readers.

[Ballot comment]
My comments are split between COMMENTs and NITs.

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

From an operational perspective, the shepherd write-up brought up the question of how this draft would be operationalized. In other words, is there an augment of the existing YANG model planned that would update the model to add the ability to configure multiple SAs? If not, how does a user specify their interest in enabling this feature?

No reference entries found for these items, which were mentioned in the text:
[TBD2] and [TBD1].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Reference [RFC6982] to RFC6982, which was obsoleted by RFC7942 (this may be on
purpose).

Section 1.2, paragraph 1
> n initial IKEv2 exchange is used to setup an IKE SA and the initial Child SA.
>                                    ^^^^^
The verb "set up" is spelled as two words. The noun "setup" is spelled as one.

Section 2, paragraph 1
> he Exchange negotiating the Child SA (eg IKE_AUTH or CREATE_CHILD_SA). If thi
>                                      ^^
The abbreviation "e.g." (= for example) requires two periods.

Section 4, paragraph 2
> hild SAs. If per-CPU packet trigger (eg SADB_ACQUIRE) messages are implemente
>                                      ^^
The abbreviation "e.g." (= for example) requires two periods.

Section 4, paragraph 3
> ed on the trigger TSi entry, an implementations can select the most optimal t
>                              ^^^^^^^^^^^^^^^^^^
The plural noun "implementations" cannot be used with the article "an". Did you
mean "an implementation" or "implementations"?

Section 5.1, paragraph 5
>  identifier in their packet trigger (eg SADB_ACQUIRE) message from the SPD t
>                                      ^^
The abbreviation "e.g." (= for example) requires two periods.

Section 6, paragraph 1
> lthough having a very large number (eg hundreds or thousands) of SAs may slo
>                                    ^^
The abbreviation "e.g." (= for example) requires two periods.

Section 6, paragraph 2
> he inbound SA and outbound SA independently from each other. It is likely tha
>                              ^^^^^^^^^^^^^^^^^^
The usual collocation for "independently" is "of", not "from". Did you mean
"independently of"?

Section 6, paragraph 4
> elonging to a specific resource. The notify data SHOULD NOT be an identifier
>                                  ^^^^^^^^^^
The verb "notify" does not usually follow articles like "The". Check that
"notify" is spelled correctly; using "notify" as a noun may be non-standard.

Section 8, paragraph 4
> the ESP flow, to a specific Q or CPU e.g ethtool ntuple configuration. The SP
>                                      ^^^
The abbreviation "e.g." (= for example) requires two periods.

[Ballot discuss]
Be ye not afraid -- see https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ on handling ballots, especially DISCUSS ballots...

A DISCUSS is a request to have a discussion, and this is especially true in this case, because my mental model is somewhat hazy here...

The document talks about negotiating multiple "Child SAs with the same Traffic Selectors". In my mental model, this looks sort of analogous to multiple parallel paths.
The document doesn't seem to discuss how implementations should share traffic across these "paths" -- should it do something like ECMP and hash  to try and keep packets in a flow tied to the same CPU? Or is this something that is done automatically by the OS already (e.g because the existing L3 logic would just view these as parallel links) and it already knows what to do? Or is this something that IPSEC implementations handle themselves? Or is my mental model so broken that my question doesn't even make sense?


The document also says that "if an implementation finds it needs to encrypt a packet but the current CPU does not have the resources to encrypt this packet, it can relay that packet to a specific CPU that does have the capability to encrypt the packet, although this will come with a performance penalty.". Cool... but does this lead to the potential of out of order packets? Is that what the "this will come with a performance penalty" is implying (in which case I'd suggest being a bit more explicit).

[Ballot comment]
I think that this document is both cool and useful -- my discuss ballot is because I'd like to better understand how this works....

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-ipsecme-multi-sa-performance-06

Thank you for the work put into this document.

Please find some non-blocking COMMENT points.

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

###COMMENTS:
##generic comments:
The abstract implies the possibility of utilizing various resources to enhance performance for the same traffic selector, yet the document consistently mentions only the CPU. If multiple CPUs are indeed the sole resource envisaged for the child SAs associated with a single traffic selector, it would be advantageous for the document to specify this more clearly in the abstract. Generally, the term "resource" encompasses a broad range of elements within networking (i.e. bandwidth, QoS queues, optical paths, ECMP paths, etc); however, in this draft, it appears to specifically refer to computing resources. 

I was on the verge of making the ballot a DISCUSS because section 2 talking about performance bottlenecks and detailing that some state can not be shared without impacting performance justifies the existence of this rfc-to-be. While it is well-understood when using different CPUs (sequence numbers etc), but it is not so simple to understand what the performance benefit is when separate queues are the resource differences. Maybe i misunderstood how this operates together in symbiose? or misunderstood the word queue (it may have different meaning in IPsec then on L3-network-interfaces)

##detailed comments
134 1.2.  Terminology

This section only has the pre-existing terminology. I was wondering if terms like the new SA_RESOURCE_INFO should be mentioned to have everything documented in a single place
This section could be a good place to extend more explicit on what is exactly meant with the term resource in the context of this draft.
should SADB_ACQUIRE be mentioned? SPD?

141 2.  Performance bottlenecks

Here is the header 'performance bottlenecks'. Only a single bottleneck is mentioned in the section. Maybe the section title can be phrased in such that it covers the content more explicit for readability. For a network generalist it is unclear which other bottlenecks exist.

143   There are a number of practical reasons why most implementations have
144   to limit a Child SA to only one specific hardware resource, but a key
145   limitation is that sharing the cryptographic state, counters and
146   sequence numbers between multiple CPUs that are trying to use these
147   shared states at the same time is not feasible without a significant
148   performance penalty.  There is a need to negotiate and establish
149   multiple Child SAs with identical TSi/TSr on a per-resource basis.

This phrase is rather long and not so easy to digest. What about this re-edit. I also took liberty to expand on TSi/TSr as a first time use:

"
There are several pragmatic reasons why most implementations must restrict a Child Security Association (SA) to a single specific hardware resource. A primary limitation arises from the challenges associated with sharing cryptographic states, counters, and sequence numbers among multiple CPUs. When these CPUs attempt to simultaneously utilize shared states, it becomes impractical to do so without incurring a significant performance penalty. It is necessary to negotiate and establish multiple Child Security Associations (SAs) with identical Traffic Selector initiator (TSi) and Traffic Selector responder (TSr) on a per-resource basis."

168   Upon installation, each resource-specific Child SA is associated with
169   an additional local selector, such as CPU or queue.  These resource-
170   specific Child SAs MUST be negotiated with identical Child SA
171   properties that were negotiated for the initial Child SA.  This

In section 2 is written that for improved performance "the cryptographic state, counters and sequence numbers between multiple CPUs" is difficult to share. THis is trivial to understand with CPUs, but how does that explicit correlate with queues?

192   There are various considerations that an implementation can use to
193   determine the best way to install multiple Child SAs.

The best 'way' or the best 'procedure'?

195   A simple distribution could be to install one additional Child SA on
196   each CPU.  An implementation MAY ensure that one Child SA can be used

A distribution of what? is this referring to an implementation?

213   When the number of queue or CPU resources are different between the
214   peers, the peer with the least amount of resources may decide to not
215   install a second outbound Child SA for the same resource as it will
216   never use it to send traffic.  However, it MUST install all inbound
217   Child SAs as it has committed to receiving traffic on these
218   negotiated Child SAs.

Is there risk to create an overload of SAs for a single resource?

224   Section 2.9.  Based on the trigger TSi entry, an implementations can

s/implementations/implementation/

243   All multi-octet fields representing integers are laid out in big
244   endian order (also known as "most significant byte first", or
245   "network byte order").

is this necessary to be explained? is that not part of what RFC7296 specifies anyway?

261   *  Protocol ID (1 octet) - MUST be 0.  MUST be ignored if not 0.
263   *  SPI Size (1 octet) - MUST be 0.  MUST be ignored if not 0.

and

280   *  Protocol ID (1 octet) - MUST be 0.  MUST be ignored if not 0.
282   *  SPI Size (1 octet) - MUST be 0.  MUST be ignored if not 0.

no code-point reservations needed for experimental? or future use?

267   *  Resource Identifier (optional).  This opaque data may be set to
268       convey the local identity of the resource.

should there be no restrictions on what can be considered as a local identity?
What of this identity is an extremely long blockchain blob? what would happen? is that allowed?

290   Implementations supporting per-CPU SAs SHOULD extend their local SPD

later in the text is the it is mentioned per-queue also... Does this behave differently then the per-CPU principle?


344   An implementation that does not accept any further resource specific
345   Child SAs MUST NOT return the NO_ADDITIONAL_SAS error because this
346   can be interpreted by the peer that no other Child SAs with different
347   TSi/TSr are allowed either.  Instead, it MUST return TS_MAX_QUEUE.

should anything be mentioned about state kept on the implementation that has no more resources?
What if the remote side tries to open 10M SAs? (is it an attack vector?)

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-ipsecme-multi-sa-performance-06

Thank you for the work put into this document.

Please find some non-blocking COMMENT points.

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

###COMMENTS:
##generic comments:
The abstract implies the possibility of utilizing various resources to enhance performance for the same traffic selector, yet the document consistently mentions only the CPU. If multiple CPUs are indeed the sole resource envisaged for the child SAs associated with a single traffic selector, it would be advantageous for the document to specify this more clearly in the abstract. Generally, the term "resource" encompasses a broad range of elements within networking (i.e. bandwidth, QoS queues, optical paths, ECMP paths, etc); however, in this draft, it appears to specifically refer to computing resources. 

I was on the verge of making the ballot a DISCUSS because section 2 talking about performance bottlenecks and detailing that some state can not be shared without impacting performance justifies the existence of this rfc-to-be. While it is well-understood when using different CPUs (sequence numbers etc), but it is not so simple to understand what the performance beneficial is when separate queues are the resource differences. Maybe i misunderstood how this operates together in symbiose? or misunderstood the word queue (it may have different meaning in IPsec then on L3-network-interfaces)

##detailed comments
134 1.2.  Terminology

This section only has the pre-existing terminology. I was wondering if terms like the new SA_RESOURCE_INFO should be mentioned to have everything documented in a single place
This section could be a good place to extend more explicit on what is exactly meant with the term resource in the context of this draft.
should SADB_ACQUIRE be mentioned? SPD?

141 2.  Performance bottlenecks

Here is the header 'performance bottlenecks'. Only a single bottleneck is mentioned in the section. Maybe the section title can be phrased in such that it covers the content more explicit for readability. For a network generalist it is unclear which other bottlenecks exist.

143   There are a number of practical reasons why most implementations have
144   to limit a Child SA to only one specific hardware resource, but a key
145   limitation is that sharing the cryptographic state, counters and
146   sequence numbers between multiple CPUs that are trying to use these
147   shared states at the same time is not feasible without a significant
148   performance penalty.  There is a need to negotiate and establish
149   multiple Child SAs with identical TSi/TSr on a per-resource basis.

This phrase is rather long and not so easy to digest. What about this re-edit. I also took liberty to expand on TSi/TSr as a first time use:

"
There are several pragmatic reasons why most implementations must restrict a Child Security Association (SA) to a single specific hardware resource. A primary limitation arises from the challenges associated with sharing cryptographic states, counters, and sequence numbers among multiple CPUs. When these CPUs attempt to simultaneously utilize shared states, it becomes impractical to do so without incurring a significant performance penalty. It is necessary to negotiate and establish multiple Child Security Associations (SAs) with identical Traffic Selector initiator (TSi) and Traffic Selector responder (TSr) on a per-resource basis."

168   Upon installation, each resource-specific Child SA is associated with
169   an additional local selector, such as CPU or queue.  These resource-
170   specific Child SAs MUST be negotiated with identical Child SA
171   properties that were negotiated for the initial Child SA.  This

In section 2 is written that for improved performance "the cryptographic state, counters and sequence numbers between multiple CPUs" is difficult to share. THis is trivial to understand with CPUs, but how does that explicit correlate with queues?

192   There are various considerations that an implementation can use to
193   determine the best way to install multiple Child SAs.

The best 'way' or the best 'procedure'?

195   A simple distribution could be to install one additional Child SA on
196   each CPU.  An implementation MAY ensure that one Child SA can be used

A distribution of what? is this referring to an implementation?

213   When the number of queue or CPU resources are different between the
214   peers, the peer with the least amount of resources may decide to not
215   install a second outbound Child SA for the same resource as it will
216   never use it to send traffic.  However, it MUST install all inbound
217   Child SAs as it has committed to receiving traffic on these
218   negotiated Child SAs.

Is there risk to create an overload of SAs for a single resource?

224   Section 2.9.  Based on the trigger TSi entry, an implementations can

s/implementations/implementation/

243   All multi-octet fields representing integers are laid out in big
244   endian order (also known as "most significant byte first", or
245   "network byte order").

is this necessary to be explained? is that not part of what RFC7296 specifies anyway?

261   *  Protocol ID (1 octet) - MUST be 0.  MUST be ignored if not 0.
263   *  SPI Size (1 octet) - MUST be 0.  MUST be ignored if not 0.

and

280   *  Protocol ID (1 octet) - MUST be 0.  MUST be ignored if not 0.
282   *  SPI Size (1 octet) - MUST be 0.  MUST be ignored if not 0.

no code-point reservations needed for experimental? or future use?

267   *  Resource Identifier (optional).  This opaque data may be set to
268       convey the local identity of the resource.

should there be no restrictions on what can be considered as a local identity?
What of this identity is an extremely long blockchain blob? what would happen? is that allowed?

290   Implementations supporting per-CPU SAs SHOULD extend their local SPD

later in the text is the it is mentioned per-queue also... Does this behave differently then the per-CPU principle?


344   An implementation that does not accept any further resource specific
345   Child SAs MUST NOT return the NO_ADDITIONAL_SAS error because this
346   can be interpreted by the peer that no other Child SAs with different
347   TSi/TSr are allowed either.  Instead, it MUST return TS_MAX_QUEUE.

should anything be mentioned about state kept on the implementation that has no more resources?
What if the remote side tries to open 10M SAs? (is it an attack vector?)

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ipsecme-multi-sa-performance-06. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the IKEv2 Notify Message Status Types registry in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Notify Message Status Type: SA_RESOURCE_INFO
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

Second, in the IKEv2 Notify Message Error Types registry also in the Internet Key Exchange Version 2 (IKEv2) Parameters registry group located at:

https://www.iana.org/assignments/ikev2-parameters/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Notify Message Error Type: TS_MAX_QUEUE
Reference: [ RFC-to-be ]

As this also requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated and completed the required Expert Review via a separate request.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-04-02):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ipsecme-multi-sa-performance@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IKEv2 support for per-resource Child SAs) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'IKEv2 support
for per-resource Child SAs'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-04-02. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines two Notify Message Type Payloads for the
  Internet Key Exchange Protocol Version 2 (IKEv2) to support the
  negotiation of multiple Child SAs with the same Traffic Selectors
  used on different resources, such as CPUs, to increase bandwidth of
  IPsec traffic between peers.

  The SA_RESOURCE_INFO notification is used to convey information that
  the negotiated Child SA and subsequent new Child SAs with the same
  Traffic Selectors are a logical group of Child SAs where most or all
  of the Child SAs are bound to a specific resource, such as a specific
  CPU.  The TS_MAX_QUEUE notify conveys that the peer is unwilling to
  create more additional Child SAs for this particular negotiated
  Traffic Selector combination.

  Using multiple Child SAs with the same Traffic Selectors has the
  benefit that each resource holding the Child SA has its own Sequence
  Number Counter, ensuring that CPUs don't have to synchronize their
  cryptographic state or disable their packet replay protection.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-multi-sa-performance/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

    It reached broad agreement as a valid and useful solution, although some
    raised concerns that accepting this document might mean similar related
    drafts might not see adoption. This mostly related to the "sequence number
    subspaces" draft, which is being worked on as part of a new ESPv4.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

    There was a long discussion about whether or not to negotiate the number of
    multiple SAs, but it became obvious that no agreement made sense, and thus to
    leave this open with only a local policy maximum safety.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  These are specified in the draft under Implementation Status.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  Not really - this is pure IPsec / IKEv2 related.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  N/A although the ipsec yang module _could_ be updated with a multi-sa option,
  which would be a boolean.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard. This is appropriate for a new IKEv2 property that
    configures an IPsec stack.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Authors have indicated that they do not know any IPRs related to this.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    -- Obsolete informational reference (is this intentional?): RFC 6982
    (Obsoleted by RFC 7942)

    This will be removed before publication anyway.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    One new Notify payload each for the IKEv2 Notify Message Types Error and
    Status types registry are requested. No new registries are created.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

    It reached broad agreement as a valid and useful solution, although some
    raised concerns that accepting this document might mean similar related
    drafts might not see adoption. This mostly related to the "sequence number
    subspaces" draft, which is being worked on as part of a new ESPv4.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

    There was a long discussion about whether or not to negotiate the number of
    multiple SAs, but it became obvious that no agreement made sense, and thus to
    leave this open with only a local policy maximum safety.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  These are specified in the draft under Implementation Status.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  Not really - this is pure IPsec / IKEv2 related.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  N/A although the ipsec yang module _could_ be updated with a multi-sa option,
  which would be a boolean.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard. This is appropriate for a new IKEv2 property that
    configures an IPsec stack.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Authors have indicated that they do not know any IPRs related to this.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    -- Obsolete informational reference (is this intentional?): RFC 6982
    (Obsoleted by RFC 7942)

    This will be removed before publication anyway.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    One new Notify payload each for the IKEv2 Notify Message Types Error and
    Status types registry are requested. No new registries are created.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/