Hi Kaelin, On Fri, Aug 22, 2025 at 8:30 PM Kaelin Foody <kfo...@staff.rfc-editor.org> 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 <d...@dhruvdhody.com> 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 < > kfo...@staff.rfc-editor.org> 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 <d...@dhruvdhody.com> wrote: > > > > > > Hi Kaelin, > > > > > > On Sat, Aug 16, 2025 at 2:32 AM Kaelin Foody < > kfo...@staff.rfc-editor.org> 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 <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
