Thanks again to Sarah and Balázs, and I also approve publication. Cheers, Andy
On Wed, Mar 4, 2026 at 4:29 AM CARLOS JESUS BERNARDOS CANO <[email protected]> wrote: > Thank you very much Sarah and Balázs for taking care of this. I've looked > at the proposed changes and the latest version and I'm happy with it. I > approve the publication of the document. > > Thanks! > > Carlos > > On Tue, Mar 3, 2026 at 3:50 PM Sarah Tarrant < > [email protected]> wrote: > >> Hi Balázs, >> >> Thank you for clarifying! We have updated the document accordingly and >> marked your approval on the AUTH48 status page for this document (see >> https://www.rfc-editor.org/auth48/rfc9938). >> >> Please review the document carefully to ensure satisfaction as we do not >> make changes once it has been published as an RFC. >> >> As we have no further questions, we will await approvals from each of the >> parties listed at the AUTH48 status page prior to moving this document >> forward in the publication process. >> >> The updated files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9938.txt >> https://www.rfc-editor.org/authors/rfc9938.pdf >> https://www.rfc-editor.org/authors/rfc9938.html >> https://www.rfc-editor.org/authors/rfc9938.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9938-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9938-auth48diff.html (AUTH48 >> changes only) >> >> Note that it may be necessary for you to refresh your browser to view the >> most recent version. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9938 >> >> Thank you, >> Sarah Tarrant >> RFC Production Center >> >> > On Mar 3, 2026, at 1:46 AM, Balázs Varga A <[email protected]> >> wrote: >> > >> > Hi Sarah, >> > >> > Thanks for the update. >> > >> > Regarding the follow-up question: Sorry my mistake. I have misread >> > and looked for reference in RFC9055. Correct change is as per your >> > original proposal. >> > >> > 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. >> > 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 2.3 of this document. >> > >> > With this change I approve this RFC for publication. >> > >> > Thanks & Cheers >> > Bala'zs >> > >> > -----Original Message----- >> > From: Sarah Tarrant <[email protected]> >> > Sent: Monday, March 2, 2026 9:48 PM >> > To: Balázs Varga A <[email protected]> >> > Cc: [email protected]; [email protected]; >> [email protected]; [email protected]; [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 >> > >> > [Ritkán kap e-maileket [email protected]. Miért fontos ez >> a https://aka.ms/LearnAboutSenderIdentification ] >> > >> > Hi Balázs, >> > >> > Thank you for your reply. We have updated the document accordingly. >> > >> > We have one followup question, regarding: >> >>> 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. >> > >> > Could you take another look at which section this is referring to? We >> don't believe there is a Section 5.2.2 in this document. Perhaps also >> provide the section title? >> > >> > The updated files have been posted here (please refresh): >> > https://www.rfc-editor.org/authors/rfc9938.txt >> > https://www.rfc-editor.org/authors/rfc9938.pdf >> > https://www.rfc-editor.org/authors/rfc9938.html >> > https://www.rfc-editor.org/authors/rfc9938.xml >> > >> > The relevant diff files have been posted here (please refresh): >> > https://www.rfc-editor.org/authors/rfc9938-diff.html (comprehensive >> diff) >> > https://www.rfc-editor.org/authors/rfc9938-auth48diff.html (AUTH48 >> changes only) >> > >> > Note that it may be necessary for you to refresh your browser to view >> the most recent version. >> > >> > For the AUTH48 status of this document, please see: >> > https://www.rfc-editor.org/auth48/rfc9938 >> > >> > Thank you, >> > Sarah Tarrant >> > RFC Production Center >> > >> > >> >> On Mar 2, 2026, at 9:21 AM, Balázs Varga A <balazs.a.varga= >> [email protected]> wrote: >> >> >> >> Dear Sarah and Karen, >> >> With the changes below: I approve this RFC for publication. >> >> Many thanks >> >> Bala'zs >> >> >> >> -----Original Message----- >> >> From: Balázs Varga A >> >> Sent: Monday, March 2, 2026 4:17 PM >> >> To: '[email protected]' <[email protected]>; >> >> [email protected]; [email protected]; [email protected]; >> >> [email protected] >> >> Cc: [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 >> >> >> >> 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%2Fstyleguide%2Fpart2%2F%23inclusive_language&data=05%7 >> >> C02%7Cbalazs.a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1 >> >> %7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080813131085435%7CUnk >> >> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJ >> >> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uH7Nz4YAY >> >> ONROT9EZPUhJd%2BY89JqWx2gK%2Fj%2FHYaLulY%3D&reserved=0> >> >> 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%2Fweb%2F20250214092458%2F&data=05%7C02%7Cbalazs.a.varga%4 >> >> 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe5 >> >> 2080c6b87953f%7C0%7C0%7C639080813131106655%7CUnknown%7CTWFpbGZsb3d8eyJ >> >> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> >> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m95ivYIxB0daCiEpUBDKVtSKNkky8HX >> >> t80pJ%2B4%2FAIR4%3D&reserved=0 >> >> https://www/. >> >> nist.gov%2Fnist-research-library%2Fnist-technical-series-publications- >> >> &data=05%7C02%7Cbalazs.a.varga%40ericsson.com%7C546a37c95ff646317e9908 >> >> de789cfcc1%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63908081313112 >> >> 9401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM >> >> CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata >> >> =K%2FuCdkIU791JchALYHL9MJvawWbmAdU91U6h8M%2BYq8w%3D&reserved=0 >> >> 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://mail/ >> >> archive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2USxIAe6P >> >> 8O4Zc&data=05%7C02%7Cbalazs.a.varga%40ericsson.com%7C546a37c95ff646317 >> >> e9908de789cfcc1%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080813 >> >> 131214582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu >> >> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C& >> >> sdata=8crJySLE7FBdPImWVx6F3n%2BDl6C%2F%2FPNjDub0Ze2bP2A%3D&reserved=0 >> >> >> >> * The archive itself: >> >> >> >> https://mail/ >> >> archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02%7Cbal >> >> azs.a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84c >> >> ebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080813131235559%7CUnknown%7CTW >> >> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIs >> >> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G8AtWujXD6GPcIN8zz >> >> ninasVLhTBb62sMWRetbwpAVA%3D&reserved=0 >> >> >> >> * 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%2Fauthors%2Frfc9938.xml&data=05%7C02%7Cbalazs.a.varga%4 >> >> 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe5 >> >> 2080c6b87953f%7C0%7C0%7C639080813131255930%7CUnknown%7CTWFpbGZsb3d8eyJ >> >> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> >> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P6YIbLMdSmFI27nF89x4hnZ%2FL6UG1 >> >> ITnnbNRPiKcJ6c%3D&reserved=0 >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauthors%2Frfc9938.html&data=05%7C02%7Cbalazs.a.varga% >> >> 40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe >> >> 52080c6b87953f%7C0%7C0%7C639080813131276339%7CUnknown%7CTWFpbGZsb3d8ey >> >> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >> >> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MNSvNQmgl0zseUpO%2BIPs9DiCwUGH >> >> LpN4xmxCDsN7x%2F0%3D&reserved=0 >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauthors%2Frfc9938.pdf&data=05%7C02%7Cbalazs.a.varga%4 >> >> 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe5 >> >> 2080c6b87953f%7C0%7C0%7C639080813131298316%7CUnknown%7CTWFpbGZsb3d8eyJ >> >> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> >> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q4VlXDFBpsMTzyt5sX%2BCaUOsVCpaX >> >> NcvMENcvb79uV0%3D&reserved=0 >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauthors%2Frfc9938.txt&data=05%7C02%7Cbalazs.a.varga%4 >> >> 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe5 >> >> 2080c6b87953f%7C0%7C0%7C639080813131318690%7CUnknown%7CTWFpbGZsb3d8eyJ >> >> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb >> >> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v3HUOtaikeFS4F3WHXv4QcEYZN02wKG >> >> kECw1qcih43g%3D&reserved=0 >> >> >> >> Diff file of the text: >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauthors%2Frfc9938-diff.html&data=05%7C02%7Cbalazs.a.v >> >> arga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd4 >> >> 7abbe52080c6b87953f%7C0%7C0%7C639080813131341466%7CUnknown%7CTWFpbGZsb >> >> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo >> >> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jZfy3PITZfSC8pgOpHwBMxdJ9 >> >> ApzN0xuiMVn0FrlqfQ%3D&reserved=0 >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauthors%2Frfc9938-rfcdiff.html&data=05%7C02%7Cbalazs. >> >> a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfb >> >> fd47abbe52080c6b87953f%7C0%7C0%7C639080813131362234%7CUnknown%7CTWFpbG >> >> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO >> >> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NZlTyGUdAPd6LcyG3aAuKj >> >> fOSfkBJbVIKJskSe0dLQ0%3D&reserved=0 (side by side) >> >> >> >> Diff of the XML: >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauthors%2Frfc9938-xmldiff1.html&data=05%7C02%7Cbalazs >> >> .a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebf >> >> bfd47abbe52080c6b87953f%7C0%7C0%7C639080813131382292%7CUnknown%7CTWFpb >> >> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >> >> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FGvTjbllCZGI5Thq4XcRw >> >> DDaV7W2%2BJWrPEouaYiHWHI%3D&reserved=0 >> >> >> >> >> >> Tracking progress >> >> ----------------- >> >> >> >> The details of the AUTH48 status of your document are here: >> >> >> >> https://www/. >> >> rfc-editor.org%2Fauth48%2Frfc9938&data=05%7C02%7Cbalazs.a.varga%40eric >> >> sson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe52080c >> >> 6b87953f%7C0%7C0%7C639080813131403417%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0 >> >> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIl >> >> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OiGR2%2BREhDiVJ7oc6zwaof%2F4lFVdb14F >> >> cfWaDXrDMNQ%3D&reserved=0 >> >> >> >> 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]
