Hi, The latest version looks good to me, I approve the publication of the document.
Best regards, Mach > -----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%7C546a37c95ff646317e9908de789 > cfcc > >> 1 > >> %7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6390808131310 > 85435%7CUn > >> k > >> > nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > MCIsIlAiOi > >> J > >> > XaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=u > H7Nz4YA > >> 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%7C92e84cebfbfd47 > abbe > >> 5 > >> > 2080c6b87953f%7C0%7C0%7C639080813131106655%7CUnknown%7CTWF > pbGZsb3d8ey > >> J > >> > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > >> b > >> > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=m95ivYIxB0daCiEpUBDKVtS > KNkky8H > >> 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%7C546a37c95ff646317 > e990 > >> 8 > >> > de789cfcc1%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080 > 8131311 > >> 2 > >> > 9401%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiI > wLjAuMDAw > >> M > >> > CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C > &sdat > >> a > >> > =K%2FuCdkIU791JchALYHL9MJvawWbmAdU91U6h8M%2BYq8w%3D&reserv > ed=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-4Q9l2USxIA > e6 > >> P > >> > 8O4Zc&data=05%7C02%7Cbalazs.a.varga%40ericsson.com%7C546a37c95ff6 > 4631 > >> 7 > >> > e9908de789cfcc1%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C6 > 3908081 > >> 3 > >> > 131214582%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI > lYiOiIwLjA > >> u > >> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > %7C%7C > >> & > >> > sdata=8crJySLE7FBdPImWVx6F3n%2BDl6C%2F%2FPNjDub0Ze2bP2A%3D&re > served=0 > >> > >> * The archive itself: > >> > >> https://mail/ > >> > archive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F&data=05%7C02% > 7Cba > >> l > >> > azs.a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92 > e84 > >> c > >> > ebfbfd47abbe52080c6b87953f%7C0%7C0%7C639080813131235559%7CUnk > nown%7CT > >> W > >> > FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa > W4zMiI > >> s > >> > IkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=G8AtWujXD6 > GPcIN8z > >> 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%7C92e84cebfbfd47 > abbe > >> 5 > >> > 2080c6b87953f%7C0%7C0%7C639080813131255930%7CUnknown%7CTWF > pbGZsb3d8ey > >> J > >> > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > >> b > >> > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=P6YIbLMdSmFI27nF89x4hn > Z%2FL6UG > >> 1 > >> ITnnbNRPiKcJ6c%3D&reserved=0 > >> > >> https://www/. > >> > rfc-editor.org%2Fauthors%2Frfc9938.html&data=05%7C02%7Cbalazs.a.varg > a > >> % > >> > 40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd4 > 7abb > >> e > >> > 52080c6b87953f%7C0%7C0%7C639080813131276339%7CUnknown%7CTWF > pbGZsb3d8e > >> y > >> > JFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWF > >> p > >> > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=MNSvNQmgl0zseUpO%2BI > Ps9DiCwUG > >> H > >> LpN4xmxCDsN7x%2F0%3D&reserved=0 > >> > >> https://www/. > >> > rfc-editor.org%2Fauthors%2Frfc9938.pdf&data=05%7C02%7Cbalazs.a.varga > % > >> 4 > >> > 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47 > abbe > >> 5 > >> > 2080c6b87953f%7C0%7C0%7C639080813131298316%7CUnknown%7CTWF > pbGZsb3d8ey > >> J > >> > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > >> b > >> > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q4VlXDFBpsMTzyt5sX%2BC > aUOsVCpa > >> X > >> NcvMENcvb79uV0%3D&reserved=0 > >> > >> https://www/. > >> > rfc-editor.org%2Fauthors%2Frfc9938.txt&data=05%7C02%7Cbalazs.a.varga > % > >> 4 > >> > 0ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47 > abbe > >> 5 > >> > 2080c6b87953f%7C0%7C0%7C639080813131318690%7CUnknown%7CTWF > pbGZsb3d8ey > >> J > >> > FbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > TWFp > >> b > >> > CIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v3HUOtaikeFS4F3WHXv4Qc > EYZN02wK > >> 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%7C92e84ce > bfbfd > >> 4 > >> > 7abbe52080c6b87953f%7C0%7C0%7C639080813131341466%7CUnknown% > 7CTWFpbGZs > >> b > >> > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > kFOIj > >> o > >> > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jZfy3PITZfSC8pgOpH > wBMxdJ > >> 9 > >> ApzN0xuiMVn0FrlqfQ%3D&reserved=0 > >> > >> https://www/. > >> > rfc-editor.org%2Fauthors%2Frfc9938-rfcdiff.html&data=05%7C02%7Cbalazs. > >> > a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84 > cebf > >> b > >> > fd47abbe52080c6b87953f%7C0%7C0%7C639080813131362234%7CUnknow > n%7CTWFpb > >> G > >> > Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkF > >> O > >> > IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NZlTyGUdAPd6Lc > yG3aAuK > >> j > >> fOSfkBJbVIKJskSe0dLQ0%3D&reserved=0 (side by side) > >> > >> Diff of the XML: > >> > >> https://www/. > >> > rfc-editor.org%2Fauthors%2Frfc9938-xmldiff1.html&data=05%7C02%7Cbala > z > >> s > >> .a.varga%40ericsson.com%7C546a37c95ff646317e9908de789cfcc1%7C92 > e84ceb > >> f > >> > bfd47abbe52080c6b87953f%7C0%7C0%7C639080813131382292%7CUnkno > wn%7CTWFp > >> b > >> > GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z > MiIsIk > >> F > >> > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FGvTjbllCZGI5T > hq4XcR > >> 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%40e > ri > >> c > >> > sson.com%7C546a37c95ff646317e9908de789cfcc1%7C92e84cebfbfd47abbe > 52080 > >> c > >> > 6b87953f%7C0%7C0%7C639080813131403417%7CUnknown%7CTWFpbGZs > b3d8eyJFbXB > >> 0 > >> > eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > bCIsI > >> 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]
