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

["Eric Vyncke (evyncke)" <[e-mail]>]

Your latest addition is good for me

Thank you

-éric

From: Valery Smyslov <[e-mail]>
Date: Monday, 15 April 2024 at 09:43
To: Eric Vyncke (evyncke) <[e-mail]>, 'The IESG' <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
Hi Éric,

please see inline (I removed parts of the message where we are in agreement).

Thank you, Valery, for your 2nd reply and for allowing me to reply w/o on-line access to the I-D when I replied.

One last comment below as EVY2>

All comments were non-blocking anyway :)

-éric

[…]

> ## 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.
         In fact it does, but it sends this after the responder, in the following exchange. So, the responder sends its list first.
         This is to have the announcements and the list of trust anchors (in the CERTREQ payload) co-located in the same message.

EVY2> then this may be useful to write the above justification in the document itself.
       I’ve added the following text in the Section 3:
To simplify
  the receiver's task of linking the announced authentication methods
  with the trust anchors, the protocol ensures that the
  SUPPORTED_AUTH_METHODS notification is always co-located with the
  CERTREQ payload in the same message.
       Does it help?
       Regards,
       Valery.

[…]