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. " 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/ 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 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. 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 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 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 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 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 _______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
