Hi Dhruv, Thank you for your reply. We have updated our files to reflect your changes. We have a few follow-up questions:
> 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. > > Dhruv: I am okay with doing that provided it does not cause issues with > DownRef. Thank you for mentioning the possibility of a downrefs issue. Would you like to update as suggested (with RFC 8051 as an informative reference), not update (and retain the reference to RFC 8231), or something else? Note that Section 2 of RFC 8231 states: This document uses the following terms defined in [RFC8051]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, and LSP State Database. > 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: > > Dhruv: Please use the template Note that we have not yet made this update because the last sentence in the template indicates that additional text about the subtrees and data nodes along with their particular sensitivities/vulnerabilities is needed. Please review and confirm how to update. > 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]. > --> > > Dhruv: Maybe the initial revision? For question 12 above, would the following update be correct? 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: The initial draft version of this document was based on the PCEP MIB [RFC7420]. The authors of this document would like to thank the authors of [RFC7420]. > 15) <!-- [rfced] Sourcecode > > 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. > --> > > Dhruv: Is it possible to regenerate the tree via pyang --ietf --lint -f tree > --tree-line-length=68 --tree-depth=10 For question 15b, we tried out your suggestion above. After regenerating the tree, we manually updated the lines that xml2rfc warned were too long (see warnings below). These changes are best viewed in the rfc9826-auth48rfcdiff.html or rfc9826-rfcdiff.html files. Section 4.1.1 (peer list) Warning: Too long line found (L717), 2 characters longer than 72 characters: | +--rw pce-initiated? boolean {pce-initiated}? Warning: Too long line found (L760), 2 characters longer than 72 characters: | | +--:(hexadecimal) {key-chain:hex-key-string}? Warning: Too long line found (L761), 3 characters longer than 72 characters: | | +--rw hexadecimal-string? yang:hex-string Section 4.1.1.1 (session list) Warning: Too long line found (L811), 2 characters longer than 72 characters: +--ro role? -> ../../../role Appendix A (full tree) Warning: Too long line found (L5354), 2 characters longer than 72 characters: | +--rw pce-initiated? boolean {pce-initiated}? Warning: Too long line found (L5397), 2 characters longer than 72 characters: | | +--:(hexadecimal) {key-chain:hex-key-string}? Warning: Too long line found (L5398), 3 characters longer than 72 characters: | | +--rw hexadecimal-string? yang:hex-string Warning: Too long line found (L5416), 2 characters longer than 72 characters: +--ro role? -> ../../../role We also created a test file in which we replaced the full YANG tree in Appendix A with the regenerated tree. There were additional wrapped lines (that had not prompted warnings by xml2rfc) and an added block. We didn’t make any additional updates, but please review and let us know if any further updates are needed. See this diff file: https://www.rfc-editor.org/authors/rfc9826-TEST2-rfcdiff.html The updated files are posted below (please refresh): Updated XML file: https://www.rfc-editor.org/authors/rfc9826.xml Updated output files: https://www.rfc-editor.org/authors/rfc9826.txt https://www.rfc-editor.org/authors/rfc9826.pdf https://www.rfc-editor.org/authors/rfc9826.html Diff file showing all changes made during AUTH48: https://www.rfc-editor.org/authors/rfc9826-auth48diff.html https://www.rfc-editor.org/authors/rfc9826-auth48rfcdiff.html (side by side) Diff files showing all changes: https://www.rfc-editor.org/authors/rfc9826-diff.html https://www.rfc-editor.org/authors/rfc9826-rfcdiff.html (side by side) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9826 Thank you. RFC Editor/kf > On Aug 13, 2025, at 5:41 AM, Dhruv Dhody <d...@dhruvdhody.com> wrote: > > Hi, > > Apologies for delay in reply. I have reviewed the diff. Please see the > answers to your questions inline - > > On Fri, Jul 25, 2025 at 11:31 PM <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 > --> > > > Dhruv: Ok. > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. --> > > > Dhruv: PCE YANG, PCEP YANG, PCC YANG > > > 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. > > > Dhruv: I am okay with doing that provided it does not cause issues with > DownRef. > > 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. > > > Dhruv: Ok > > 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) > --> > > > Dhruv: I am okay with these changes. > > > 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] > --> > > > Dhruv: Ack > > > 5) <!-- [rfced] In Section 3, may we order the items in each list > alphabetically? > Or do you prefer the current order? > --> > > > Dhruv: Please keep 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]. > --> > > > Dhruv: Agree > > > 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 > > --> > > > Dhruv: My preference is to use "YANG data model" as per > https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-28.html#section-2.5 > both in the section title, sentence and table title. > > > 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."; > --> > > > Dhruv: Yes, thanks for catching this! > > > 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"; > --> > > > Dhruv: Correct, please make these singular. > > > 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. > > > Dhruv: Okay. > > b.) FYI - We added headers to separate the information for each module. > > > Dhruv: Okay. > 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. > > > Dhruv: Those RFCs are RFC9645 and RFC8776. 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: > > > Dhruv: Please use the template > > 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. > > > Dhruv: Yes they do not apply! > > 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. > > > Dhruv: They are not part of the template but extra information related to > this model. They are okay as is. > > 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. > --> > > Dhruv: yes, please change. > > > 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]. > --> > > > Dhruv: Maybe the initial revision? > > > 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 > --> > > Dhruv: Yes. But change ECI Telecom to Ciena for Avantika. > > > > 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. > --> > > > Dhruv: Please delete > > > 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. > > > Dhruv: Ack > > 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. > --> > > > Dhruv: Is it possible to regenerate the tree via pyang --ietf --lint -f tree > --tree-line-length=68 --tree-depth=10 > > > 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. > --> > > > Dhruv: ok > > > 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. > --> > > > Dhruv: Ack > > > 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) > > --> > > > Dhruv: Ack > > > 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. --> > > > > Dhruv: The term comes from RFC 8232. Please keep it. > > Thank you. > > RFC Editor/kf/rv > > > > Dhruv: Please change [YANG-PCEP-SR] to [YANG-PCEP-SRV6] > > Thanks! > Dhruv > > > > 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
