Dear Sarah and Karen, Please, find resolutions inline after the "-->" mark. Many thanks for your efforts Bala'zs
-----Original Message----- From: [email protected] <[email protected]> Sent: Saturday, February 21, 2026 2:54 AM To: [email protected]; [email protected]; [email protected]; Balázs Varga A <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: AUTH48: RFC-to-be 9938 <draft-ietf-detnet-controller-plane-framework-15> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the source file. 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> Proposed keywords: DetNet, Controller plane, SDN 2) <!-- [rfced] We're having trouble understanding the parentheses in this sentence. Is the "set of documents" referring to A) all of the subsequently listed RFCs or B) just RFC 8938? Please let us know how we may update for clarity. Original: The DetNet data plane is defined in a set of documents that are anchored by the DetNet data plane framework [RFC8938] (as well as the associated DetNet MPLS defined in [RFC8964], the DetNet IP defined in [RFC8939], and other data plane specifications defined in [RFC9023], [RFC9024], [RFC9025], [RFC9037], and [RFC9056]). Perhaps A: The DetNet data plane is defined in a set of documents that are anchored by the DetNet data plane framework [RFC8938], which includes the associated DetNet MPLS defined in [RFC8964], the DetNet IP defined in [RFC8939], and other data plane specifications defined in [RFC9023], [RFC9024], [RFC9025], [RFC9037], and [RFC9056]. or Perhaps B: The DetNet data plane is defined in the DetNet data plane framework [RFC8938] (and is further explained in the associated DetNet MPLS [RFC8964], the DetNet IP [RFC8939], and other data plane specifications [RFC9023] [RFC9024] [RFC9025] [RFC9037] [RFC9056]). --> Please, go with Version-B. Thanks. 3) <!-- [rfced] We note that RFC 9055 and this document do not contain "Section 2.4". Please clarify if Section 2.3 of this document was perhaps intended. Current: In addition, security requirements for the DetNet Controller Plane have been discussed in [RFC9055], and a summary of those requirements is provided in Section 2.4. Perhaps: In addition, security requirements for the DetNet Controller Plane have been discussed in [RFC9055], and a summary of those requirements is provided in Section 2.3 of this document. --> The correct reference is "Section 5.2.5" NEW: In addition, security requirements for the DetNet Controller Plane have been discussed in [RFC9055], and a summary of those requirements is provided in Section 5.2.5 of this document. 4) <!-- [rfced] We note "SDN/Fully Centralized" vs. "fully SDN/centralized". May we remove the slashes and rephrase using "and" for clarity as shown below? Please let us know if this retains the intended meaning or if you prefer otherwise. Original: 3.2. SDN/Fully Centralized Control Plane In the fully SDN/centralized configuration model, flow/UNI information is transmitted from a centralized user controller or from applications via an API/ northbound interface to a centralized controller. Perhaps: 3.2. SDN and Fully Centralized Control Plane In the SDN and fully centralized configuration model, both flow and UNI information can be transmitted from a centralized user controller or from other applications, via an API or northbound interface, to a centralized controller. --> SDN is an example of the fully centralized method. Finetuned version of your proposal is below: NEW: 3.2. Fully Centralized Control Plane In the fully centralized configuration model (e.g., using an SDN controller), both flow and UNI information can be transmitted from a centralized user controller or from other applications, via an API or northbound interface, to a centralized controller. 5) <!--[rfced] How may we clarify/expand the first mention of "PCE-CC"? Perhaps "PCE-based central controller (PCE-CC)"? Original: Network node configurations for DetNet flows are performed by the controller using a protocol such as NETCONF [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], or PCE-CC [RFC8283]. Perhaps: Network node configurations for DetNet flows are performed by the controller using a protocol such as NETCONF [RFC6241], YANG [RFC6020] [RFC7950], DetNet YANG [RFC9633], or a PCE-based central controller (PCE-CC) [RFC8283]. --> Good suggestion. Please, change as per your proposal. Thanks. 6) <!--[rfced] FYI: Per RFC 9016, we updated "Maximum Packets Per Interval" and "Maximum Payload Size" to "MaxPacketsPerInterval" and "MaxPayloadSize", respectively. Please let us know if this is incorrect. Original: A DetNet flow is characterized with a traffic specification as defined in [RFC9016], including attributes such as Interval, Maximum Packets Per Interval, and Maximum Payload Size. Current: A DetNet flow is characterized with a traffic specification as defined in [RFC9016], including attributes such as Interval, MaxPacketsPerInterval, and MaxPayloadSize. --> Good suggestion. Please, change as per your proposal. Thanks. 7) <!-- [rfced] Are the parentheses around "member" essential to the sentence, or may we remove them? Current: Mapping of DetNet (member) flows to explicit path segments has to be ensured as well. Perhaps: Mapping of DetNet member flows to explicit path segments has to be ensured as well. --> DetNet member flow is specific term used in DetNet. NEW: Mapping of DetNet flows or DetNet member flows to explicit path segments has to be ensured as well. 8) <!--[rfced] Please clarify if "BGP/MPLS-based" means "BGP and MPLS-based" (option A) or "BGP-based and MPLS-based" (option B) in the following. Current: The dynamic signaling protocols most commonly used for label distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP/MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs [RFC7432]). Perhaps A: The dynamic signaling protocols most commonly used for label distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP and MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs [RFC7432]). or Perhaps B: The dynamic signaling protocols most commonly used for label distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP-/MPLS-based Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs [RFC7432]). --> The term intends to refer to VPNs established in MPLS networks using BGP protocol. NEW: The dynamic signaling protocols most commonly used for label distribution are LDP [RFC5036], RSVP-TE [RFC4875], and BGP [RFC8277] (which enables BGP-based MPLS Layer 3 VPNs [RFC4384], Layer 2 VPNs [RFC4664], and EVPNs [RFC7432]). 9) <!-- [rfced] Section 4.4.2: This section states that it will "discuss possible protocol extensions to existing IP routing protocols"; however, it does not appear to do that. Please review and let us know if content should be added to this section or if it should be rephrased for clarity. Current: For the purposes of this document, "traditional IP" is defined as IP without the use of segment routing (see Section 4.4.3 for a discussion of IP with segment routing). This section will discuss possible protocol extensions to existing IP routing protocols. It should be noted that a DetNet IP data plane [RFC8939] is simpler than a DetNet MPLS data plane [RFC8964] and doesn't support PREOF, so only one path per flow or flow aggregate is required. --> Thanks for pointing out this issue. I have changed the sentence and moved to the end of the paragraph. NEW: For the purposes of this document, "traditional IP" is defined as IP without the use of segment routing (see Section 4.4.3 for a discussion of IP with segment routing). It should be noted that a DetNet IP data plane [RFC8939] is simpler than a DetNet MPLS data plane [RFC8964] and doesn't support PREOF, so only one path per flow or flow aggregate is required. Therefore, possible protocol extensions are expected to be limited e.g., to existing IP routing protocols. 10) <!-- [rfced] We're having trouble parsing how "one ... controller plane function" can "collaborate". How may we update for clarity? Note that we updated the capitalization of the expansions for CPF and FME to match RFC 8655. Current: When there are multiple domains involved, one or multiple Controller Plane Functions (CPFs) would have to collaborate to implement the requests received from the Flow Management Entity (FME) [RFC8655] as per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow. Perhaps A: When there are multiple domains involved, multiple Controller Plane Functions (CPFs) would have to collaborate to implement the requests received from the Flow Management Entity (FME) [RFC8655] as per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow. or Perhaps B: When there are multiple domains involved, one Controller Plane Function (CPF) (or multiple CPFs in collaboration) would have to implement the requests received from the Flow Management Entity (FME) [RFC8655] as per-flow, per-hop behaviors installed in the DetNet nodes for each individual flow. --> Please, go with Version-A. Thanks. 11) <!--[rfced] We rephrased the following text to expand "RAW" and to avoid hyphenating "RAW-specific functions". Please let us know if this retains the intended meaning. Original: Furthermore, in the case of wireless domains, the per-domain RAW [I-D.ietf-raw-architecture] specific functions like the PLR (Point of Local Repairs have to be also considered, e.g., in addition to the PCEs. Current: Furthermore, in the case of wireless domains, per-domain functions specific to Reliable and Available Wireless (RAW) [RAW-ARCH], such as Point of Local Repairs (PLRs), have to also be considered, e.g., in addition to the PCEs. --> Good suggestion. Please, go with your proposed change. Thanks. 12) <!-- [rfced] Terminology a) Throughout the text, the following terminology appears to be used inconsistently. Please review these occurrences and let us know if/how they may be made consistent. Segment Routing vs. segment routing (not including "Segment Routing over MPLS" or "Segment Routing over IPv6") b) Note that we updated the text to reflect the forms on the right for consistency. Please let us know if any further changes are needed. Controller Plane -> controller plane (per RFCs 9016 and 9055) Data Plane -> data plane (per RFCs 9016, 9055, and 9551) DetNet Architecture -> DetNet architecture (per RFCs 8939 and 9016) DetNet control plane -> DetNet Control Plane (per RFC 9551) DetNet controller plane -> DetNet Controller Plane (per RFCs 9055 and 9551) DetNet Data Plane Framework -> DetNet data plane framework (per RFC 8938) --> I would prefer: a) Segment Routing b) I am happy with your suggestions. Many thanks. 13) <!-- [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. In addition, please consider whether "tradition" should be updated for clarity. While the NIST website <https://web.archive.org/web/20250214092458/ https://www.nist.gov/nist-research-library/nist-technical-series-publications- author-instructions#table1> indicates that this term is potentially biased, it is also ambiguous. "Tradition" is a subjective term, as it is not the same for everyone. A): Note that in the DetNet overall architecture, the controller plane includes what are more traditionally considered separate control and management planes (see Section 4.4.2 of [RFC8655]). --> I propose to change to "usually" here. NEW: Note that in the DetNet overall architecture, the controller plane includes what are usually considered as separate control and management planes (see Section 4.4.2 of [RFC8655]). B): Traditionally, the management plane is primarily involved with fault management, configuration management, and performance management (sometimes accounting management and security management are also considered in the management plane (Section 4.2 of [RFC6632]) but they are not in the scope of this document). --> I propose to remove here. NEW: The management plane is primarily involved with fault management, configuration management, and performance management (sometimes accounting management and security management are also considered in the management plane (Section 4.2 of [RFC6632]) but they are not in the scope of this document). C): For the purposes of this document, "traditional MPLS" is defined as MPLS without the use of segment routing (see Section 4.4.3 for a discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. --> I propose to change to "legacy" here. NEW: For the purposes of this document, "legacy MPLS" is defined as MPLS without the use of segment routing (see Section 4.4.3 for a discussion of MPLS with segment routing) or MPLS-TP [RFC5960]. D): In traditional MPLS domains, a dynamic control plane using distributed signaling protocols is typically used for the distribution of MPLS labels used for forwarding MPLS packets. --> I propose to change to "legacy" here. NEW: In legacy MPLS domains, a dynamic control plane using distributed signaling protocols is typically used for the distribution of MPLS labels used for forwarding MPLS packets. E): For the purposes of this document, "traditional IP" is defined as IP without the use of segment routing (see Section 4.4.3 for a discussion of IP with segment routing). --> I propose to change to "legacy" here. NEW: For the purposes of this document, "legacy IP" is defined as IP without the use of segment routing (see Section 4.4.3 for a discussion of IP with segment routing). F): Segment Routing reduces the amount of network signaling associated with distributed signaling protocols, such as RSVP-TE, and also reduces the amount of state in core nodes compared with that required for traditional MPLS and IP routing, as the state is now in the packets rather than in the routers. --> I propose to change to "legacy" here. NEW: Segment Routing reduces the amount of network signaling associated with distributed signaling protocols, such as RSVP-TE, and also reduces the amount of state in core nodes compared with that required for legacy MPLS and IP routing, as the state is now in the packets rather than in the routers. Thank you. Sarah Tarrant and Karen Moore RFC Production Center On Feb 20, 2026, at 5:52 PM, [email protected] wrote: *****IMPORTANT***** Updated 2026/02/20 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * [email protected] (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * [email protected], which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, [email protected] will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9938.xml https://www.rfc-editor.org/authors/rfc9938.html https://www.rfc-editor.org/authors/rfc9938.pdf https://www.rfc-editor.org/authors/rfc9938.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9938-diff.html https://www.rfc-editor.org/authors/rfc9938-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9938-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9938 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9938 (draft-ietf-detnet-controller-plane-framework-15) Title : A Framework for Deterministic Networking (DetNet) Controller Plane Author(s) : A. Malis, X. Geng, M. Chen, B. Varga, C. Bernardos WG Chair(s) : Lou Berger, János Farkas Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
