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 <iesg-boun...@ietf.org> On Behalf Of Valery Smyslov Sent: Thursday, April 11, 2024 10:31 AM To: gun...@vandevelde.cc; 'The IESG' <i...@ietf.org> 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 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
