Thanks Med! Looks good! Dhruv
On Tue, Mar 14, 2023 at 12:01 PM <mohamed.boucad...@orange.com> wrote: > Hi Dhruv, > > > > Thanks for the follow-up. > > > > The candidate changes can be seen at: https://tinyurl.com/add-ike-latest. > Please let me know if any other change is needed. > > > > Cheers, > > Med > > > > *De :* Dhruv Dhody <d...@dhruvdhody.com> > *Envoyé :* lundi 13 mars 2023 19:16 > *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > *Cc :* ops-...@ietf.org; draft-ietf-ipsecme-add-ike....@ietf.org; > ipsec@ietf.org; last-c...@ietf.org > *Objet :* Re: Opsdir last call review of draft-ietf-ipsecme-add-ike-09 > > > > Hi Med, > > > > Thanks for your reply! > > > > On Mon, Mar 13, 2023 at 8:26 PM <mohamed.boucad...@orange.com> wrote: > > Hi Dhruv, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -----Message d'origine----- > > De : Dhruv Dhody via Datatracker <nore...@ietf.org> > > Envoyé : lundi 13 mars 2023 14:52 > > À : ops-...@ietf.org > > Cc : draft-ietf-ipsecme-add-ike....@ietf.org; ipsec@ietf.org; > > last-c...@ietf.org > > 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. > > > > Dhruv: I didn't expect you to cover every instance, just one sentence that > would point the reader to the correct reference. Something like the error > handling in case of badly formatted attributes or unacceptable fields is as > per Section 2.21 of [RFC7296]. > > > > <snip> > > > > - 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." > > > > Dhruv: Hmmm, a bit awkward wording on first reading, but I get it! > > > > > 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. > > > > [Dhruv]: Please do, it came to me when I saw that you explicitly call it > out for hash algo ids. > > > > <Snip> > > > > > - 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. > > > > [Dhruv]: Perhaps add a forward reference to section 5, that would be a > clear indication that section 5 is the key normative text about it. > > > > Thanks again for taking my comments into consideration! > > Dhruv > > > > > > > > > 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. > > _________________________________________________________________________________________________________________________ > > 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
