Hi Dhruv, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Dhruv Dhody via Datatracker <noreply@xxxxxxxx> > Envoyé : lundi 13 mars 2023 14:52 > À : ops-dir@xxxxxxxx > Cc : draft-ietf-ipsecme-add-ike.all@xxxxxxxx; ipsec@xxxxxxxx; > last-call@xxxxxxxx > Objet : Opsdir last call review of draft-ietf-ipsecme-add-ike-09 > > Reviewer: Dhruv Dhody > Review result: Has Issues > > # OPSDIR Review of draft-ietf-ipsecme-add-ike-09 > > Reviewer: Dhruv Dhody > Review Result: Has Issues > > I have reviewed this document as part of the Operational > directorate's ongoing effort to review all IETF documents being > processed by the IESG. These comments were written with the > intent of improving the operational aspects of the IETF drafts. > Comments that are not addressed in last call may be included in AD > reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call > comments. > > The document is clear and well-written. The appendix is useful, > thanks for adding these! It does not have any operational > considerations section. It could be useful to add (to highlight > them). There is some text of operational significance in section > 4. > > ## Major > > - There are instances of "attributes MUST NOT be X" but it is not > mentioned how the implementation deals with them when received. [Med] This will be handled as a malformed message. We don't repeat these considerations here as these are already covered in the base spec: /rfc7296.html#section-2.21. > Perhaps, a reference to an existing RFC that has the error > handling specified? > - Service Priority MUST NOT be 0. > - Num Addresses MUST NOT be 0. > - The service parameters MUST NOT include "ipv4hint" or > "ipv6hint" > - ... > > ## Minor > > - I think that the "ADN Length" can be 0. Maybe state that > explicitly. [Med] OK. Added this NEW: NEW: When set to '0', this means that no ADN is enclosed in the attribute. > - Suggest use of normative MUST below - > OLD: > If the request includes multiple bitwise identical attributes, > only the first occurrence is processed, and the rest SHOULD be > ignored by the responder. NEW: > If the request includes multiple bitwise identical attributes, > only the first occurrence MUST be processed, and the rest SHOULD > be ignored by the responder. [Med] The OLD version was carefully worded to allow as an option to ignore the full request under such conditions. The NEW wording will conflict with the sentence right after: "The responder MAY discard the full request if the count of repeated attributes exceeds an (implementation specific) threshold." > END - Maybe you can explicitly state that there is no padding for > ADN? [Med] I don't think there is ambiguity in the encoding of that field, but will double check. - Suggest adding references for the port numbers in section > 3.1. [Med] Sure. Updated to "853 for DoT (Section 6 of [RFC7858]), 443 for DoH (Section 8.1 of [RFC8484]), and 853 for DoQ (Section 8 of [RFC9250])" - Should this text in Section 3.2 "Note that SHA2-256 is > mandatory to implement." use Normative MUST? Note that you do use > it in Section 5. [Med] We don't use the normative language in 3.2 as this will be redundant with Section 5. If we use it in 3.2, we need to remove it from 5. > > Thanks! > Dhruv > > _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
