[Detnet] Re: WG adoption poll: joung-detnet-stateless-fair-queuing-05

[Jinoo Joung <[e-mail]>]

Hello Mike, for your careful consideration and comments.

We will try our best to align this work with ITU-T standards.
Please see our answers in-line marked JJ.

Best regards,
Jinoo (on behalf of authors)

On Tue, Mar 3, 2026 at 9:00 PM Mike Blanche <[e-mail]> wrote:

>
> Hi Jinoo, authors, and the WG,
>
> Thank you Jinoo and the authors for updating this draft.
>
> I think the "meat" of what is new in the proposal is in 6.3.2.1 (IPv6
> header format) and 6.3.2.2 (MPLS label format), and possibly 6.3.3, the
> admission procedure.
>
 JJ: Right, and Section 7 (Approximate C-SCORE) too.

>
> Most of the other content appears to summarize or restate what is in ITU-T
> Y.3129 and Y.3148, albeit with discrepancies.
>
> For example Section 4 appears to be a condensed version of section 6 of
> ITU-T Y.3129, although it still appears to include specifications already
> defined in Y.3129, e.g.
> section 4 of this I-D: "Instead of deriving a new FT at each core node, we
> will specify a method of deriving the FT at downstream nodes by using the
> initial FT calculated at the entrance node."
> section 6 of Y.3129: "This Recommendation presents requirements and a
> framework for generation and update of FT..."
>

JJ: To provide necessary context for the reader, this draft retains the
core principles of Y.3129.

>
> Section 6.1 has five requirements but Y.3129 has nine.
>

JJ: Right. But the context of the requirements remains identical. For
example, the first two requirements in Y.3129 states:

R1: The entrance node of a flow is required to manage the flow state.
R2: The entrance node is required to determine initial FTs for packets
according to the flow state.

These requirements are summarized as Requirement 1 below in the draft.

Requirement 1: In the entrance node, it is REQUIRED to obtain the FTs with
the following
equation. 0 denotes the entrance node of the flow under observation.
F0(p) = max{F0(p-1), A0(p)}+L(p)/r.

Overall, the texts in Y.3129 are high-level, while those in the draft are
specific.
If you think the texts for the requirements should be identical, I will
gladly change them.


> The equations in section 6.2 include clock discrepancy adjustment which
> appears absent from the equivalent equations in section 8.2 of Y.3129.
>

JJ: We will add the equation in the future version.
However, this version has been refined for brevity, retaining only the
critical elements necessary.


>
> The metadata proposal appears to conflict with the ITU Recommendations.
> The I-D suggests two pieces of metadata to be carried, Fh(p) and L/r.
> However Y.3129 and Y.3148 refers to three pieces of metadata, Fh(p), L and
> r.
>

JJ: What is required to fulfill the requirements and framework is the
metadata L/r. Making two (L and r) to one (L/r) can be seen as an
improvement.
However, if necessary we will specify both cases in the draft.


> Section 6.3.4 is almost word-for-word identical to Y.3129 section 8.4,
> with the difference being the I-D suggests writing two pieces of metadata
> whereas Y.3129 suggests three.
>
> Section 6.3.5 similarly to Y.3129 section 8.5.
>
> Section 6.3.6 similarly to Y.3129 section 8.6.
>

JJ: Right. These are the critical elements and the summarized texts.

>
> If I have misunderstood any of the above please let me know, it's entirely
> possible.
>
> We must ensure the work aligns with existing standards. If we refer to
> those standards we should not seek to recreate them in our drafts for risk
> of introducing confusion.
>
> The abstract and introduction should also be updated to reflect what is
> "new" in this proposal.
>

JJ: OK. We will update them as suggested.


>
> Thank you all for your continued efforts here.
>
> Mike
>
>
>
>
> On Fri, 27 Feb 2026 at 14:28, Janos Farkas <Janos.Farkas=
> [e-mail]> wrote:
>
>> Hi Jinoo, Authors,
>>
>>
>>
>> Thank you for the updates!
>>
>>
>>
>> Prior to publication as a WG document, we ask that you add a section that
>> describes the relationship of this work to the ITU-T work.
>>
>>
>>
>> Thank you,
>>
>> Lou and Janos
>>
>>
>>
>>
>>
>> *From:* Jinoo Joung <[e-mail]>
>> *Sent:* Friday, February 20, 2026 12:11 PM
>> *To:* Janos Farkas <[e-mail]>
>> *Cc:* Scott Mansfield <scott.mansfield=[e-mail]>;
>> [e-mail]
>> *Subject:* Re: [Detnet] Re: WG adoption poll:
>> joung-detnet-stateless-fair-queuing-05
>>
>>
>>
>> Hello Chairs, Scott, and WG,
>>
>>
>>
>> Please note that draft-joung-detnet-stateless-fair-queuing is revised and
>> uploaded as 07.
>>
>> In line with Scott's suggestions, the new version includes:
>>
>> 1) Abbreviations
>>
>> 2) New references including RFC8200, MPLS-related IETF drafts, and two
>> ITU-T Recommendations.
>>
>> 3) Minimized 6.1. Framework and other content that are duplicative with
>> ITU-T Recommendations. Only those that are essential to understand the
>> whole picture are left.
>>
>> 4) Elaborated 6.3.1 Metadata; 6.3.2. Header format; 6.3.3. Admission
>> control; 7. Approximate C-SCORE
>>
>>
>>
>> In 6.3.1 and 6.3.2, the methods for carrying metadata with IPv6 and MPLS
>> MNA Sub-stack are described in detail.
>>
>> 6.3.3 delineates two distinct admission control methodologies, providing
>> for the selection of either procedure based on specific implementation
>> requirements.
>>
>> Section 7. Approximate C-SCORE specifies the nodal architecture and
>> algorithms to approximate C-SCORE with rotating strict priority schedulers.
>>
>> The E2E latency bound, in a complete math expression, is also given.
>>
>> This approximation serves to alleviate the sorting bottleneck intrinsic
>> to C-SCORE,
>>
>> bypassing the intensive priority queue operations while maintaining
>> near-optimal alignment with theoretical Finish Time objectives.
>>
>>
>>
>> Best regards,
>>
>> Jinoo (on behalf of authors)
>>
>>
>>
>> ====================================
>>
>>
>>
>> Internet-Draft draft-joung-detnet-stateless-fair-queuing-07.txt is now
>> available. It is a work item of the Deterministic Networking (DETNET) WG
>> of
>> the IETF.
>>
>>    Title:   Latency Guarantee with Stateless Fair Queuing
>>    Authors: Jinoo Joung
>>             Jeong-dong Ryoo
>>             Taesik Cheung
>>             Yizhou Li
>>             Peng Liu
>>    Name:    draft-joung-detnet-stateless-fair-queuing-07.txt
>>    Pages:   23
>>    Dates:   2026-02-20
>>
>> Abstract:
>>
>>    This document specifies the framework and the operational procedure
>>    for deterministic networking with a set of rate based work conserving
>>    packet schedulers.  The framework guarantees end-to-end (E2E) latency
>>    bounds to flows.  The schedulers in core nodes do not need to
>>    maintain flow states.  Instead, the entrance node of a flow marks an
>>    ideal service completion time according to a fluid model, called
>>    Finish Time (FT), of a packet in the packet header.  The subsequent
>>    core nodes update the FT by adding the delay factor, which is a
>>    function of the flow and the nodes.  The packets in the queue of the
>>    scheduler are served in the ascending order of FT.  This mechanism is
>>    called the stateless fair queuing.  The result is that flows are
>>    isolated from each other almost perfectly.  The latency bound of a
>>    flow depends only on the flow's intrinsic parameters such as the
>>    maximum burst size and the service rate, except the link capacities
>>    and the maximum packet length among other flows sharing each output
>>    link with the flow.  Furthermore, this document specifies an
>>    approximation of stateless fair queuing implemented via a strict
>>    priority (SP) scheduler.  This approach maintains a guaranteed end-
>>    to-end (E2E) latency bound.
>>
>> The IETF datatracker status page for this Internet-Draft is:
>>
>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/
>>
>> There is also an HTMLized version available at:
>>
>> https://datatracker.ietf.org/doc/html/draft-joung-detnet-stateless-fair-queuing-07
>>
>> A diff from the previous version is available at:
>>
>> https://author-tools.ietf.org/iddiff?url2=draft-joung-detnet-stateless-fair-queuing-07
>>
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>>
>>
>>
>>
>>
>> On Fri, Jan 23, 2026 at 10:52 PM Janos Farkas <[e-mail]>
>> wrote:
>>
>> Hi,
>>
>>
>>
>> Scott,
>>
>> Thank you very mush for your guidelines! Much appreciated.
>>
>>
>>
>> Jinoo,
>>
>> Great to see agreement.
>>
>> Could you please revise the draft along the guidelines provided? Once
>> updated per the discussion below, we can publish it as a WG document.
>>
>>
>>
>> Thank you,
>>
>> Lou and Janos
>>
>>
>>
>> *From:* Jinoo Joung <[e-mail]>
>> *Sent:* Tuesday, January 20, 2026 4:23 PM
>> *To:* Scott Mansfield <scott.mansfield=[e-mail]>
>> *Cc:* [e-mail]
>> *Subject:* [Detnet] Re: WG adoption poll:
>> joung-detnet-stateless-fair-queuing-05
>>
>>
>>
>> Hello Scott,
>>
>> Thanks for your valuable suggestions.
>> I deeply appreciate your efforts to resolve this issue in a fair and
>> reasonable manner.
>> I agree with your proposed action.
>>
>> I have answered your guidelines in-line marked with JJ. Please take a
>> look.
>>
>> In short, there is a clear gap between the ITU-T work and the IETF
>> document.
>> While ITU-T work focuses on the requirements and framework, the IETF
>> document will elaborate on IP/MPLS specific information for deployment,
>> including header fields and formats, protocols for admission control and
>> time-difference compensation.
>> It will also include implementation details for approximating fair
>> queuing with a strict priority scheduler.
>>
>> Many thanks and best regards,
>> Jinoo
>>
>>
>>
>> On Tue, Jan 20, 2026 at 6:11 AM Scott Mansfield <scott.mansfield=
>> [e-mail]> wrote:
>>
>> Hi,
>>
>>
>>
>> Speaking as a liaison manager between the IETF and ITU-T, it is important
>> to note a few guidelines.  Following this discussion, I observe there is
>> concern that there is work being duplicated.  In order to make all parties
>> comfortable I would suggest the following:
>>
>>
>>
>> Potential Action:
>>
>> The process of “gap analysis” is used a lot in the ITU-T to ensure new
>> work items do not duplicate work already done by the industry recognized
>> center of competence.  The reverse is true as well.  I would want to see
>> the gap that the IETF is filling here and how it augments or modifies what
>> the ITU-T has already done.  If there are modifications to the ITU-T work
>> needed, I would like to see the authors plans to progress that work in the
>> ITU-T.
>>
>>
>>
>> JJ: There is a clear gap, as I stated in the main text of this mail. The
>> IETF draft will augment the ITU-T work. There is no need to modify the
>> ITU-T work. It serves as a solid foundation for the IETF draft. In my
>> opinion, the implementation specific issues in the IETF draft are not
>> appropriate for standardization in ITU-T.
>>
>>
>>
>> Guidelines To Note:
>> - It is appropriate for the IETF to take ITU-T work and augment it as
>> long as the augmentation is in the scope and mandate of IETF.  Also, the
>> work should not fundamentally change (or be backwards incompatible).  It is
>> imperative that the IETF document be clear what ITU-T work it is using and
>> properly reference the work.
>>
>>
>>
>> JJ: I believe the IP/MPLS issues, protocols, and implementation
>> specifications are well within the scope of IETF. While the work proceeds
>> in IETF, no changes will be introduced. The ITU-T works will be referenced
>> as well.
>>
>>
>>
>> - If there is anything being added in the IETF that requires a
>> fundamental change to the ITU-T work, that work needs to be
>> liaised/coordinated with the ITU-T.  If what the IETF is doing is
>> explaining how to use the ITU-T work in the context of IETF (profiles etc.)
>> that is ok.
>>
>>
>>
>> JJ: Again, the ITU-T work won't be changed. The IETF draft will explain
>> how to use the fundamentals described in the ITU-T work.
>>
>>
>>
>> - If the IETF work is really changing the math, that should be
>> coordinated too.  If the ITU-T work missed something, or is not appropriate
>> for the IETF use-case, again, coordination is needed.  Since (at least)
>> some of the authors are the same in both groups, this is the best way to
>> gain consensus by ensuring the process of each group is followed.
>>
>>
>>
>> JJ: I definitely agree with you.
>>
>>
>>
>> I find coordination and cooperation is best handled when people work
>> together and have people that attend each organization and follow the
>> processes of the organization when progressing the documents.  Liaison can
>> be used, but they tend to be slow.  The IETF DetNet mailing list is the
>> proper place to have this discussion especially if there are participants
>> in this working group that need clarity to ensure work is not duplicated.
>>
>>
>>
>> Many thanks,
>>
>> -scott.
>>
>>
>>
>>
>>
>>
>>
>> [Detnet] Re: WG adoption poll: joung-detnet-stateless-fair-queuing-05
>>
>> Jinoo Joung <[e-mail]> Fri, 02 January 2026 22:16 UTCShow header
>> <https://mailarchive.ietf.org/arch/msg/detnet/Ea4920SPZmgxU-0npKrss00EI7Y/>
>>
>> Hello Mike, it's great to hear from you.
>>
>> Thanks for the valuable feedback.
>>
>> It seems that your major concern is the discrepancy between the standards.
>>
>>
>>
>> But I assure you that there is no conflict.
>>
>> Because ITU-T did not allow math equations in the Requirements section,
>>
>> I had to divide one equation into two or three sentences.
>>
>> That is why it seems the number of requirements are different.
>>
>> If you find any discrepancies, just let me know.
>>
>>
>>
>> Y.3148 also deals with considerations for metadata, but it still is at an
>>
>> academic level.
>>
>> These two ITU-T standards are strictly based on the paper:
>>
>> https://ieeexplore.ieee.org/document/10261190
>>
>>
>>
>> Best regards,
>>
>> Jinoo
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Jan 3, 2026 at 4:09 AM Mike Blanche <[e-mail]>
>> wrote:
>>
>>
>>
>> >
>>
>> > Hi Jinoo and all,
>>
>> >
>>
>> > Although the C-SCORE approach may be an appropriate solution within the
>>
>> > agreed taxonomy, I am still concerned about duplicating work already
>> done
>>
>> > elsewhere.
>>
>> >
>>
>> > What happens if the IETF draft diverges from the ITU Recommendation?
>>
>> > Y.3129 makes 9 "requirements", whereas the current draft has 5
>> requirements
>>
>> > and 3 conditions. There is already one discrepancy between the two
>>
>> > documents in the description of the maths. This may lead to
>> inconsistent or
>>
>> > incompatible implementations depending on which document implementers
>>
>> > follow.
>>
>> >
>>
>> > I see the new draft  (-06) focuses more on the necessary metadata. This
>> is
>>
>> > also already documented in ITU-T Y.3148, which covers metadata creation
>> and
>>
>> > updating procedures in depth. Again, how will it be ensured that this
>> draft
>>
>> > does not diverge from or conflict with the existing ITU Recommendation?
>>
>> >
>>
>> > The latest draft still does not cite either ITU Recommendation Y.3129 or
>>
>> > Y.3148.
>>
>> >
>>
>> > Thanks,
>>
>> >
>>
>> > Mike
>>
>> >
>>
>> > On Tue, 23 Dec 2025 at 00:08, Jinoo Joung <[e-mail]> wrote:
>>
>> >
>>
>> >>
>>
>> >> Hello Mike, thanks for the comment regarding the work in ITU-T.
>>
>> >> I understand your concern.
>>
>> >>
>>
>> >> Hello WG and Mike,
>>
>> >>
>>
>> >> The C-SCORE draft, as indicated in the version 6, will have the
>> following
>>
>> >> details in the future, once accepted as the WG draft.
>>
>> >> 1) MPLS and IP specific protocol details: This includes the header
>>
>> >> fields/formats, interactions between nodes and between control/data
>> planes.
>>
>> >> 2) Implementation issues regarding the priority queue, which is
>> currently
>>
>> >> required to sort the packets in FT orders: This includes an
>> approximation
>>
>> >> technique based on strict priority schedulers.
>>
>> >>
>>
>> >> Y.3129 is focused on the requirements and provides theoretical
>>
>> >> justifications but the C-SCORE draft targets on the solution.
>>
>> >> Some framework texts are covered in both. But they are necessary
>>
>> >> information for readers in order to understand the design principles
>> of the
>>
>> >> solution in the C-SCORE draft.
>>
>> >>
>>
>> >> C-SCORE is not a new invention.
>>
>> >> It is an outcome of the numerous researches conducted during late '90 ~
>>
>> >> early '00s, which was the peak period of Internet research.
>>
>> >> There are more than hundreds of papers that are related to the fair
>>
>> >> queuing, after all.
>>
>> >>
>>
>> >> I believe it is worth being standardized by such virtues:
>>
>> >> 1) flow isolation capability, which protects from other flows'
>>
>> >> join/leave, bursts, or even malicious behaviours
>>
>> >> 2) scalability due to its stateless nature
>>
>> >> 3) flexibility from network asymmetry such as link capacity variations
>>
>> >> and uneven propagation delays
>>
>> >> 4) simple admission criteria, which allows incremental flow acceptance,
>>
>> >> without modifying existing network setup
>>
>> >> 5) small average delay due to work conserving nature,
>>
>> >> just to mention a few. :-)
>>
>> >>
>>
>> >> Best regards,
>>
>> >> Jinoo (on behalf of authors)
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> On Fri, Dec 12, 2025 at 12:10 AM Mike Blanche <[e-mail]>
>>
>> >> wrote:
>>
>> >>
>>
>> >>>
>>
>> >>> Hi all,
>>
>> >>>
>>
>> >>> This proposal appears very similar to ITU-T Recommendation Y.3129,
>> which
>>
>> >>> I believe was developed by some of the same authors.
>>
>> >>>
>>
>> >>> https://www.itu.int/rec/T-REC-Y.3129-202404-I/en
>>
>> >>>
>>
>> >>> The abstract text of the I-D is virtually identical to the summary of
>>
>> >>> Y.3129. In addition, significant parts of the content are very
>> similar -
>>
>> >>> e.g. parts of section 6.3 of the draft are word-for-word the same as
>> parts
>>
>> >>> of section 8 of the ITU-T Recommendation.
>>
>> >>>
>>
>> >>> The ITU-T Recommendation is missing from the draft's References
>> section.
>>
>> >>>
>>
>> >>> I am unclear why we are considering duplicating work that appears to
>> be
>>
>> >>> already completed at the ITU.
>>
>> >>>
>>
>> >>> Best regards,
>>
>> >>>
>>
>> >>> Mike
>>
>> >>>
>>
>> >>> On Fri, 5 Dec 2025 at 15:49, Janos Farkas <Janos.Farkas=
>>
>> >>> [e-mail]> wrote:
>>
>> >>>
>>
>> >>>> Hi,
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>> This email begins a 4-week adoption poll for:
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/05/
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>> No IPR has been disclosed for this document.
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>> Please voice your support or technical objections to adoption on the
>>
>> >>>>
>>
>> >>>> list by the end of the day (any time zone) January 2nd.
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>> As a reminder this document is part of the larger set of adoption
>> calls
>>
>> >>>>
>>
>> >>>> of the documents discussed at IETF 124:
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/05
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwarding/18
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>> https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanism/13
>>
>> >>>>
>>
>> >>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/09
>>
>> >>>>
>>
>> >>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/06
>>
>> >>>>
>>
>> >>>>
>> https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/04
>>
>> >>>>
>>
>> >>>> https://datatracker.ietf.org/doc/draft-ryoo-detnet-nscore/02
>>
>> >>>>
>>
>> >>>>
>>
>> >>>>
>>
>> >>>> Thank you,
>>
>> >>>>
>>
>> >>>> János (as Co-chair)
>>
>> >>>>
>>
>> >>>>
>>
>> >>>> _______________________________________________
>>
>> >>>> detnet mailing list -- [e-mail]
>>
>> >>>> To unsubscribe send an email to [e-mail]
>>
>> >>>>
>>
>> >>> _______________________________________________
>>
>> >>> detnet mailing list -- [e-mail]
>>
>> >>> To unsubscribe send an email to [e-mail]
>>
>> >>>
>>
>> >>
>>
>>    - [Detnet] WG adoption poll: joung-detnet-stateless…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/Q2JXJlfyvd-WzGkkqtRfCr3yHOs/>  Janos
>>    Farkas
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/tqDrY-nmIDalPRGf5OMD0_xWvOU/>  Mike
>>    Blanche
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/S51eXeGt_UcT_1cVqUZrUxejR3U/>
>>      song.xueyan2
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/3MdTx2InCj1rbv31dZrqBFzfio8/>  Jinoo
>>    Joung
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/BE3XHigD2aMc8-NgWPZhBWRG_ic/>  Yizhou
>>    Li
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/l6I5fRbyBp1QQZEYv-4sSuSve_E/>
>>      유연철
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/7ksa7vAMmQ3sehku5DO8LfONpPg/>  Jeong-dong
>>    Ryoo
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/2GqbxqQFYw2wYOv1c8UnF3alGns/>
>>      xiong.quan
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/_G3i5tAVEVx2ptaZ5waatbMJo6Y/>
>>      정태식
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/FFbeeIUbtYnhRQ04YDfa13_3hrc/>  Mike
>>    Blanche
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/Ea4920SPZmgxU-0npKrss00EI7Y/>  Jinoo
>>    Joung
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/24tmXTeBKDecp-cQi4rhK1H0jGk/>
>>      [e-mail]
>>    - [Detnet] Re: WG adoption poll: joung-detnet-state…
>>    <https://mailarchive.ietf.org/arch/msg/detnet/AhQOorY02WR6zJowkcLrXGPqk-E/>  Xuesong
>>    Geng
>>
>>
>>
>> _______________________________________________
>> detnet mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> detnet mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>