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 From: Valery Smyslov <s...@elvis.ru> Date: Friday, 12 April 2024 at 09:40 To: Eric Vyncke (evyncke) <evyn...@cisco.com>, 'The IESG' <i...@ietf.org> Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org <draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org>, ipsecme-cha...@ietf.org <ipsecme-cha...@ietf.org>, ipsec@ietf.org <ipsec@ietf.org>, kivi...@iki.fi <kivi...@iki.fi> Subject: RE: Éric Vyncke's No Objection on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT) Hi Éric, please see inline. Thank you, Valery, for the prompt reply. See below for EVY> Regards -éric From: Valery Smyslov <s...@elvis.ru<mailto:s...@elvis.ru>> Date: Thursday, 11 April 2024 at 15:23 To: Eric Vyncke (evyncke) <evyn...@cisco.com<mailto:evyn...@cisco.com>>, 'The IESG' <i...@ietf.org<mailto:i...@ietf.org>> Cc: draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org<mailto:draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org> <draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org<mailto:draft-ietf-ipsecme-ikev2-auth-annou...@ietf.org>>, ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org> <ipsecme-cha...@ietf.org<mailto:ipsecme-cha...@ietf.org>>, ipsec@ietf.org<mailto:ipsec@ietf.org> <ipsec@ietf.org<mailto:ipsec@ietf.org>>, kivi...@iki.fi<mailto:kivi...@iki.fi> <kivi...@iki.fi<mailto: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 Great! > ## 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. > ## 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 ? I think that since we explicitly reference the description of the Notify Payload in RFC 7296, readers will be able to know how the generic payload header fields should be filled in, right? I’m just trying to follow other IKEv2 extensions RFCs, where usually these details are omitted (if one wants to implement an IKEv2 extension, then we presume that he/she is familiar with IKEv2 enough to know how to construct a payload). What about the Protocol ID (and SPI Size), the text currently defines what should be there. The current text is: The Notify payload format is defined in Section 3.10 of [RFC7296]. When a Notify payload of type SUPPORTED_AUTH_METHODS is sent, the Protocol ID field is set to 0, the SPI Size is set to 0, meaning there is no SPI field, and the Notify Message Type is set to <TBA by IANA>. 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) It is already there (in the para describing the notification payload data, Section 3.2)! Authentication methods are represented as values from the "IKEv2 Authentication Method" registry defined in [IKEV2-IANA]. and later in the Normative references: [IKEV2-IANA] IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", <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 EVY> ;-) I had to learn it myself (not easy for non English speaker) Indeed :) Regards, Valery.
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
