Inline: GV2> -----Original Message----- From: Cheng Li <c...@huawei.com> Sent: Friday, November 15, 2024 5:56 PM To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; The IESG <i...@ietf.org> Cc: draft-ietf-pce-stateful-pce-ven...@ietf.org; pce-cha...@ietf.org; pce@ietf.org Subject: RE: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-stateful-pce-vendor-10: (with COMMENT)
Hi Gunter, Thank you very much for your review and comments. Please see our reply inline. Thanks, Cheng -----Original Message----- From: Gunter Van de Velde via Datatracker <nore...@ietf.org> Sent: Thursday, November 14, 2024 12:13 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-pce-stateful-pce-ven...@ietf.org; pce-cha...@ietf.org; pce@ietf.org Subject: [Pce] Gunter Van de Velde's No Objection on draft-ietf-pce-stateful-pce-vendor-10: (with COMMENT) Gunter Van de Velde has entered the following ballot position for draft-ietf-pce-stateful-pce-vendor-10: 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-stateful-pce-vendor/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-pce-stateful-pce-vendor-10 # line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-stateful-pce-vendor-10.txt # in general i found the document is well written #DETAILED COMMENTS #================= 18 A Stateful Path Computation Element (PCE) maintains information on 19 the current network state, including computed Label Switched Path 20 (LSPs), reserved resources within the network, and the pending path 21 computation requests. This information may then be considered when 22 computing new traffic-engineered LSPs, and for any associated and 23 dependent LSPs, received from a Path Computation Client (PCC). 25 RFC 7470 defines a facility to carry vendor-specific information in 26 stateless PCE Communication Protocol (PCEP) messages. 28 This document extends this capability for the Stateful PCEP messages. GV> What about following rewrite: " This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that enable the inclusion of vendor-specific information in stateful PCE operations. These extensions allow vendors to incorporate proprietary data within PCEP messages, facilitating enhanced network optimization and functionality in environments requiring vendor-specific features. The extensions maintain compatibility with existing PCEP implementations and promote interoperability across diverse network deployments. RFC 7470 defines a facility to carry vendor-specific information in stateless PCE Communication Protocol (PCEP) messages. This document extends this capability for the Stateful PCEP messages. " [Cheng]LGTM, thank you! 119 The Vendor Information Object and the VENDOR-INFORMATION-TLV are also 120 valuable in the Stateful PCE model. The VENDOR-INFORMATION-TLV can 121 be included within any of the new objects introduced in PCEP for 122 Stateful PCE as defined in [RFC7470]. This document extends stateful 123 PCEP messages to incorporate the Vendor Information Object. GV> s/within any of the new objects/within any of the objects/ [Cheng]OK. 135 The message formats in this document are illustrated using Routing 136 Backus-Naur Form (RBNF) encoding, as specified in [RFC5511]. The use 137 of RBNF is illustrative only and may elide certain important details; 138 the normative specification of messages is found in the prose 139 description. If there is any divergence between the RBNF and the 140 prose, the prose is considered authoritative. GV> I got thrown off rails by the word "prose". I am not native english GV> speaker and had to look it up. WHat i found was: A prose description is a narrative explanation written in ordinary, continuous language using full sentences and paragraphs. It conveys information in a clear and straightforward manner, without the use of technical jargon, bullet points, or specialized formatting. In technical documents or specifications, a prose description helps readers understand concepts, features, or procedures by presenting them in an easily readable and understandable form. What confuses me is that RBNF is very different then prose. I think that the section is correct, but does read rather unnatural. [Cheng]what about this? "The use of RBNF is illustrative only and may omit certain important details; the normative specification of messages is found in the descriptive text. If there is any divergence between the RBNF and the descriptive text, the descriptive text is considered authoritative. " GV2> John Scudder provided me some background on the text paragraph and the wording. It was ok, but stretching the limits of my English vocabulary. 160 The message formats in this document are specified using Routing 161 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. GV> RBNF is expanded, while it was defined earlier in the document [Cheng]No problem, we can edit it. Thanks. 271 4.2. Information and Data Models 273 The PCEP YANG module is specified in [I-D.ietf-pce-pcep-yang]. Any 274 standard YANG module will not include details of vendor-specific 275 information. GV> I would assume that the container of the TLV could be specified, but GV> not the container content as that is vendor specific (aka proprietary). Assigning a conainer name for the the vendor specific option could carry value from alignment perspective [Cheng]In the PCEP YANG, we do not store the objects or TLVS. So it will be a little bit weird to do so for vendor TLV only. How about let's keep it as is? GV2> okay 277 4.3. Liveness Detection and Monitoring 279 Mechanisms defined in this document do not imply any new liveness 280 detection and monitoring requirements in addition to those already 281 listed in [RFC5440]. GV> I did not check the history of the creation of this text, but wonder GV> what this section has to do with the content. COuld it not just be removed and reduce document size? I have similar observation with paragraph 4.4 [Cheng] These sections are following the practice in PCE WG. PCEP RFCs all have these sections, and it is recommended in RFC6123. How about let's keep the text, readers can skip the text if they do not want to read it. GV2> okay. It was not blocking and seemed as not needed text. If it is the practice, then it seems correct to keep the paragraphs G/ _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
