Hi Kaelin, Approved.
Cheers, Jeff > On Sep 3, 2025, at 11:22, Kaelin Foody <[email protected]> wrote: > > 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) >> <[email protected]> wrote: >> >> Hi Kaelin, >> >> Please find this Approved. >> >> Be well, >> G/ >> >> -----Original Message----- >> From: Kaelin Foody <[email protected]> >> Sent: Friday, August 22, 2025 10:48 PM >> To: Gunter van de Velde (Nokia) <[email protected]> >> Cc: Dhruv Dhody <[email protected]>; Vishnu Pavan Beeram >> <[email protected]>; [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected]; [email protected]; >> [email protected] >> 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 <[email protected]> >>>> 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 <[email protected]> >>>> wrote: >>>> >>>> Hi Dhruv, >>>> >>>> Thank you for your reply. We have made those changes and updated our files >>>> accordingly. >>>> >>>> To confirm, no additional changes are needed per the following, correct? >>>> As noted in our previous email, we manually updated only the lines that >>>> xml2rfc warned were too long, but we wanted to make you aware of the >>>> additional block that was included when we regenerated the tree in case >>>> additional updates are needed. >>>> >>>>> We also created a test file in which we replaced the full YANG tree in >>>>> Appendix A with the regenerated tree. There were additional wrapped lines >>>>> (that had not prompted warnings by xml2rfc) and an added block. >>>>> We didn’t make any additional updates, but please review and let us know >>>>> if any further updates are needed. See this diff file: >>>>> >>>>> https://www.rfc-editor.org/authors/rfc9826-TEST2-rfcdiff.html >>>> >>>> The updated files are posted below (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9826.xml >>>> https://www.rfc-editor.org/authors/rfc9826.txt >>>> https://www.rfc-editor.org/authors/rfc9826.pdf >>>> https://www.rfc-editor.org/authors/rfc9826.html >>>> >>>> Diff files showing all changes made during AUTH48: >>>> https://www.rfc-editor.org/authors/rfc9826-auth48diff.html >>>> https://www.rfc-editor.org/authors/rfc9826-auth48rfcdiff.html (side >>>> by side) >>>> >>>> Diff files showing all changes: >>>> https://www.rfc-editor.org/authors/rfc9826-diff.html >>>> https://www.rfc-editor.org/authors/rfc9826-rfcdiff.html (side by >>>> side) >>>> >>>> The AUTH48 status page for this document is available here: >>>> https://www.rfc-editor.org/auth48/rfc9826 >>>> >>>> Thank you, >>>> RFC Editor/kf >>>> >>>>> On Aug 17, 2025, at 2:36 AM, Dhruv Dhody <[email protected]> wrote: >>>>> >>>>> Hi Kaelin, >>>>> >>>>> On Sat, Aug 16, 2025 at 2:32 AM Kaelin Foody >>>>> <[email protected]> wrote: >>>>> Hi Dhruv, >>>>> >>>>> Thank you for your reply. We have updated our files to reflect your >>>>> changes. We have a few follow-up questions: >>>>> >>>>> >>>>>> 3) <!-- [rfced] We have a few questions about the text below in Section >>>>>> 3. >>>>>> >>>>>> a) It seems that some of the terms in the list are defined in RFC >>>>>> 8051 rather than in RFC 8231 (specifically, Stateful PCE, Passive >>>>>> Stateful PCE, Active Stateful PCE, and Delegation). If you agree, >>>>>> we will create a separate list for these as shown below and add a >>>>>> normative reference to RFC 8051. >>>>>> >>>>>> Dhruv: I am okay with doing that provided it does not cause issues with >>>>>> DownRef. >>>>> >>>>> Thank you for mentioning the possibility of a downrefs issue. Would >>>>> you like to update as suggested (with RFC 8051 as an informative >>>>> reference), not update (and retain the reference to RFC 8231), or >>>>> something else? >>>>> >>>>> Note that Section 2 of RFC 8231 states: >>>>> >>>>> This document uses the following terms defined in [RFC8051]: >>>>> Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, >>>>> and LSP State Database. >>>>> >>>>> >>>>> >>>>> Dhruv: My preference would be for an informative reference to RFC 8051 >>>>> and the update as you suggest. >>>>> >>>>>> d.) For the "ietf-pcep-stats" YANG module, the first and last >>>>>> sentence in the the "Readable nodes section" vary from the template. Are >>>>>> any updates needed? >>>>>> >>>>>> Document: >>>>>> The readable data nodes in this YANG module may be considered >>>>>> sensitive or vulnerable in some network environments. It is thus >>>>>> important to control read access (e.g., via get, get-config, or >>>>>> notification) to these data nodes. The statistics could provide >>>>>> information related to the current usage patterns of the network. >>>>>> >>>>>> Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): >>>>>> Some of the readable data nodes in this YANG module may be >>>>>> considered sensitive or vulnerable in some network environments. It >>>>>> is thus important to control read access (e.g., via get, >>>>>> get-config, or notification) to these data nodes. Specifically, the >>>>>> following subtrees and data nodes have particular >>>>>> sensitivities/vulnerabilities: >>>>>> >>>>>> Dhruv: Please use the template >>>>> >>>>> Note that we have not yet made this update because the last sentence in >>>>> the template indicates that additional text about the subtrees and data >>>>> nodes along with their particular sensitivities/vulnerabilities is needed. >>>>> Please review and confirm how to update. >>>>> >>>>> >>>>> Dhruv: >>>>> >>>>> CURRENT: >>>>> The "ietf-pcep-stats" YANG module: >>>>> This document also includes another YANG module (called >>>>> "ietf-pcep-stats") for maintaining the statistics by augmenting the >>>>> "ietf-pcep" YANG module. >>>>> There are no particularly sensitive writable data nodes. >>>>> The readable data nodes in this YANG module may be considered sensitive >>>>> or vulnerable in some network environments. It is thus important to >>>>> control read access (e.g., via get, get-config, or notification) to these >>>>> data nodes. The statistics could provide information related to the >>>>> current usage patterns of the network. >>>>> Some of the RPC or action operations in this YANG module may be >>>>> considered sensitive or vulnerable in some network environments. It is >>>>> thus important to control access to these operations. Specifically, the >>>>> following operation has particular sensitivities/vulnerabilities: >>>>> • reset-pcep-statistics-all: The RPC is used to reset all PCEP statistics >>>>> across all peers and sessions. An unauthorized reset could impact >>>>> monitoring. >>>>> NEW: >>>>> The "ietf-pcep-stats" YANG module: >>>>> There are no particularly sensitive writable data nodes. >>>>> There are no particularly sensitive readable data nodes. >>>>> Some of the RPC or action operations in this YANG module may be >>>>> considered sensitive or vulnerable in some network environments. It is >>>>> thus important to control access to these operations. Specifically, the >>>>> following operations have particular sensitivities/ vulnerabilities: >>>>> • reset-pcep-statistics-all: The RPC is used to reset all PCEP statistics >>>>> across all peers and sessions. An unauthorized reset could impact >>>>> monitoring. >>>>> END >>>>> >>>>> Since there are no writable data nodes, you may even remove the first >>>>> sentence, but it was not clear from the template if that is the preferred >>>>> option. >>>>> The additional text about reusable groupings and no data nodes are not >>>>> applicable. >>>>> >>>>> >>>>>> 12) <!-- [rfced] What is meant by "The initial document" and "above >>>>>> document" here? >>>>>> >>>>>> Original: >>>>>> The initial document is based on the PCEP MIB [RFC7420]. The >>>>>> authors of this document would like to thank the authors of the >>>>>> above document. >>>>>> >>>>>> Perhaps: >>>>>> This document is based on the PCEP MIB [RFC7420]. The authors of >>>>>> this document would like to thank the authors of [RFC7420]. >>>>>> --> >>>>>> >>>>>> Dhruv: Maybe the initial revision? >>>>> >>>>> For question 12 above, would the following update be correct? >>>>> >>>>> Original: >>>>> The initial document is based on the PCEP MIB [RFC7420]. The authors >>>>> of this document would like to thank the authors of the above >>>>> document. >>>>> >>>>> Perhaps: >>>>> The initial draft version of this document was based on the PCEP MIB >>>>> [RFC7420]. The authors of this document would like to thank the authors >>>>> of [RFC7420]. >>>>> >>>>> >>>>> Dhruv: Ack >>>>> >>>>> >>>>>> 15) <!-- [rfced] Sourcecode >>>>>> >>>>>> b) Some lines in the tree diagrams in Section 4.1.1 and Appendix A >>>>>> extend beyond the margin in the txt output. How may we break these >>>>>> lines so they fit within the 69-character limit for sourcecode? We >>>>>> can use the line wrapping described in Section 7 of RFC 8792, but >>>>>> we first want to confirm that this the best solution here. Perhaps >>>>>> removing some space between items (especially for the last two lines >>>>>> below) would be another option. >>>>>> >>>>>> Same four lines in both Section 4.1.1 and Appendix A: >>>>>> >>>>>> rw pce-initiated? boolean {pce-initiated}? >>>>>> >>>>>> :(hexadecimal) {key-chain:hex-key-string}? >>>>>> >>>>>> rw hexadecimal-string? yang:hex-string >>>>>> >>>>>> ro role? -> ../../../role >>>>>> >>>>>> Note: We only included the portion of the line after the double >>>>>> dash in order to include the lines in this xml comment. >>>>>> --> >>>>>> >>>>>> Dhruv: Is it possible to regenerate the tree via pyang --ietf >>>>>> --lint -f tree --tree-line-length=68 --tree-depth=10 >>>>> >>>>> For question 15b, we tried out your suggestion above. After regenerating >>>>> the tree, we manually updated the lines that xml2rfc warned were too long >>>>> (see warnings below). >>>>> These changes are best viewed in the rfc9826-auth48rfcdiff.html or >>>>> rfc9826-rfcdiff.html files. >>>>> >>>>> Section 4.1.1 (peer list) >>>>> Warning: Too long line found (L717), 2 characters longer than 72 >>>>> characters: | +--rw pce-initiated? boolean >>>>> {pce-initiated}? >>>>> Warning: Too long line found (L760), 2 characters longer than 72 >>>>> characters: | | +--:(hexadecimal) >>>>> {key-chain:hex-key-string}? >>>>> Warning: Too long line found (L761), 3 characters longer than 72 >>>>> characters: | | +--rw hexadecimal-string? >>>>> yang:hex-string >>>>> >>>>> Section 4.1.1.1 (session list) >>>>> Warning: Too long line found (L811), 2 characters longer than 72 >>>>> characters: +--ro role? -> >>>>> ../../../role >>>>> >>>>> Appendix A (full tree) >>>>> Warning: Too long line found (L5354), 2 characters longer than 72 >>>>> characters: | +--rw pce-initiated? boolean >>>>> {pce-initiated}? >>>>> Warning: Too long line found (L5397), 2 characters longer than 72 >>>>> characters: | | +--:(hexadecimal) >>>>> {key-chain:hex-key-string}? >>>>> Warning: Too long line found (L5398), 3 characters longer than 72 >>>>> characters: | | +--rw hexadecimal-string? >>>>> yang:hex-string >>>>> Warning: Too long line found (L5416), 2 characters longer than 72 >>>>> characters: +--ro role? -> >>>>> ../../../role >>>>> >>>>> >>>>> We also created a test file in which we replaced the full YANG tree in >>>>> Appendix A with the regenerated tree. There were additional wrapped lines >>>>> (that had not prompted warnings by xml2rfc) and an added block. >>>>> We didn’t make any additional updates, but please review and let us know >>>>> if any further updates are needed. See this diff file: >>>>> >>>>> https://www.rfc-editor.org/authors/rfc9826-TEST2-rfcdiff.html >>>>> >>>>> >>>>> Dhruv: I have reviewed and am happy with the change! >>>>> >>>>> Thanks! >>>>> Dhruv >>>>> >>>>> >>>>> The updated files are posted below (please refresh): >>>>> >>>>> Updated XML file: >>>>> https://www.rfc-editor.org/authors/rfc9826.xml >>>>> >>>>> Updated output files: >>>>> https://www.rfc-editor.org/authors/rfc9826.txt >>>>> https://www.rfc-editor.org/authors/rfc9826.pdf >>>>> https://www.rfc-editor.org/authors/rfc9826.html >>>>> >>>>> Diff file showing all changes made during AUTH48: >>>>> https://www.rfc-editor.org/authors/rfc9826-auth48diff.html >>>>> https://www.rfc-editor.org/authors/rfc9826-auth48rfcdiff.html (side >>>>> by side) >>>>> >>>>> Diff files showing all changes: >>>>> https://www.rfc-editor.org/authors/rfc9826-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9826-rfcdiff.html (side by >>>>> side) >>>>> >>>>> The AUTH48 status page for this document is available here: >>>>> https://www.rfc-editor.org/auth48/rfc9826 >>>>> >>>>> Thank you. >>>>> RFC Editor/kf >>>>> >>>>>> On Aug 13, 2025, at 5:41 AM, Dhruv Dhody <[email protected]> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Apologies for delay in reply. I have reviewed the diff. Please see >>>>>> the answers to your questions inline - >>>>>> >>>>>> On Fri, Jul 25, 2025 at 11:31 PM <[email protected]> wrote: >>>>>> Authors, >>>>>> >>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>> necessary) the following questions, which are also in the XML file. >>>>>> >>>>>> >>>>>> 1) <!-- [rfced] FYI - We updated the abbreviated title (appears in >>>>>> the header of this document's PDF output) as follows. >>>>>> >>>>>> Original: >>>>>> PCE-YANG >>>>>> >>>>>> Updated: >>>>>> YANG Data Model for PCEP >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Ok. >>>>>> >>>>>> >>>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that >>>>>> appear in the title) for use on https://www.rfc-editor.org/search. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: PCE YANG, PCEP YANG, PCC YANG >>>>>> >>>>>> >>>>>> 3) <!-- [rfced] We have a few questions about the text below in Section >>>>>> 3. >>>>>> >>>>>> a) It seems that some of the terms in the list are defined in RFC >>>>>> 8051 rather than in RFC 8231 (specifically, Stateful PCE, Passive >>>>>> Stateful PCE, Active Stateful PCE, and Delegation). If you agree, >>>>>> we will create a separate list for these as shown below and add a >>>>>> normative reference to RFC 8051. >>>>>> >>>>>> >>>>>> Dhruv: I am okay with doing that provided it does not cause issues with >>>>>> DownRef. >>>>>> >>>>>> b) In the first two bullets, more than one term appears in a single >>>>>> bullet item. If no objections, we will separate these into separate >>>>>> bullets as shown below. >>>>>> >>>>>> >>>>>> Dhruv: Ok >>>>>> >>>>>> c) Note that we updated the third and fourth bullets (regarding >>>>>> PCRpt and >>>>>> PCUpd) as shown below per Sections 6.1 and 6.2 of RFC 8231. Let us >>>>>> know any concerns. >>>>>> >>>>>> Original: >>>>>> Further, this document also uses the following terms defined in >>>>>> [RFC8231] : >>>>>> >>>>>> * Stateful PCE, Passive Stateful PCE, Active Stateful PCE >>>>>> >>>>>> * Delegation, Revocation, Redelegation >>>>>> >>>>>> * LSP State Report, Path Computation Report message (PCRpt). >>>>>> >>>>>> * LSP State Update, Path Computation Update message (PCUpd). >>>>>> >>>>>> * PLSP-ID: a PCEP-specific identifier for the LSP. >>>>>> >>>>>> * SRP: Stateful PCE Request Parameters >>>>>> >>>>>> Perhaps: >>>>>> Further, this document uses the following terms defined in [RFC8051]: >>>>>> >>>>>> * Stateful PCE >>>>>> >>>>>> * Passive Stateful PCE >>>>>> >>>>>> * Active Stateful PCE >>>>>> >>>>>> * Delegation >>>>>> >>>>>> In addition, this document uses the following terms defined in [RFC8231]: >>>>>> >>>>>> * Revocation >>>>>> >>>>>> * Redelegation >>>>>> >>>>>> * Path Computation LSP State Report (PCRpt) message >>>>>> >>>>>> * Path Computation LSP Update Request (PCUpd) message >>>>>> >>>>>> * PLSP-ID (a PCEP-specific identifier for the LSP) >>>>>> >>>>>> * Stateful PCE Request Parameter (SRP) >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: I am okay with these changes. >>>>>> >>>>>> >>>>>> 4) <!-- [rfced] We have condensed this text in Section 3 as >>>>>> follows. Please let us know any concerns. >>>>>> >>>>>> Original: >>>>>> >>>>>> [RFC8408] : >>>>>> >>>>>> * Path Setup Type (PST). >>>>>> >>>>>> [RFC8664] : >>>>>> >>>>>> * Segment Routing (SR). >>>>>> >>>>>> [RFC5541] : >>>>>> >>>>>> * Objective Function (OF). >>>>>> >>>>>> [RFC8697] : >>>>>> >>>>>> * Association. >>>>>> >>>>>> [RFC6241] : >>>>>> >>>>>> * Configuration data. >>>>>> >>>>>> * State data. >>>>>> >>>>>> Updated: >>>>>> Last, this document uses the following terms, which are defined in >>>>>> the RFCs indicated below: >>>>>> >>>>>> * Path Setup Type (PST) [RFC8408] >>>>>> >>>>>> * Segment Routing (SR) [RFC8664] >>>>>> >>>>>> * Objective Function (OF) [RFC5541] >>>>>> >>>>>> * Association [RFC8697] >>>>>> >>>>>> * Configuration data [RFC6241] >>>>>> >>>>>> * State data [RFC6241] >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Ack >>>>>> >>>>>> >>>>>> 5) <!-- [rfced] In Section 3, may we order the items in each list >>>>>> alphabetically? >>>>>> Or do you prefer the current order? >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Please keep the current order. >>>>>> >>>>>> >>>>>> 6) <!-- [rfced] Because there are multiple tree diagrams used in >>>>>> this document, should plural "representations...are" rather than >>>>>> singular "representation...is" be used in this sentence? >>>>>> >>>>>> Original: >>>>>> A simplified graphical representation of the data model is used in >>>>>> this document. The meaning of the symbols in these diagrams is >>>>>> defined in [RFC8340]. >>>>>> >>>>>> Perhaps: >>>>>> Simplified graphical representations of the data model are used in >>>>>> this document. The meaning of the symbols in these diagrams is >>>>>> defined in [RFC8340]. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Agree >>>>>> >>>>>> >>>>>> 7) <!-- [rfced] The title and first sentence in Section 3.3 use >>>>>> "model", but the title of Table 2 uses "YANG modules". Should all >>>>>> three read "YANG modules"? Let us know if any updates would be helpful. >>>>>> >>>>>> Original: >>>>>> 3.3. References in the Model >>>>>> >>>>>> Following documents are referenced in the model defined in this >>>>>> document - >>>>>> ... >>>>>> Table 2: References in the YANG modules >>>>>> >>>>>> Perhaps: >>>>>> 3.3. References in the YANG Modules >>>>>> >>>>>> The following table lists the documents that are referenced in the YANG >>>>>> modules defined this document. >>>>>> ... >>>>>> Table 2: References in the YANG Modules >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: My preference is to use "YANG data model" as per >>>>>> https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-28.html#section-2.5 >>>>>> both in the section title, sentence and table title. >>>>>> >>>>>> >>>>>> 8) <!-- [rfced] In the third list item below, is "Path Computation >>>>>> Server (PCE)" >>>>>> meant to read as "Path Computation Element (PCE)"? >>>>>> >>>>>> Original: >>>>>> >>>>>> description >>>>>> "The role of a PCEP speaker. >>>>>> Takes one of the following values >>>>>> - unknown(0): the role is not known, >>>>>> - pcc(1): the role is of a Path Computation >>>>>> Client (PCC), >>>>>> - pce(2): the role is of a Path Computation >>>>>> Server (PCE), >>>>>> - pcc-and-pce(3): the role is of both a PCC and >>>>>> a PCE."; >>>>>> >>>>>> Perhaps: >>>>>> >>>>>> description >>>>>> "The role of a PCEP speaker. >>>>>> Takes one of the following values values: >>>>>> - unknown(0): the role is not known, >>>>>> - pcc(1): the role is of a Path Computation >>>>>> Client (PCC), >>>>>> - pce(2): the role is of a Path Computation >>>>>> Element (PCE), >>>>>> - pcc-and-pce(3): the role is of both a PCC and >>>>>> a PCE."; >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Yes, thanks for catching this! >>>>>> >>>>>> >>>>>> 9) <!-- [rfced] Is "this path-keys" correct in these description >>>>>> clauses? Or should "this path-keys" be updated to "this path-key" >>>>>> (singular)? >>>>>> >>>>>> Original: >>>>>> } >>>>>> leaf discard-time { >>>>>> type uint32; >>>>>> units "minutes"; >>>>>> description >>>>>> "A time after which this path-keys will be >>>>>> discarded"; >>>>>> } >>>>>> leaf reuse-time { >>>>>> type uint32; >>>>>> units "minutes"; >>>>>> description >>>>>> "A time after which this path-keys could be >>>>>> reused"; >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Correct, please make these singular. >>>>>> >>>>>> >>>>>> 10) <!-- [rfced] Security Considerations >>>>>> >>>>>> a.) We made some updates to this section to align with the template >>>>>> at <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please >>>>>> review. >>>>>> >>>>>> >>>>>> Dhruv: Okay. >>>>>> >>>>>> b.) FYI - We added headers to separate the information for each module. >>>>>> >>>>>> >>>>>> Dhruv: Okay. >>>>>> c.) The document includes "respective RFCs" in this sentence, but >>>>>> the template indicates that the RFCs should be listed. Are any updates >>>>>> needed here? >>>>>> >>>>>> Document: >>>>>> Refer to the Security Considerations of respective RFCs for >>>>>> information as to which nodes may be considered sensitive or >>>>>> vulnerable in network environments. >>>>>> >>>>>> Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): >>>>>> Refer to the Security Considerations of [RFC-insert-numbers] for >>>>>> information as to which nodes may be considered sensitive or >>>>>> vulnerable in network environments. >>>>>> >>>>>> >>>>>> Dhruv: Those RFCs are RFC9645 and RFC8776. d.) For the >>>>>> "ietf-pcep-stats" YANG module, the first and last sentence in the the >>>>>> "Readable nodes section" vary from the template. Are any updates needed? >>>>>> >>>>>> Document: >>>>>> The readable data nodes in this YANG module may be considered >>>>>> sensitive or vulnerable in some network environments. It is thus >>>>>> important to control read access (e.g., via get, get-config, or >>>>>> notification) to these data nodes. The statistics could provide >>>>>> information related to the current usage patterns of the network. >>>>>> >>>>>> Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): >>>>>> Some of the readable data nodes in this YANG module may be >>>>>> considered sensitive or vulnerable in some network environments. >>>>>> It is thus important to control read access (e.g., via get, >>>>>> get-config, or notification) to these data nodes. Specifically, >>>>>> the following subtrees and data nodes have particular >>>>>> sensitivities/vulnerabilities: >>>>>> >>>>>> >>>>>> Dhruv: Please use the template >>>>>> >>>>>> e.) For the "ietf-pcep-stats" YANG module, we do not see the >>>>>> "Reusable groupings from other modules section" or "No data nodes >>>>>> section" from the template. Please confirm that these sections do >>>>>> not apply to this YANG module. >>>>>> >>>>>> >>>>>> Dhruv: Yes they do not apply! >>>>>> >>>>>> f.) The following paragraphs (pertaining to the "ietf-pcep" YANG >>>>>> module) do not appear in the template. Do these paragraphs pertain >>>>>> to any parts of the template (i.e., need to be bulleted lists under >>>>>> a part of the template)? Or are these okay as is? >>>>>> >>>>>> Original: >>>>>> The actual authentication key data (whether locally specified or >>>>>> part of a key-chain) is sensitive and needs to be kept secret from >>>>>> unauthorized parties; compromise of the key data would allow an >>>>>> attacker to forge PCEP traffic that would be accepted as authentic, >>>>>> potentially compromising the TE domain. >>>>>> >>>>>> The model describes several notifications, implementations must >>>>>> rate- limit the generation of these notifications to avoid >>>>>> creating a significant notification load. Otherwise, this >>>>>> notification load may have some side effects on the system >>>>>> stability and may be exploited as an attack vector. >>>>>> >>>>>> The "auth" container includes various authentication and security >>>>>> options for PCEP. Further, Section 7.1 describes how to configure >>>>>> TLS1.2 and TLS1.3 for a PCEP session via this YANG module. >>>>>> >>>>>> >>>>>> Dhruv: They are not part of the template but extra information related >>>>>> to this model. They are okay as is. >>>>>> >>>>>> g.) Note that we will ask the AD to approve the changes to the >>>>>> Security Considerations after the questions above have been addressed. >>>>>> --> >>>>>> >>>>>> >>>>>> 11) <!-- [rfced] Would it be helpful to specify which module is >>>>>> being referred to in the phrase "in the YANG Module"? >>>>>> >>>>>> Original: >>>>>> The example below provides an overview of PCEP peer session >>>>>> information and LSP-DB in the YANG Module. >>>>>> >>>>>> Perhaps: >>>>>> The example below provides an overview of PCEP peer session >>>>>> information and LSP-DB in the "ietf-pcep" module. >>>>>> --> >>>>>> >>>>>> Dhruv: yes, please change. >>>>>> >>>>>> >>>>>> 12) <!-- [rfced] What is meant by "The initial document" and "above >>>>>> document" here? >>>>>> >>>>>> Original: >>>>>> The initial document is based on the PCEP MIB [RFC7420]. The >>>>>> authors of this document would like to thank the authors of the >>>>>> above document. >>>>>> >>>>>> Perhaps: >>>>>> This document is based on the PCEP MIB [RFC7420]. The authors of >>>>>> this document would like to thank the authors of [RFC7420]. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Maybe the initial revision? >>>>>> >>>>>> >>>>>> 13) <!-- [rfced] Only one name is listed for the following >>>>>> individuals in the Contributors section. Is either a surname or >>>>>> first name needed? Or are these okay as is? >>>>>> >>>>>> Current: >>>>>> Avantika >>>>>> ECI Telecom >>>>>> India >>>>>> Email: [email protected] >>>>>> >>>>>> >>>>>> Shashikanth >>>>>> India >>>>>> Email: [email protected] >>>>>> --> >>>>>> >>>>>> Dhruv: Yes. But change ECI Telecom to Ciena for Avantika. >>>>>> >>>>>> >>>>>> >>>>>> 14) <!-- [rfced] Some author comments are present in the XML. >>>>>> Please confirm that no updates related to these comments are >>>>>> outstanding. Note that the comments will be deleted prior to publication. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Please delete >>>>>> >>>>>> >>>>>> 15) <!-- [rfced] Sourcecode >>>>>> >>>>>> a) Note that, except for Figure 1, we updated all instances of >>>>>> <artwork> to either <sourcecode>, <dl> (in IANA Considerations >>>>>> section), or <contact> (in Contributors section). For the instances >>>>>> now tagged as <sourcecode>, we used either type="yangtree" or >>>>>> type="yang". Please review to confirm correctness. >>>>>> >>>>>> >>>>>> Dhruv: Ack >>>>>> >>>>>> b) Some lines in the tree diagrams in Section 4.1.1 and Appendix A >>>>>> extend beyond the margin in the txt output. How may we break these >>>>>> lines so they fit within the 69-character limit for sourcecode? We >>>>>> can use the line wrapping described in Section 7 of RFC 8792, but >>>>>> we first want to confirm that this the best solution here. Perhaps >>>>>> removing some space between items (especially for the last two lines >>>>>> below) would be another option. >>>>>> >>>>>> Same four lines in both Section 4.1.1 and Appendix A: >>>>>> >>>>>> rw pce-initiated? boolean {pce-initiated}? >>>>>> >>>>>> :(hexadecimal) {key-chain:hex-key-string}? >>>>>> >>>>>> rw hexadecimal-string? yang:hex-string >>>>>> >>>>>> ro role? -> ../../../role >>>>>> >>>>>> Note: We only included the portion of the line after the double >>>>>> dash in order to include the lines in this xml comment. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Is it possible to regenerate the tree via pyang --ietf >>>>>> --lint -f tree --tree-line-length=68 --tree-depth=10 >>>>>> >>>>>> >>>>>> 16) <!-- [rfced] We have received guidance from Benoit Claise and >>>>>> the YANG Doctors that "YANG data model" is preferred (instead of >>>>>> "YANG model"). We have updated the text to use this form. Please review. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: ok >>>>>> >>>>>> >>>>>> 17) <!-- [rfced] FYI - We see both American and British spellings >>>>>> in this document; for consistency, we updated to use American >>>>>> spelling. Please note that our updates include changing >>>>>> "neighbour-domains" to "neighbor-domains" in the YANG modules and tree >>>>>> diagrams. >>>>>> Let us know any concerns about these changes in the sourcecode. >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Ack >>>>>> >>>>>> >>>>>> 18) <!-- [rfced] We have added expansions for abbreviations upon >>>>>> first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please >>>>>> review each expansion in the document carefully to ensure correctness. >>>>>> >>>>>> Label Switched Paths (LSPs) >>>>>> Point-to-Multipoint (P2MP) >>>>>> Maximum SID Depth (MSD) >>>>>> LSP Database (LSP-DB) >>>>>> >>>>>> --> >>>>>> >>>>>> >>>>>> Dhruv: Ack >>>>>> >>>>>> >>>>>> 19) <!-- [rfced] Please review the "Inclusive Language" portion of >>>>>> the online Style Guide >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>>> and let us know if any changes are needed. Updates of this nature >>>>>> typically result in more precise language, which is helpful for readers. >>>>>> >>>>>> For example, please consider whether "sanity" should be updated in the >>>>>> text below: >>>>>> >>>>>> This YANG model defines a RPC to trigger state resynchronize at >>>>>> the PCE for sanity check with a particular PCC. --> >>>>>> >>>>>> >>>>>> >>>>>> Dhruv: The term comes from RFC 8232. Please keep it. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> RFC Editor/kf/rv >>>>>> >>>>>> >>>>>> >>>>>> Dhruv: Please change [YANG-PCEP-SR] to [YANG-PCEP-SRV6] >>>>>> >>>>>> Thanks! >>>>>> Dhruv >>>>>> >>>>>> >>>>>> >>>>>> On Jul 25, 2025, at 10:55 AM, [email protected] wrote: >>>>>> >>>>>> *****IMPORTANT***** >>>>>> >>>>>> Updated 2025/07/25 >>>>>> >>>>>> RFC Author(s): >>>>>> -------------- >>>>>> >>>>>> Instructions for Completing AUTH48 >>>>>> >>>>>> Your document has now entered AUTH48. Once it has been reviewed >>>>>> and approved by you and all coauthors, it will be published as an RFC. >>>>>> If an author is no longer available, there are several remedies >>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>> >>>>>> You and you coauthors are responsible for engaging other parties >>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>> your approval. >>>>>> >>>>>> Planning your review >>>>>> --------------------- >>>>>> >>>>>> Please review the following aspects of your document: >>>>>> >>>>>> * RFC Editor questions >>>>>> >>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>> that have been included in the XML file as comments marked as >>>>>> follows: >>>>>> >>>>>> <!-- [rfced] ... --> >>>>>> >>>>>> These questions will also be sent in a subsequent email. >>>>>> >>>>>> * Changes submitted by coauthors >>>>>> >>>>>> Please ensure that you review any changes submitted by your >>>>>> coauthors. We assume that if you do not speak up that you agree to >>>>>> changes submitted by your coauthors. >>>>>> >>>>>> * Content >>>>>> >>>>>> Please review the full content of the document, as this cannot >>>>>> change once the RFC is published. Please pay particular attention to: >>>>>> - IANA considerations updates (if applicable) >>>>>> - contact information >>>>>> - references >>>>>> >>>>>> * Copyright notices and legends >>>>>> >>>>>> Please review the copyright notice and legends as defined in RFC >>>>>> 5378 and the Trust Legal Provisions (TLP – >>>>>> https://trustee.ietf.org/license-info). >>>>>> >>>>>> * Semantic markup >>>>>> >>>>>> Please review the markup in the XML file to ensure that elements of >>>>>> content are correctly tagged. For example, ensure that >>>>>> <sourcecode> and <artwork> are set correctly. See details at >>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>> >>>>>> * Formatted output >>>>>> >>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>> formatted output, as generated from the markup in the XML file, is >>>>>> reasonable. Please note that the TXT will have formatting >>>>>> limitations compared to the PDF and HTML. >>>>>> >>>>>> >>>>>> Submitting changes >>>>>> ------------------ >>>>>> >>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as >>>>>> all the parties CCed on this message need to see your changes. The >>>>>> parties >>>>>> include: >>>>>> >>>>>> * your coauthors >>>>>> >>>>>> * [email protected] (the RPC team) >>>>>> >>>>>> * other document participants, depending on the stream (e.g., >>>>>> IETF Stream participants are your working group chairs, the >>>>>> responsible ADs, and the document shepherd). >>>>>> >>>>>> * [email protected], which is a new archival mailing list >>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>> list: >>>>>> >>>>>> * More info: >>>>>> >>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-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, >>>>>> [email protected] will be re-added to the CC list and >>>>>> its addition will be noted at the top of the message. >>>>>> >>>>>> You may submit your changes in one of two ways: >>>>>> >>>>>> An update to the provided XML file >>>>>> — OR — >>>>>> An explicit list of changes in this format >>>>>> >>>>>> Section # (or indicate Global) >>>>>> >>>>>> OLD: >>>>>> old text >>>>>> >>>>>> NEW: >>>>>> new text >>>>>> >>>>>> You do not need to reply with both an updated XML file and an >>>>>> explicit list of changes, as either form is sufficient. >>>>>> >>>>>> We will ask a stream manager to review and approve any changes that >>>>>> seem beyond editorial in nature, e.g., addition of new text, >>>>>> deletion of text, and technical changes. Information about stream >>>>>> managers can be found in the FAQ. Editorial changes do not require >>>>>> approval from a stream manager. >>>>>> >>>>>> >>>>>> Approving for publication >>>>>> -------------------------- >>>>>> >>>>>> To approve your RFC for publication, please reply to this email >>>>>> stating that you approve this RFC for publication. Please use >>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to see your >>>>>> approval. >>>>>> >>>>>> >>>>>> Files >>>>>> ----- >>>>>> >>>>>> The files are available here: >>>>>> https://www.rfc-editor.org/authors/rfc9826.xml >>>>>> https://www.rfc-editor.org/authors/rfc9826.html >>>>>> https://www.rfc-editor.org/authors/rfc9826.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9826.txt >>>>>> >>>>>> Diff file of the text: >>>>>> https://www.rfc-editor.org/authors/rfc9826-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9826-rfcdiff.html (side by >>>>>> side) >>>>>> >>>>>> Alt-diff of the text (allows you to more easily view changes where >>>>>> text has been deleted or moved): >>>>>> https://www.rfc-editor.org/authors/rfc9826-alt-diff.html >>>>>> >>>>>> Diff of the XML: >>>>>> https://www.rfc-editor.org/authors/rfc9826-xmldiff1.html >>>>>> >>>>>> >>>>>> Tracking progress >>>>>> ----------------- >>>>>> >>>>>> The details of the AUTH48 status of your document are here: >>>>>> https://www.rfc-editor.org/auth48/rfc9826 >>>>>> >>>>>> Please let us know if you have any questions. >>>>>> >>>>>> Thank you for your cooperation, >>>>>> >>>>>> RFC Editor >>>>>> >>>>>> -------------------------------------- >>>>>> RFC9826 (draft-ietf-pce-pcep-yang-30) >>>>>> >>>>>> Title : A YANG Data Model for Path Computation Element >>>>>> Communications Protocol (PCEP) >>>>>> Author(s) : D. Dhody, V. Beeram, J. Hardwick, J. Tantsura >>>>>> WG Chair(s) : Julien Meuric, Dhruv Dhody >>>>>> >>>>>> Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de >>>>>> Velde >>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
