Hi Gunter, all, Thanks for your reply. We have marked your approval on the AUTH48 status page available below:
https://www.rfc-editor.org/auth48/rfc9826 We now only await approval from Jeff prior to moving this document forward in the publication process. Thank you, Kaelin Foody RFC Production Center > On Sep 1, 2025, at 3:06 AM, Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com> wrote: > > Hi Kaelin, > > Please find this Approved. > > Be well, > G/ > > -----Original Message----- > From: Kaelin Foody <kfo...@staff.rfc-editor.org> > Sent: Friday, August 22, 2025 10:48 PM > To: Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com> > Cc: Dhruv Dhody <d...@dhruvdhody.com>; Vishnu Pavan Beeram > <vishnupa...@gmail.com>; dhruv.i...@gmail.com; vbee...@juniper.net; > jonathan.e.hardw...@gmail.com; jefftant.i...@gmail.com; pce-...@ietf.org; > pce-cha...@ietf.org; julien.meu...@orange.com; auth48archive@rfc-editor.org; > rfc-edi...@rfc-editor.org > Subject: Re: [AD] AUTH48: RFC-to-be 9826 <draft-ietf-pce-pcep-yang-30> for > your review > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Hi Gunter, > > In addition to reviewing the updates made to the Security Considerations > section in the previous email, please also review the lines added to the YANG > trees in Section 4.1 and Appendix A, and let us know if you approve. These > changes are best viewed in this diff file: > https://www.rfc-editor.org/authors/rfc9826-diff.html. > > Also note that the paragraphs below have been removed for the "ietf-pcep” > module in the Security Considerations section. These paragraphs are the "No > data nodes section:” from the template at > <https://wiki.ietf.org/group/ops/yang-security-guidelines>. The author > requested that these be removed and notes that this section of the template > is "only applicable in case other sections about writable and readable nodes > are not applicable”. This change replaces item #2 in the email below. > > Removed: > 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’). > > Thanks again, > RFC Editor/kf > >> On Aug 20, 2025, at 4:14 PM, Kaelin Foody <kfo...@staff.rfc-editor.org> >> wrote: >> >> 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-4Q9l2U >>>>> SxIAe6P8O4Zc >>>>> >>>>> * 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
