Hi Gunter (as AD)*, *AD - Some updates were made to the Security Considerations section of this document. Please review the following changes along with the notes below and let us know if you approve.
The changes are best viewed in these diff files: https://www.rfc-editor.org/authors/rfc9826-diff.html https://www.rfc-editor.org/authors/rfc9826-rfcdiff.html (side by side) 1) Some changes were made to align with the template at <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Note that the first three paragraphs apply to both YANG modules defined in the document. We added headers after these three paragraphs to separate information for each module. 2) For the "ietf-pcep" YANG module, this sentence was not present in the “No data nodes section”; it has been added. From the guidelines page: For example, reusing some of these groupings will expose privacy-related information (e.g., 'node-example'). 3) For the "ietf-pcep" YANG module, we updated “respective RFCs” as follows per the author’s response. Original: Refer to the Security Considerations of respective RFCs for information as to which nodes may be considered sensitive or vulnerable in network environments. Updated: Refer to the Security Considerations of [RFC9645] and [RFC8776] for information as to which nodes may be considered sensitive or vulnerable in network environments. 4) For the "ietf-pcep" YANG module, the following paragraphs do not seem to be within a section of the template. Author comment: “They are not part of the template but extra information related to this model. They are okay as is.” Original: Unauthorized access to the above list can adversely affect the PCEP session between the local entity and the peers. This may lead to the inability to compute new paths, and stateful operations on the delegated as well as PCE-initiated LSPs. … 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. 5) The following change was made in the text about the "ietf-pcep-stats" YANG module during AUTH48 (the “Writable nodes” and “Readable nodes” sections of the template). Original Further, 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 data nodes defined in this module which are writable/creatable/deletable (i.e., config true). 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. Current: There are no particularly sensitive writable data nodes. There are no particularly sensitive readable data nodes. 6) Lastly, for the "ietf-pcep-stats" YANG module, the “Reusable groupings from other modules section" and "No data nodes section" from the template are not included. The author notes that these do not apply. Thank you, RFC Editor/kf > On Aug 20, 2025, at 8:57 AM, 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 > > 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
