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]
