Bonjour Med, You are correct and I stand corrected for the length field being 16 bits... too early in the morning for me ;-)
Regards -éric From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> Date: Wednesday, 2 April 2025 at 10:16 To: Eric Vyncke (evyncke) <evyn...@cisco.com>, The IESG <i...@ietf.org> Cc: draft-ietf-pce-segment-routing-policy...@ietf.org <draft-ietf-pce-segment-routing-policy...@ietf.org>, pce-cha...@ietf.org <pce-cha...@ietf.org>, pce@ietf.org <pce@ietf.org>, d...@dhruvdhody.com <d...@dhruvdhody.com> Subject: RE: Éric Vyncke's Discuss on draft-ietf-pce-segment-routing-policy-cp-25: (with DISCUSS and COMMENT) Salut Éric, Regarding: > > ### 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. The length field is 16 bits. I actually asked to have that text in the spec and ensure that we are consistent with https://datatracker.ietf.org/doc/draft-ietf-idr-sr-policy-safi/13/. I suggest we keep the current wording. Thanks. Cheers, Med > -----Message d'origine----- > De : Éric Vyncke via Datatracker <nore...@ietf.org> > Envoyé : mercredi 2 avril 2025 09:44 > À : The IESG <i...@ietf.org> > Cc : draft-ietf-pce-segment-routing-policy...@ietf.org; pce- > cha...@ietf.org; pce@ietf.org; d...@dhruvdhody.com > Objet : Éric Vyncke's Discuss on draft-ietf-pce-segment-routing- > policy-cp-25: (with DISCUSS and COMMENT) > > > É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.) > > > ------------------------------------------------------------------ > 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) > > > ### 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 ;-) > > ____________________________________________________________________________________________________________ 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.
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
