Éric Vyncke has entered the following ballot position for draft-ietf-pce-segment-routing-policy-cp-26: 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-pce-segment-routing-policy-cp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for *partially* addressing my blocking DISCUSS (including the last one, which was caused by my misreading of the I-D). I am clearing my DISCUSS. ***BUT***, I still find the text in section 3 very unclear about its applicability to SRv6, the LSP explanation added at the end of section 2 is enough to clear my previous DISCUSS, but ***the whole section can only confuse the readers***. # Below kept for archiving No need to act on anything below. ## Archive of 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. *My bad on this one, Med corrected me* ## Archive of 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
