All, We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9938
Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. Sincerely, Sarah Tarrant RFC Production Center > On Mar 5, 2026, at 8:39 AM, Sarah Tarrant <[email protected]> > wrote: > > Hi Xuesong, > > Thank you for double-checking, as we indeed did not get your approval email. > We have now marked your approval on the AUTH48 status page for this document > (see https://www.rfc-editor.org/auth48/rfc9938). > > Sincerely, > Sarah Tarrant > RFC Production Center > >> On Mar 5, 2026, at 4:10 AM, Xuesong Geng <[email protected]> wrote: >> >> Hi Sarah, >> >> Outlook notified me that my previous email may not have been delivered >> successfully. In case you did not receive it, I am resending it here for >> your reference. >> >> Please let me know if you still have any issues receiving it. >> >> Best regards, >> Xuesong >> >> -----Original Message----- >> From: Xuesong Geng >> Sent: Thursday, March 5, 2026 6:07 PM >> To: 'Sarah Tarrant' <[email protected]>; Balázs Varga A >> <[email protected]> >> Cc: [email protected]; [email protected]; Mach Chen >> <[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 >> >> Hi Balaz and Sarah, >> >> Thanks a lot for helping with the progress of the document! >> I confirm that I have reviewed the document and approve it for publication. >> Let me know if anything further is needed from my side. >> >> Best >> Xuesong >> >> -----Original Message----- >> From: Sarah Tarrant <[email protected]> >> Sent: Tuesday, March 3, 2026 10:51 PM >> To: Balázs Varga A <[email protected]> >> Cc: [email protected]; [email protected]; Xuesong Geng >> <[email protected]>; Mach Chen <[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 >> >> 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 >>>> <[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%7C546a37c95ff646317e9908de789cfcc >>>> 1 >>>> %7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080813131085435%7CUn >>>> k >>>> nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOi >>>> J >>>> XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uH7Nz4YA >>>> Y 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%7C92e84cebfbfd47abbe >>>> 5 >>>> 2080c6b87953f%7C0%7C0%7C639080813131106655%7CUnknown%7CTWFpbGZsb3d8ey >>>> J >>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>> b >>>> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m95ivYIxB0daCiEpUBDKVtSKNkky8H >>>> X >>>> 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%7C546a37c95ff646317e990 >>>> 8 >>>> de789cfcc1%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6390808131311 >>>> 2 >>>> 9401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw >>>> M >>>> CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat >>>> a >>>> =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-4Q9l2USxIAe6 >>>> P >>>> 8O4Zc&data=05%7C02%7Cbalazs.a.varga%40ericsson.com%7C546a37c95ff64631 >>>> 7 >>>> e9908de789cfcc1%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C63908081 >>>> 3 >>>> 131214582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjA >>>> u >>>> 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%7Cba >>>> l >>>> azs.a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84 >>>> c >>>> ebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080813131235559%7CUnknown%7CT >>>> W >>>> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiI >>>> s >>>> IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G8AtWujXD6GPcIN8z >>>> z >>>> 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%7C92e84cebfbfd47abbe >>>> 5 >>>> 2080c6b87953f%7C0%7C0%7C639080813131255930%7CUnknown%7CTWFpbGZsb3d8ey >>>> J >>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>> b >>>> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P6YIbLMdSmFI27nF89x4hnZ%2FL6UG >>>> 1 >>>> ITnnbNRPiKcJ6c%3D&reserved=0 >>>> >>>> https://www/. >>>> rfc-editor.org%2Fauthors%2Frfc9938.html&data=05%7C02%7Cbalazs.a.varga >>>> % >>>> 40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abb >>>> e >>>> 52080c6b87953f%7C0%7C0%7C639080813131276339%7CUnknown%7CTWFpbGZsb3d8e >>>> y >>>> JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF >>>> p >>>> bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MNSvNQmgl0zseUpO%2BIPs9DiCwUG >>>> H >>>> LpN4xmxCDsN7x%2F0%3D&reserved=0 >>>> >>>> https://www/. >>>> rfc-editor.org%2Fauthors%2Frfc9938.pdf&data=05%7C02%7Cbalazs.a.varga% >>>> 4 >>>> 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe >>>> 5 >>>> 2080c6b87953f%7C0%7C0%7C639080813131298316%7CUnknown%7CTWFpbGZsb3d8ey >>>> J >>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>> b >>>> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q4VlXDFBpsMTzyt5sX%2BCaUOsVCpa >>>> X >>>> NcvMENcvb79uV0%3D&reserved=0 >>>> >>>> https://www/. >>>> rfc-editor.org%2Fauthors%2Frfc9938.txt&data=05%7C02%7Cbalazs.a.varga% >>>> 4 >>>> 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe >>>> 5 >>>> 2080c6b87953f%7C0%7C0%7C639080813131318690%7CUnknown%7CTWFpbGZsb3d8ey >>>> J >>>> FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>> b >>>> CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v3HUOtaikeFS4F3WHXv4QcEYZN02wK >>>> G >>>> 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%7C92e84cebfbfd >>>> 4 >>>> 7abbe52080c6b87953f%7C0%7C0%7C639080813131341466%7CUnknown%7CTWFpbGZs >>>> b >>>> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIj >>>> o >>>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jZfy3PITZfSC8pgOpHwBMxdJ >>>> 9 >>>> ApzN0xuiMVn0FrlqfQ%3D&reserved=0 >>>> >>>> https://www/. >>>> rfc-editor.org%2Fauthors%2Frfc9938-rfcdiff.html&data=05%7C02%7Cbalazs. >>>> a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebf >>>> b >>>> fd47abbe52080c6b87953f%7C0%7C0%7C639080813131362234%7CUnknown%7CTWFpb >>>> G >>>> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF >>>> O >>>> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NZlTyGUdAPd6LcyG3aAuK >>>> j >>>> fOSfkBJbVIKJskSe0dLQ0%3D&reserved=0 (side by side) >>>> >>>> Diff of the XML: >>>> >>>> https://www/. >>>> rfc-editor.org%2Fauthors%2Frfc9938-xmldiff1.html&data=05%7C02%7Cbalaz >>>> s >>>> .a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84ceb >>>> f >>>> bfd47abbe52080c6b87953f%7C0%7C0%7C639080813131382292%7CUnknown%7CTWFp >>>> b >>>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIk >>>> F >>>> OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FGvTjbllCZGI5Thq4XcR >>>> w >>>> 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%40eri >>>> c >>>> sson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe52080 >>>> c >>>> 6b87953f%7C0%7C0%7C639080813131403417%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >>>> 0 >>>> eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI >>>> l >>>> dUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OiGR2%2BREhDiVJ7oc6zwaof%2F4lFVdb14 >>>> F >>>> 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]
