Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] FYI - We updated the abbreviated title (appears in the header of this document's PDF output) as follows. Original: PCE-YANG Updated: YANG Data Model for PCEP --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] We have a few questions about the text below in Section 3. a) It seems that some of the terms in the list are defined in RFC 8051 rather than in RFC 8231 (specifically, Stateful PCE, Passive Stateful PCE, Active Stateful PCE, and Delegation). If you agree, we will create a separate list for these as shown below and add a normative reference to RFC 8051. b) In the first two bullets, more than one term appears in a single bullet item. If no objections, we will separate these into separate bullets as shown below. c) Note that we updated the third and fourth bullets (regarding PCRpt and PCUpd) as shown below per Sections 6.1 and 6.2 of RFC 8231. Let us know any concerns. Original: Further, this document also uses the following terms defined in [RFC8231] : * Stateful PCE, Passive Stateful PCE, Active Stateful PCE * Delegation, Revocation, Redelegation * LSP State Report, Path Computation Report message (PCRpt). * LSP State Update, Path Computation Update message (PCUpd). * PLSP-ID: a PCEP-specific identifier for the LSP. * SRP: Stateful PCE Request Parameters Perhaps: Further, this document uses the following terms defined in [RFC8051]: * Stateful PCE * Passive Stateful PCE * Active Stateful PCE * Delegation In addition, this document uses the following terms defined in [RFC8231]: * Revocation * Redelegation * Path Computation LSP State Report (PCRpt) message * Path Computation LSP Update Request (PCUpd) message * PLSP-ID (a PCEP-specific identifier for the LSP) * Stateful PCE Request Parameter (SRP) --> 4) <!-- [rfced] We have condensed this text in Section 3 as follows. Please let us know any concerns. Original: [RFC8408] : * Path Setup Type (PST). [RFC8664] : * Segment Routing (SR). [RFC5541] : * Objective Function (OF). [RFC8697] : * Association. [RFC6241] : * Configuration data. * State data. Updated: Last, this document uses the following terms, which are defined in the RFCs indicated below: * Path Setup Type (PST) [RFC8408] * Segment Routing (SR) [RFC8664] * Objective Function (OF) [RFC5541] * Association [RFC8697] * Configuration data [RFC6241] * State data [RFC6241] --> 5) <!-- [rfced] In Section 3, may we order the items in each list alphabetically? Or do you prefer the current order? --> 6) <!-- [rfced] Because there are multiple tree diagrams used in this document, should plural "representations...are" rather than singular "representation...is" be used in this sentence? Original: A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [RFC8340]. Perhaps: Simplified graphical representations of the data model are used in this document. The meaning of the symbols in these diagrams is defined in [RFC8340]. --> 7) <!-- [rfced] The title and first sentence in Section 3.3 use "model", but the title of Table 2 uses "YANG modules". Should all three read "YANG modules"? Let us know if any updates would be helpful. Original: 3.3. References in the Model Following documents are referenced in the model defined in this document - ... Table 2: References in the YANG modules Perhaps: 3.3. References in the YANG Modules The following table lists the documents that are referenced in the YANG modules defined this document. ... Table 2: References in the YANG Modules --> 8) <!-- [rfced] In the third list item below, is "Path Computation Server (PCE)" meant to read as "Path Computation Element (PCE)"? Original: description "The role of a PCEP speaker. Takes one of the following values - unknown(0): the role is not known, - pcc(1): the role is of a Path Computation Client (PCC), - pce(2): the role is of a Path Computation Server (PCE), - pcc-and-pce(3): the role is of both a PCC and a PCE."; Perhaps: description "The role of a PCEP speaker. Takes one of the following values values: - unknown(0): the role is not known, - pcc(1): the role is of a Path Computation Client (PCC), - pce(2): the role is of a Path Computation Element (PCE), - pcc-and-pce(3): the role is of both a PCC and a PCE."; --> 9) <!-- [rfced] Is "this path-keys" correct in these description clauses? Or should "this path-keys" be updated to "this path-key" (singular)? Original: } leaf discard-time { type uint32; units "minutes"; description "A time after which this path-keys will be discarded"; } leaf reuse-time { type uint32; units "minutes"; description "A time after which this path-keys could be reused"; --> 10) <!-- [rfced] Security Considerations a.) We made some updates to this section to align with the template at <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please review. b.) FYI - We added headers to separate the information for each module. c.) The document includes "respective RFCs" in this sentence, but the template indicates that the RFCs should be listed. Are any updates needed here? Document: Refer to the Security Considerations of respective RFCs for information as to which nodes may be considered sensitive or vulnerable in network environments. Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): Refer to the Security Considerations of [RFC-insert-numbers] for information as to which nodes may be considered sensitive or vulnerable in network environments. d.) For the "ietf-pcep-stats" YANG module, the first and last sentence in the the "Readable nodes section" vary from the template. Are any updates needed? Document: The readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The statistics could provide information related to the current usage patterns of the network. Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities: e.) For the "ietf-pcep-stats" YANG module, we do not see the "Reusable groupings from other modules section" or "No data nodes section" from the template. Please confirm that these sections do not apply to this YANG module. f.) The following paragraphs (pertaining to the "ietf-pcep" YANG module) do not appear in the template. Do these paragraphs pertain to any parts of the template (i.e., need to be bulleted lists under a part of the template)? Or are these okay as is? Original: The actual authentication key data (whether locally specified or part of a key-chain) is sensitive and needs to be kept secret from unauthorized parties; compromise of the key data would allow an attacker to forge PCEP traffic that would be accepted as authentic, potentially compromising the TE domain. The model describes several notifications, implementations must rate- limit the generation of these notifications to avoid creating a significant notification load. Otherwise, this notification load may have some side effects on the system stability and may be exploited as an attack vector. The "auth" container includes various authentication and security options for PCEP. Further, Section 7.1 describes how to configure TLS1.2 and TLS1.3 for a PCEP session via this YANG module. g.) Note that we will ask the AD to approve the changes to the Security Considerations after the questions above have been addressed. --> 11) <!-- [rfced] Would it be helpful to specify which module is being referred to in the phrase "in the YANG Module"? Original: The example below provides an overview of PCEP peer session information and LSP-DB in the YANG Module. Perhaps: The example below provides an overview of PCEP peer session information and LSP-DB in the "ietf-pcep" module. --> 12) <!-- [rfced] What is meant by "The initial document" and "above document" here? Original: The initial document is based on the PCEP MIB [RFC7420]. The authors of this document would like to thank the authors of the above document. Perhaps: This document is based on the PCEP MIB [RFC7420]. The authors of this document would like to thank the authors of [RFC7420]. --> 13) <!-- [rfced] Only one name is listed for the following individuals in the Contributors section. Is either a surname or first name needed? Or are these okay as is? Current: Avantika ECI Telecom India Email: avantika....@gmail.com Shashikanth India Email: shash...@gmail.com --> 14) <!-- [rfced] Some author comments are present in the XML. Please confirm that no updates related to these comments are outstanding. Note that the comments will be deleted prior to publication. --> 15) <!-- [rfced] Sourcecode a) Note that, except for Figure 1, we updated all instances of <artwork> to either <sourcecode>, <dl> (in IANA Considerations section), or <contact> (in Contributors section). For the instances now tagged as <sourcecode>, we used either type="yangtree" or type="yang". Please review to confirm correctness. b) Some lines in the tree diagrams in Section 4.1.1 and Appendix A extend beyond the margin in the txt output. How may we break these lines so they fit within the 69-character limit for sourcecode? We can use the line wrapping described in Section 7 of RFC 8792, but we first want to confirm that this the best solution here. Perhaps removing some space between items (especially for the last two lines below) would be another option. Same four lines in both Section 4.1.1 and Appendix A: rw pce-initiated? boolean {pce-initiated}? :(hexadecimal) {key-chain:hex-key-string}? rw hexadecimal-string? yang:hex-string ro role? -> ../../../role Note: We only included the portion of the line after the double dash in order to include the lines in this xml comment. --> 16) <!-- [rfced] We have received guidance from Benoit Claise and the YANG Doctors that "YANG data model" is preferred (instead of "YANG model"). We have updated the text to use this form. Please review. --> 17) <!-- [rfced] FYI - We see both American and British spellings in this document; for consistency, we updated to use American spelling. Please note that our updates include changing "neighbour-domains" to "neighbor-domains" in the YANG modules and tree diagrams. Let us know any concerns about these changes in the sourcecode. --> 18) <!-- [rfced] We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Label Switched Paths (LSPs) Point-to-Multipoint (P2MP) Maximum SID Depth (MSD) LSP Database (LSP-DB) --> 19) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "sanity" should be updated in the text below: This YANG model defines a RPC to trigger state resynchronize at the PCE for sanity check with a particular PCC. --> Thank you. RFC Editor/kf/rv On Jul 25, 2025, at 10:55 AM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/07/25 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-edi...@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9826.xml https://www.rfc-editor.org/authors/rfc9826.html https://www.rfc-editor.org/authors/rfc9826.pdf https://www.rfc-editor.org/authors/rfc9826.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9826-diff.html https://www.rfc-editor.org/authors/rfc9826-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9826-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9826-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9826 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9826 (draft-ietf-pce-pcep-yang-30) Title : A YANG Data Model for Path Computation Element Communications Protocol (PCEP) Author(s) : D. Dhody, V. Beeram, J. Hardwick, J. Tantsura WG Chair(s) : Julien Meuric, Dhruv Dhody Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
