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> 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 > > > >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
