Hi Jon and Pavan, Thanks for your replies. We have marked both of your approvals on the AUTH48 status page.
The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9826 We will await approvals from each of the remaining parties listed on the AUTH48 status page prior to moving forward with publication. Thank you, RFC Editor/kf > On Aug 26, 2025, at 4:44 PM, Jonathan Hardwick > <[email protected]> wrote: > > Hi Kaelin > > Please add my approval to Dhruv's. Thanks all! > > Best regards > Jon > > > On Tue, 26 Aug 2025, 19:12 Kaelin Foody, <[email protected]> wrote: > Hi Dhruv, > > Thanks for your reply and for confirming those YANG trees look correct. We > have marked your approval on the AUTH48 status page. > > We will await approvals from each of the parties listed on the AUTH48 status > page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9826 > > Thank you, > RFC Editor/kf > > > On Aug 25, 2025, at 7:11 AM, Dhruv Dhody <[email protected]> wrote: > > > > Hi Kaelin, > > > > On Fri, Aug 22, 2025 at 8:30 PM Kaelin Foody <[email protected]> > > wrote: > > Hi Dhruv, > > > > Thank you for your reply. We have updated the document accordingly. > > > > Please make sure to review the lines added to the YANG trees in Section 4.1 > > and Appendix A to ensure correctness. > > > > > > Dhruv: This has been reviewed thanks for your work! > > > > Please contact us with any further updates or questions you may have. We > > will await approvals from each of the parties listed on the AUTH48 status > > page prior to moving forward to publication. > > > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9826 > > > > > > Dhruv: Please mark my approval. > > > > Co-authors, please check and send your approval for AUTH48! > > > > Thanks! > > Dhruv > > > > The updated files are posted below (please refresh): > > https://www.rfc-editor.org/authors/rfc9826.xml > > 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 files showing 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) > > > > Thank you, > > RFC Editor/kf > > > > > On Aug 21, 2025, at 3:26 AM, Dhruv Dhody <[email protected]> wrote: > > > > > > Hi Kaelin, > > > > > > Two things... > > > > > > (1) Please remove the "No data nodes section:" from the security > > > consideration section for "ietf-pcep", as that is only applicable in case > > > other sections about writable and readable nodes are not applicable - > > > > > > The YANG module defines a set of identities, types, and groupings. These > > > nodes are intended to be reused by other YANG modules. The module by > > > itself does not expose any data nodes that are writable, data nodes that > > > contain read-only state, or RPCs. As such, there are no additional > > > security issues related to the YANG module that need to be considered. > > > > > > Modules that use the groupings that are defined in this document should > > > identify the corresponding security considerations. For example, reusing > > > some of these groupings will expose privacy-related information (e.g., > > > 'node-example'). > > > > > > > > > On Wed, Aug 20, 2025 at 6:28 PM Kaelin Foody > > > <[email protected]> wrote: > > > Hi Dhruv, > > > > > > Thank you for your reply. We have made those changes and updated our > > > files accordingly. > > > > > > To confirm, no additional changes are needed per the following, correct? > > > As noted in our previous email, we manually updated only the lines that > > > xml2rfc warned were too long, but we wanted to make you aware of the > > > additional block that was included when we regenerated the tree in case > > > additional updates are needed. > > > > 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 > > > > > > > > > Dhruv: (2) It would be good to make those additional updates to match > > > with what the tool is producing for Appendix A as well as in the tree in > > > section 4.1. Apologies as I was not clear on this earlier. > > > > > > Happy with all other changes. > > > > > > Thanks! > > > Dhruv > > > > > > The updated files are posted below (please refresh): > > > https://www.rfc-editor.org/authors/rfc9826.xml > > > 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 files 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 17, 2025, at 2:36 AM, Dhruv Dhody <[email protected]> wrote: > > > > > > > > Hi Kaelin, > > > > > > > > On Sat, Aug 16, 2025 at 2:32 AM Kaelin Foody > > > > <[email protected]> wrote: > > > > 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. > > > > > > > > > > > > > > > > Dhruv: My preference would be for an informative reference to RFC 8051 > > > > and the update as you suggest. > > > > > > > > > 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. > > > > > > > > > > > > Dhruv: > > > > > > > > CURRENT: > > > > The "ietf-pcep-stats" YANG module: > > > > This document also includes another YANG module (called > > > > "ietf-pcep-stats") for maintaining the statistics by augmenting the > > > > "ietf-pcep" YANG module. > > > > There are no particularly sensitive writable data nodes. > > > > 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. > > > > Some of the RPC or action operations in this YANG module may be > > > > considered sensitive or vulnerable in some network environments. It is > > > > thus important to control access to these operations. Specifically, the > > > > following operation has particular sensitivities/vulnerabilities: > > > > • reset-pcep-statistics-all: The RPC is used to reset all PCEP > > > > statistics across all peers and sessions. An unauthorized reset could > > > > impact monitoring. > > > > NEW: > > > > The "ietf-pcep-stats" YANG module: > > > > There are no particularly sensitive writable data nodes. > > > > There are no particularly sensitive readable data nodes. > > > > Some of the RPC or action operations in this YANG module may be > > > > considered sensitive or vulnerable in some network environments. It is > > > > thus important to control access to these operations. Specifically, the > > > > following operations have particular sensitivities/ vulnerabilities: > > > > • reset-pcep-statistics-all: The RPC is used to reset all PCEP > > > > statistics across all peers and sessions. An unauthorized reset could > > > > impact monitoring. > > > > END > > > > > > > > Since there are no writable data nodes, you may even remove the first > > > > sentence, but it was not clear from the template if that is the > > > > preferred option. > > > > The additional text about reusable groupings and no data nodes are not > > > > applicable. > > > > > > > > > > > > > 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]. > > > > > > > > > > > > Dhruv: Ack > > > > > > > > > > > > > 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 > > > > > > > > > > > > Dhruv: I have reviewed and am happy with the change! > > > > > > > > Thanks! > > > > Dhruv > > > > > > > > > > > > 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 <[email protected]> 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 <[email protected]> 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: [email protected] > > > > > > > > > > > > > > > Shashikanth > > > > > India > > > > > Email: [email protected] > > > > > --> > > > > > > > > > > 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, [email protected] 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 > > > > > > > > > > * [email protected] (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). > > > > > > > > > > * [email protected], 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, > > > > > [email protected] 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 -- [email protected] To unsubscribe send an email to [email protected]
