[IPsec] Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Éric Vyncke, INT AD, comments fordraft-ietf-ipsecme-ikev2-auth-announce-09

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education), and some nits.

Special thanks to Tero Kivinen for the shepherd's detailed write-up including
the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Abstract

As the I-D is about authentication methods, I wonder whether `with multiple
different credentials` is the right wording, should it rather be "different
authentication methods" ? (of course with some text repetition).

## Section 3.1

`Regardless of whether the notification is received,` may be I am mis-reading
this, but why would the responder send the notification if the initiator does
not care anyway ?

## Section 3.2

While the readers may guess some details, but let's be clear in a proposed
standard I-D:

1) `Notification Data field` does not appear in figure 4
2) role of C flag and its value
3) value of Protocol ID
4) saying that reserved field must be set to 0 by sender and ignored on the
receiver

## Section 3.2.1

Let's be crisp and specify that the length is in octets.

Is there a registry for authentication method ? or should this specification be
updated for every new authentication method ?

# NITS (non-blocking / cosmetic)

## Section 1

The last sentence of the 2nd paragraph is rather long and I think that "that"
should be used in `the peer which supports wider range of`.

## Section 3.2.1

Missing closing parenthesis in the last paragraph.