Dhruv, Thank you for the quick turnaround.
I sincerely hope that my review has helped to improve (the already good) document ;-) Cheers -éric From: Dhruv Dhody <dhruv.i...@gmail.com> Date: Thursday, 6 October 2022 at 15:07 To: Eric Vyncke <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, "draft-ietf-lsr-pce-discovery-security-supp...@ietf.org" <draft-ietf-lsr-pce-discovery-security-supp...@ietf.org>, "lsr-cha...@ietf.org" <lsr-cha...@ietf.org>, "l...@ietf.org" <l...@ietf.org>, "Acee Lindem (acee)" <a...@cisco.com>, "pce@ietf.org" <pce@ietf.org>, "swo...@pir.org" <swo...@pir.org> Subject: Re: Éric Vyncke's No Objection on draft-ietf-lsr-pce-discovery-security-support-11: (with COMMENT) Hi Eric, Thanks for your review. The working copy is at - TXT - https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt DIFF - https://www.ietf.org/rfcdiff?url1=draft-ietf-lsr-pce-discovery-security-support-11&url2=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-lsr-pce-discovery-security-support-12.txt On Wed, Oct 5, 2022 at 9:01 PM Éric Vyncke via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Éric Vyncke has entered the following ballot position for draft-ietf-lsr-pce-discovery-security-support-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-lsr-pce-discovery-security-support-11 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Acee Lindem for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status, but we miss the WG reaction on the IPR disclosure (see below). Please note that Suzanne Woolf is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Suzanne will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/reviewrequest/16328/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### IPR The shepherd's write-up rightfully states that IPR disclosures were done (e.g., https://datatracker.ietf.org/ipr/5027/). But, the write-up says nothing about the WG reaction on a licensing scheme that it rather ambiguous `Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee` as the "possible royalty/fee" could hinder the deployment and use of this I-D. What was the WG reaction ? ### Section 1 The first paragraph mentions privacy, which is important but I would have assumed that integrity was even more important. Should integrity be mentioned ? Updated to - As described in [RFC5440], Path Computation Element Communication Protocol (PCEP) communication privacy and integrity are important issues, as an attacker that intercepts a PCEP message could obtain sensitive information related to computed paths and resources. Authentication and integrity checks allow the receiver of a PCEP message to know that the message genuinely comes from the node that purports to have sent it and to know whether the message has been modified. It is probably obvious, but should the change of registry names be linked to supporting IS-IS as well ? Added - [RFC5089] states that the IS-IS uses the same registry as OSPF. This document updates [RFC5089] to refer to the new IGP registry. ### Section 3.2.1 (and 3.3.1) The section would benefit of a simple figure showing the TLV structure, even if only to be consistent with section 3.2.2 IS-IS usually does not include figures and this is consistent with RFC 5089. ### Normative references Unsure whether RFC 5925, 5926, and others are really normative as I would qualify them as informative. I think RFC5925 should remain normative because of KeyID at the very least -> KeyID: The one octet Key ID as per [RFC5925] to uniquely identify the Master Key Tuple (MKT). RFC5926 can be moved to informative! Thanks! Dhruv ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
