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 <dd@xxxxxxxxxxxxxx>
Envoyé : lundi 13 mars 2023 19:16
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
Cc : ops-dir@xxxxxxxx; draft-ietf-ipsecme-add-ike.all@xxxxxxxx; ipsec@xxxxxxxx; last-call@xxxxxxxx
Objet : Re: Opsdir last call review of draft-ietf-ipsecme-add-ike-09
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.
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].
> - 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.
- 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!
>
> 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.
|
