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.
Ive 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.
[
]
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
