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%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]
