Hello Valery Thanks for your prompt reply. Please look below for EV>
Regards -éric On 27/04/2023, 08:53, "Valery Smyslov" <s...@elvis.ru <mailto:s...@elvis.ru>> 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: > https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir- > <https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-11-dnsdir-> > telechat-mevzek-2023-04-04/ > (and I have read Med's reply so all it good) and the previous > https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc- > <https://datatracker.ietf.org/doc/review-ietf-ipsecme-add-ike-09-dnsdir-lc-> > 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 > ## 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. > > ## Section 2 > > Should RFC 8499 be normative (note RFC 7296 is normative and used in the > same > way)? > > ## 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 ? 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 ;) > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
