Éric Vyncke has entered the following ballot position for draft-ietf-pce-segment-routing-policy-cp-25: Discuss
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-pce-segment-routing-policy-cp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-pce-segment-routing-policy-cp-25 CC @evyncke Thank you for the work put into this document. Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Dhruv Dhody for the shepherd's write-up including the WG consensus, some justification for 6 authors, and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 3 This section appears to be only about SR-MPLS, i.e., conflicting with the abstract, which explicitly includes SRv6, and the title, which does not mention any restriction to SR-MPLS only. Either add some SRv6 text (my preference) or restrict the I-D to SR-MPLS only. ### Section 4.1 Let's remove any ambiguity and specify the units (octets I guess) and the field coverage (color + endpoint I guess) for the Length field. ### Sections 4.2.1 & 4.2.3 `It is RECOMMENDED that the size of the symbolic name for the SR Policy is limited to 255 bytes. ` why only "RECOMMENDED" when the Length field can only indicate 255 maximum ? Suggest using MUST rather RECOMMENDED here. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Are RFC 8986 policies included ? This document does not seem to include RFC 8986 (network programming) policies as it only talks about "paths". The document should be clear whether it supports RFC 8986 and, if so, amend the text about "paths". ### Abstract Suggest deleting `called a headend node` as it brings no value there. ### Section 1 s/Path Setup Type 1 (Segment Routing) /Path Setup Type 1 (SR-MPLS) / ? (and possibly other places, let's remove any ambiguity) ### Sections 4.2.1 and 4.2.3 `Padding is not included in the Length field.` do PCEP receivers know how to handle a Length that does not really represent the length of the TLV ? ### Section 11.2 RFC20 should be normative. ## NITS (non-blocking / cosmetic) ### Section 1 Consider using lower case for `Establishing Relationships Between Sets` ### Section 5.1 Please use balanced quotes in `Type: 71 for "SRPOLICY-CAPABILITY TLV` ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg too to generate SVG graphics. It is worth a try ;-) _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
