Hi Éric, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Eric Vyncke (evyncke) <[email protected]> > Envoyé : jeudi 27 avril 2023 09:03 > À : Valery Smyslov <[email protected]>; 'The IESG' <[email protected]> > Cc : [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Objet : Re: Éric Vyncke's Yes on draft-ietf-ipsecme-add-ike-11: > (with COMMENT) > > Hello Valery > > Thanks for your prompt reply. Please look below for EV> > > Regards > > -éric > > On 27/04/2023, 08:53, "Valery Smyslov" <[email protected] > <mailto:[email protected]>> wrote: > > > Hi Éric, > > > thank you for your comments. Please see inline (I will only > address some of your comments). > > > > > > ---------------------------------------------------------------- > ------ > > COMMENT: > > ---------------------------------------------------------------- > ------ > > > > Thank you for the work put into this document. It really helps > to > > achieve the goals of the ADD WG :-) (only regret is that the > IPSECME > > WGLC was not formally extended to the ADD WG, a little more of > > cross-WG collaboration is always welcome even if authors are > also very active in ADD). > > > > Please find below some non-blocking COMMENT points (but replies > would > > be appreciated even if only for my own education), and one nit. > > > > Special thanks to Tero Kivinen for the shepherd's detailed > write-up > > including the WG consensus and the justification of the intended > status. > > > > Other thanks to Patrick Mevzek, the DNS directorate reviewer, > please > > consider this dns-dir review: > > > > mevzek-2023-03-16/ > > (and the authors/chairs have also replied) > > > > I hope that this review helps to improve the document, > > > > Regards, > > > > -éric > > > > # COMMENTS (non-blocking) > > > > I second Paul Wouters' DISCUSS point #2 and Zahed's one (even if > this > > may be the IPSECME WG usual process, it is not the IETF > process). > > > Are there any formal guidelines that list criteria for marking a > document "Update" for another document? > > EV> Alas no... some IESG have tried to get a formal definition and > always failed ☹ ... I.e., common sense should apply in the > absence of rules. > > What I like about ipsecme position on that - there is a well > understood criteria: > if new specification requires that legacy implementations be > updated, then the new specification "Updates" an old one. If this > is not the case - no need to mark it as "Update". > > > In our case, no change to implementations that are unaware of this > document > and only implement RFC 8598 is needed, so this is not (in our > opinion) an "Update". > > EV> this sounds logical [Med] Thanks. > > > ## Section 1 > > > > In the discussion about private CA / address for the DNS > resolver, one more > > sentence stating the obvious (when using a private CA then the > client may use > > the digest info payload) would be welcome. Alternatively, moving > this > > paragraph > > before the reference to the appendix will make it clearer the > link with > > ENCDNS_DIGEST_INFO. > > [Med] Moved the text as suggested. > > ## Section 2 > > > > Should RFC 8499 be normative (note RFC 7296 is normative and > used in the > > same > > way)? > > [Med] I prefer to be consist with how we classified RFC8499 in other ADD document. 7296 is cited as a normative as this is the base IKE spec. > > ## Section 3.2 > > > > What is the responder behaviour when receiving a CFG_REQUEST > with "ADN > > Length" > > different from 0 ? Symmetrical case for the initiator when "Num > Hash Algs" is > > not 1 in a CFG_SET. If the generic behaviour described in > section 4 (`As a > > reminder, badly formatted attributes or unacceptable fields are > handled as per > > Section 2.21 of [RFC7296].`), then why other fields (notably > "R") have specific > > text ? The reminder of section 4 should rather be in section 3 > (but this is a > > matter of taste). > > > "R" is a RESERVED field and is treated as any other RESERVED field > in IKEv2 - > its value (whether it is 0 or not) is ignored. We cannot ignore > invalid > values in other fields, because the receiver in this case has no > clue what > the sender meant. > > > > `Note that SHA2-256 is mandatory to implement` does this mean > that SHA2- > > 256 > > identifier *MUST* always be in the list or is it implicit and > does not have to > > be in the list ? > > > I believe not. It is mandatory to implement in general, for > operations on the Internet. > Mutually consenting parties operating in closed environment may > very well ignore this MTI requirement > and list only other values. > > EV> ah ah, SHA2 is mandatory to implement but may not be used. > This subtlety had escaped me, should the text be clear about this > ? > [Med] Made this change: OLD; Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client. NEW: Specifies a list of 16-bit hash algorithm identifiers that are supported by the encrypted DNS client. This list may be controlled by a local policy. Please let us know if you prefer a more specific wording. Thanks. > Regards, > Valery. > > > > # NITS (non-blocking / cosmetic) > > > > ## Appendix A.1 > > > > No need to expand VPN as it is both well-known and used before > without > > expansion ;) > > > > > > > > > > _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
