Hi authors, This is a friendly reminder that we await answers to the questions below and your review of the document before continuing with the publication process.
Thank you, RFC Editor/rv > On Jul 25, 2025, at 11:01 AM, rfc-edi...@rfc-editor.org wrote: > > 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
