Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi Mahesh,

thank you for your comments, please see inline.

> Mahesh Jethanandani 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:
> --
> 
> Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
> to Rifaat for the SECDIR review, and to Marc for the ARTART review.
> 
> Section 3.1, paragraph 14
> >If the responder has sent any CERTREQ payload in the IKE_SA_INIT,
> >then it MUST re-send the same payload(s) in the IKE_INTERMEDIATE
> >response containing the SUPPORTED_AUTH_METHODS notification if any of
> >the included Announcements has a non-zero Cert Link field (see
> >Section 3.2.2 and Section 3.2.3).  This requirement allows peers to
> >have a list of Announcements and a list of CAs in the same message,
> >which simplifies their linking (note, that this requirement is always
> >fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges).  However, if
> >for any reason the responder doesn't re-send CERTREQ payload(s) in
> >the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort
> >negotiation.  Instead, the initiator MAY either link the
> >Announcements to the CAs received in the IKE_SA_INIT response, or MAY
> >ignore the Announcements containing links to CAs.
> 
> I am a little puzzled by the MUST at the beginning of the paragraph which
> insists that CERTREQ payload should be sent in IKE_INTERMEDIATE response
> and
> the MUST NOT/MAY at the bottom of the paragraph, which seems to be ok with
> not
> re-sending the CERTREQ payload. Is it possible that the CERTREQ payloads are
> not re-send and at the same time they do not fit in IKE_SA_INIT (without being
> fragmented)?

Good point, thank you. We can s/MUST/SHOULD.

The idea is to make initiator's task of linking auth announcements to CAs 
simpler,
by always having them in one message. On the other hand, responder may
have its own considerations about re-sending CERTREQ in the IKE_INTERMEDIATE.

> The IANA review of this document seems to not have concluded yet.

Hmm, from my understanding, the IANA has already reviewed the draft...

> No reference entries found for these items, which were mentioned in the text:
> [RFC].

I believe the RFC Editor will change  this to the appropriate value.

> Possible DOWNREF from this Standards Track doc to [IKEV2-IANA]. If so, the
> IESG
> needs to approve it.

I think that referencing IANA registries is not a DOWNREF.

> Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and more
> guidance:
> 
>  * Term "his"; alternatives might be "they", "them", "their"


Paul Wouters is definitely "he" :-)

> ---
> 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.
> 
> Section 1, paragraph 3
> 
> s/each peer uses/each peer use/

I think the current text is correct.

> Section 3, paragraph 1
> >particular trust anchors.  Upon receiving this information the peer
> >may take it into consideration while selecting an algorithm for its
> >authentication if several alternatives are available.
> 
> This sentence does not parse for me. When it says, "the peer may take it into
> consideration while ...", I seem to be missing what needs to be taken into
> consideration.

Perhaps:

NEW:

   The receiving party may take this information into consideration when 
selecting an algorithm for its
   authentication if several alternatives are available.

Is this better?

> Section 3.2, paragraph 6
> >If more authentication methods are defined in future, the
> >corresponding documents must describe the semantics of the
> >announcements for these methods.  Implementations MUST ignore
> >announcements which semantics they don't understand.
> 
> s/announcements which semantics/announcements 

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov]

Hi,

for some reason I didn't receive a message with comments from Gunter, but I 
noticed his comments at the ballot page
(it seems that the e-mail wasn't requested to be sent, as indicated in the 
datatracker).

I'm not sure if the message will be sent later and I want to respond to these 
comments, so I take the opportunity
to reply to the Mahesh's e-mail once again and comment on Gunter's comments :-)

First, thanks for these comments, I copy-pasted them from the datatracker. 
Plese, see inline.

> Document reviewed: draft-ietf-ipsecme-ikev2-auth-announce-09.txt
>
> Many thanks for this write-up. I see no issues from my side to progress this 
> document.
> During my review cycle i noted some observations that you may consider if you 
> find beneficial
>
> typos:
> s/overriden/overridden/

Fixed, thanks.

> [idnits] entries when runing idnits captured by shepherd review
>
> Review comments:
> 14   supported authentication methods to their peers while establishing
> 15   IKEv2 Security Association (SA).  This mechanism improves
>
> This draft is written for IKEv2, however would the proposed technology be 
> used potentially by newer IKE flavors?
> (as networking generalist i am unclear about dynamics of IKE evolutions). If 
> the IKEv2 is 'always' implicit 
> implied, then does it add value to mention IKEv2 here again? (i am ok with it 
> either way, only questioning the extra characters in the abstract)

I agree that using both 'IKE' and 'IKEv2' adds some confusion for readers, but 
this is a long habit in IPsec.
To the point - this draft is written for IKEv2 (we don't know what IKEv3 would 
look like),
so it is always implicitly implied. Sometimes it is also stated explicitly.

> 84   selecting authentication credentials.  The problem may arise when
> 85   there are several credentials of different types configured on one
> 86   peer, while only some of them are supported on the other peer.
>
> Not sure that saying "The problem" is accurate? there is added complexity or 
> credential 
> inconsistency, but by itself that is not a problem.
>
> What about this rewrite suggestion to nail this down: 
>
> "SA establishment failure between peers may arise when there are several 
> credentials of different types
> configured on one peer, while only some of them are supported on the other 
> peer."

I used this text, thank you.

> 116  When establishing IKE SA each party may send a list of authentication
> 117  methods it supports and is configured to use to its peer.  For this
>
> Here is mentioning of IKE and not IKEv2. was this intentional. Is there a 
> benefit in being consistent in terminology wrt IKE vs IKEv2?

As I said, there is a habit to mix 'IKE' and 'IKEv2' in IPsec world.

> 121  the party sending it.  The sending party may additionally specify
> 122  that some of the authentication methods are only for use with the
> 123  particular trust anchors.  Upon receiving this information the peer
>
> what does 'the' in the above phrase "**the** particular trust anchors" refer 
> towards? 
> (i am not so familiar with IKE so much, so am trying to understand how 
> SUPPORTED_AUTH_METHODS is correlated, and trust anchors was not mentioned 
> before. 
> (i do assume its well known terminology  though)

List of trust anchors are sent in the CERTREQ payload.
This extension allows to link each of the announced digital signature auth 
method with the particular
trust anchor (meaning that *this* algorithm should be used with *this* CA).

> 132  message.  This notification contains a list of authentication methods
> 133  supported by the responder, ordered by their preference.
>
> how is this correlating towards the trust anchor mentioned in above comment?

The order of preference is not correlated with the trust anchors.
The correlation is described above.

> 287  announcements for these methods.  Implementations MUST ignore
> 288  announcements which semantics they don't understand.
>
> s/which/with/

Changed to s/which/whose as Mahesh proposed.

> 390   4.  Interaction with IKE Extensions concerning Authentication
>
> is there a reason why IKE is mentioned instead of IKEv2 ?

Changed to 'IKEv2'.

Regards,
Valery.

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Gunter van de Velde (Nokia)]

Thank you Valery for your kind consideration of the review comments.

You were correct that indeed I did not hit the 'send update' radio button 
because my comments were 
non-blocking and I intended to reduce generic email noise. Unfortunately I did 
not realize that not 
sending email voids easy opportunity to draft authors to reply to the comment. 
My apologies for inconvenience

G/

-Original Message-
From: iesg  On Behalf Of Valery Smyslov
Sent: Thursday, April 11, 2024 10:31 AM
To: gun...@vandevelde.cc; 'The IESG' 
Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org; ipsecme-cha...@ietf.org; 
ipsec@ietf.org; kivi...@iki.fi
Subject: RE: Mahesh Jethanandani's No Objection on 
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[You don't often get email from s...@elvis.ru. Learn why this is important at 
https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Hi,

for some reason I didn't receive a message with comments from Gunter, but I 
noticed his comments at the ballot page (it seems that the e-mail wasn't 
requested to be sent, as indicated in the datatracker).

I'm not sure if the message will be sent later and I want to respond to these 
comments, so I take the opportunity to reply to the Mahesh's e-mail once again 
and comment on Gunter's comments :-)

First, thanks for these comments, I copy-pasted them from the datatracker. 
Plese, see inline.

> Document reviewed: draft-ietf-ipsecme-ikev2-auth-announce-09.txt
>
> Many thanks for this write-up. I see no issues from my side to progress this 
> document.
> During my review cycle i noted some observations that you may consider 
> if you find beneficial
>
> typos:
> s/overriden/overridden/

Fixed, thanks.

> [idnits] entries when runing idnits captured by shepherd review
>
> Review comments:
> 14   supported authentication methods to their peers while establishing
> 15   IKEv2 Security Association (SA).  This mechanism improves
>
> This draft is written for IKEv2, however would the proposed technology be 
> used potentially by newer IKE flavors?
> (as networking generalist i am unclear about dynamics of IKE 
> evolutions). If the IKEv2 is 'always' implicit implied, then does it 
> add value to mention IKEv2 here again? (i am ok with it either way, 
> only questioning the extra characters in the abstract)

I agree that using both 'IKE' and 'IKEv2' adds some confusion for readers, but 
this is a long habit in IPsec.
To the point - this draft is written for IKEv2 (we don't know what IKEv3 would 
look like), so it is always implicitly implied. Sometimes it is also stated 
explicitly.

> 84   selecting authentication credentials.  The problem may arise when
> 85   there are several credentials of different types configured on one
> 86   peer, while only some of them are supported on the other peer.
>
> Not sure that saying "The problem" is accurate? there is added 
> complexity or credential inconsistency, but by itself that is not a problem.
>
> What about this rewrite suggestion to nail this down:
>
> "SA establishment failure between peers may arise when there are 
> several credentials of different types configured on one peer, while only 
> some of them are supported on the other peer."

I used this text, thank you.

> 116  When establishing IKE SA each party may send a list of authentication
> 117  methods it supports and is configured to use to its peer.  For this
>
> Here is mentioning of IKE and not IKEv2. was this intentional. Is there a 
> benefit in being consistent in terminology wrt IKE vs IKEv2?

As I said, there is a habit to mix 'IKE' and 'IKEv2' in IPsec world.

> 121  the party sending it.  The sending party may additionally specify
> 122  that some of the authentication methods are only for use with the
> 123  particular trust anchors.  Upon receiving this information the peer
>
> what does 'the' in the above phrase "**the** particular trust anchors" refer 
> towards?
> (i am not so familiar with IKE so much, so am trying to understand how 
> SUPPORTED_AUTH_METHODS is correlated, and trust anchors was not mentioned 
> before.
> (i do assume its well known terminology  though)

List of trust anchors are sent in the CERTREQ payload.
This extension allows to link each of the announced digital signature auth 
method with the particular trust anchor (meaning that *this* algorithm should 
be used with *this* CA).

> 132  message.  This notification contains a list of authentication methods
> 133  supported by the responder, ordered by their preference.
>
> how is this correlating towards the trust anchor mentioned in above comment?

The order of preference is not correlated with the trust anchors.
The correlation is described above.

> 287  announcements for these methods.  Implementations MUST ignore
> 288  announcemen

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

[Éric Vyncke via Datatracker]

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



___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Éric,

thank you for your comments, please see inline.

> É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).

I believe "different credentials" may include "different authentication 
methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?

> ## 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 ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind 
whether to send and whether to process this notification (if it is ever 
supported). 

> ## 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

There is a reference to Section 3.10 of RFC 7296, which contains 
details of how a generic payload header should be filled in.
The Protocol ID and SPI Size values are defined in this document (zero).

What about 1), well, the "Notification Data" is the generic name
of this field in the Notify Payload. Its content depends on the type of the 
notify message.
I quickly scanned other RFCs which defined new notifications and they all
renamed the "Notification Data" to some name specific to the 
type of notification. So, to avoid confusion, I changed the text as follows:

s/The Notification Data field/ Notification data

Hope this eliminates the possible confusion.

> ## Section 3.2.1
> 
> Let's be crisp and specify that the length is in octets.

Done.

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

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

I hope no, but I cannot predict how IKEv2 would be tweaked in the future :-)

> # 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`.

Thank you, I've been always mixing when to use "which" or "that" :-)

I changed s/which/that

> ## Section 3.2.1
> 
> Missing closing parenthesis in the last paragraph.

Fixed.

Regards,
Valery.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Eric Vyncke (evyncke)]

Thank you, Valery, for the prompt reply.

See below for EVY>

Regards

-éric

From: Valery Smyslov 
Date: Thursday, 11 April 2024 at 15:23
To: Eric Vyncke (evyncke) , 'The IESG' 
Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org 
, ipsecme-cha...@ietf.org 
, ipsec@ietf.org , kivi...@iki.fi 

Subject: RE: Éric Vyncke's No Objection on 
draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

thank you for your comments, please see inline.

> É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).

I believe "different credentials" may include "different authentication 
methods"?
There are may also be some subtleties. For example, consider the situation
when user has 2 certificates: RSA and ECDSA. In this case he/she has
different credentials, but from IKEv2 point of view, both use the same
authentication method, "Digital Signature", with different signature algorithms.

I make the following change:
s/multiple different credentials/multiple credentials of different type

Is this better?
EVY> I think so



> ## 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 ?

The responder doesn't know if the initiator cares or not.
There is no negotiation of this feature, each party just makes its mind
whether to send and whether to process this notification (if it is ever 
supported).

EVY> sure it will work like described in the I-D, but I find it really weird 
that the initiator does not send its own list.

> ## 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

There is a reference to Section 3.10 of RFC 7296, which contains
details of how a generic payload header should be filled in.
The Protocol ID and SPI Size values are defined in this document (zero).

EVY> I am off-line now so cannot check in the I-D whether the reference is 
there. But, may I suggest to state somewhere that the fields C/protocol 
id/reserved are specified in RFC 7296 ?


What about 1), well, the "Notification Data" is the generic name
of this field in the Notify Payload. Its content depends on the type of the 
notify message.
I quickly scanned other RFCs which defined new notifications and they all
renamed the "Notification Data" to some name specific to the
type of notification. So, to avoid confusion, I changed the text as follows:

s/The Notification Data field/ Notification data

Hope this eliminates the possible confusion.

EVY> this would help indeed


> ## Section 3.2.1
>
> Let's be crisp and specify that the length is in octets.

Done.

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

https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

EVY> may I suggest to add a reference to this registry (again off-line and 
cannot check)


I hope no, but I cannot predict how IKEv2 would be tweaked in the future :-)

> # 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`.

Thank you, I've been

Re: [IPsec] Mahesh Jethanandani's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Mahesh Jethanandani]

HI Valery,

Thanks for responding to my comments. 

Some of these comments are generated by a tool we use, and as it says, you 
should feel free to ignore them if they are not applicable. Please see inline 
for the remaining.

> On Apr 11, 2024, at 12:56 AM, Valery Smyslov  wrote:
> 
> Hi Mahesh,
> 
> thank you for your comments, please see inline.
> 
>> Mahesh Jethanandani 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:
>> --
>> 
>> Thanks to Reese Enghardt for the General Area Review Team (Gen-ART) review
>> to Rifaat for the SECDIR review, and to Marc for the ARTART review.
>> 
>> Section 3.1, paragraph 14
>>>   If the responder has sent any CERTREQ payload in the IKE_SA_INIT,
>>>   then it MUST re-send the same payload(s) in the IKE_INTERMEDIATE
>>>   response containing the SUPPORTED_AUTH_METHODS notification if any of
>>>   the included Announcements has a non-zero Cert Link field (see
>>>   Section 3.2.2 and Section 3.2.3).  This requirement allows peers to
>>>   have a list of Announcements and a list of CAs in the same message,
>>>   which simplifies their linking (note, that this requirement is always
>>>   fulfilled for the IKE_SA_INIT and IKE_AUTH exchanges).  However, if
>>>   for any reason the responder doesn't re-send CERTREQ payload(s) in
>>>   the IKE_INTERMEDIATE exchange, then the initiator MUST NOT abort
>>>   negotiation.  Instead, the initiator MAY either link the
>>>   Announcements to the CAs received in the IKE_SA_INIT response, or MAY
>>>   ignore the Announcements containing links to CAs.
>> 
>> I am a little puzzled by the MUST at the beginning of the paragraph which
>> insists that CERTREQ payload should be sent in IKE_INTERMEDIATE response
>> and
>> the MUST NOT/MAY at the bottom of the paragraph, which seems to be ok with
>> not
>> re-sending the CERTREQ payload. Is it possible that the CERTREQ payloads are
>> not re-send and at the same time they do not fit in IKE_SA_INIT (without 
>> being
>> fragmented)?
> 
> Good point, thank you. We can s/MUST/SHOULD.
> 
> The idea is to make initiator's task of linking auth announcements to CAs 
> simpler,
> by always having them in one message. On the other hand, responder may
> have its own considerations about re-sending CERTREQ in the IKE_INTERMEDIATE.
> 
>> The IANA review of this document seems to not have concluded yet.
> 
> Hmm, from my understanding, the IANA has already reviewed the draft...

You are right. In most cases, IANA will take a look at the IANA Considerations 
section, and say they understand the request. I on the other hand, tend to err 
on the side of giving more information than less. For example, in this case 
what does RFC refer to? A short note to the RFC Editor (with another note 
to say please remove it before publication), would inform them that RFC 
refers to the RFC number that will be assigned to this document. 

> 
>> No reference entries found for these items, which were mentioned in the text:
>> [RFC].
> 
> I believe the RFC Editor will change  this to the appropriate value.
> 
>> Possible DOWNREF from this Standards Track doc to [IKEV2-IANA]. If so, the
>> IESG
>> needs to approve it.
> 
> I think that referencing IANA registries is not a DOWNREF.

This is an example of the tool trying to figure out where is the reference 
(possibly because of the square brackets). You can ignore it.

> 
>> Found terminology that should be reviewed for inclusivity; see
>> https://www.rfc-editor.org/part2/#inclusive_language 
>>  for background and 
>> more
>> guidance:
>> 
>> * Term "his"; alternatives might be "they", "them", "their"
> 
> 
> Paul Wouters is definitely "he" :-)

Another case of the tool giving a false positive. But in general the idea is to 
flag use of his, her etc. You get the picture. 

> 
>> ---
>> 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-revie