Return-Path: X-Original-To: detnet@mail2.ietf.org Delivered-To: detnet@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 948F2AA70492 for ; Tue, 20 Jan 2026 07:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=smu-ac-kr.20230601.gappssmtp.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svNPJkZpPVlV for ; Tue, 20 Jan 2026 07:24:28 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id D62DDAA702B1 for ; Tue, 20 Jan 2026 07:23:22 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-59b672f8e40so6918279e87.2 for ; Tue, 20 Jan 2026 07:23:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768922595; cv=none; d=google.com; s=arc-20240605; b=UNswIhiS186ibcmFl1V0LVB9Gk1lOcj0elC5A7BpIrk+kl0LXyfbNZxpsqx0ZthOfY Iy2jQrQ8mRmEs/GkAudpENFcsWqzX90DZRPcodTPPCpr2pQXhCOPfxl9Rr6Tz+3vZiyW X6df0CRi5ZXqtIc/d23U4SdQj5Z9ISu1zHvkUxkmgTkGxISRsmad+1zo9qy4hWip6HUm Quwc98ivEAaktO7ZwNAXNlqKsKoLTuBGr1NXVVCPd4uyM2eTWn5wDW6YdyC3gOmmKjHw bl+yZnYPFNE71+WbSOhp9LzyMdXDJEqSx0svP2K//HfIf0CK8olPffC1xLnt0IAYBuRc 6cvw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=8puj3sGMm87BA0z4J3qk0DON0bp56CDCZkXalecF9qA=; fh=jApumuotgKtbxz0J9edxYAWkCTwbCqKuYp+9HLm2DJU=; b=SWECOS+aPLFKq2q7YolT4UfgHORyB6+DH2HixJqbZEb4IsAbuJMtwHKK3xMs73zx3W DxfOz3Rul2trx8Q0yuIRiqY9zayvHUSFY7a8tA8WPWKeskpPYmOBfsu5T9jSiKv/gP8i 6bWLOIN1OnqTGqklaa1o9RLgDBbS848+eORdcjDPVZdpCoflraIHCx/5//o4pXLCalzG jV6n8wKIp16v7GpUyfgLo7bVCL8HDtgJvkaRnDu3bXNWcQYQVBprSQaOVVjB4GMzhmhp thq8vZeq76ujSLDWvhdULcEXi8owdsLLgVwXEifDWmJNvxtXSOQz+wYzNdg/2QkLr4kv yONA==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=smu-ac-kr.20230601.gappssmtp.com; s=20230601; t=1768922595; x=1769527395; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=8puj3sGMm87BA0z4J3qk0DON0bp56CDCZkXalecF9qA=; b=Wlu8WtFY7oWH7egWnxQXdEUFEkxKky1LCtghv2K4fi7eGOCKDH9soqpgezDj+UI+kW 3TrS1oP/RnhV7hOPgjhqRjos2r/YsEUuc3yBCYuxV9dLtqvMjO2+J8clDYNDoqK5wIaS HqGmM+lG/HEy7l5gAdGMWXWeyzy3sQPrF+9e82SNhFOGk3EZv2/vp2buPpZniey+5Fiv rr/MqqjrYf2AflhAuwB6DbDth4YWb+MoSo5eRDQ9pTggTGf8sTP8AkdIwnL+Ql+4V1L0 7nVPsUYy4jGz6Kvtg5+LjDYjbfLAm+P8KGYnbaw5yEQC4EbXrgNZkG54CZNbimK+Ei6/ 8mEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768922595; x=1769527395; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=8puj3sGMm87BA0z4J3qk0DON0bp56CDCZkXalecF9qA=; b=HyUVITYn314DGaQuvGIM/wM7tZbSuzxx+cI3UKV5jkdfS3ZDLzqhOvHAHnlTRv0aVZ ExpebSbVhZesfwcDKLpsC37LN4IAvTewiB9l9s4VpEFfalSbrzSXAF/OCsfCyUOfDf18 WJPOXLAAy76f9OYbAWUlq2Xsn0ahvSoUId5XTVS4aEaFAG1CVI4yasNkcDsuEghNQshk eqA5rxTHrLAB+oZ7LLOU5SKVGHDP+jk0E2wAEilaXpLmJbk/7HEMQOAW7TpptUQcYIG3 KrlsFg5TdvCIXRaC4B2RlaMWzDLDRdgSnMH06ea7WsCrmCiOAwJWnKzUmHpdx49AqToL Jcjg== X-Gm-Message-State: AOJu0YxSthY98c0sS3/BkWDFqKoHzl0Wq+7lkrtvXWbwMZemsan3J6Dq Xg4l7nzcRE8lwMZatp9wcgp3ZeXUFRzJi+4yFVtT68PhufNMb9bVfa84hgMzw1jzGb1yKUHJk8n MJOZet59KJSnmG+yB9RvQDKSjQCcIHXokaO0PSVTScYm+DXTOvwrN4rk= X-Gm-Gg: AZuq6aJ6cv+de5aID2zSRuThFN0Pehgl/E/5gpxchju1PzFUEAICkOsYHO2S97/rwAB iTy51EZiuekO1TlJxy6KngWzE/4ArHkh2JRhqh96L7D2yl74ANWWgIK3/o3Yzwob1SWhOGDR02M r0Ft0Rj7kyRsAlHfBytmx8Vad5jR5JQWg9Op9kyVzVal51MvKo05HVfTLN40zIspxAM027OFtHJ 0jp9zE6XzDdSeMmwt1O7EYFrSnoePkB9uEh+6Z0In9mFzvjaVR5/SIdwkiidvJy9W4J4fd5NA== X-Received: by 2002:a05:6512:3d91:b0:59b:b3fd:ea24 with SMTP id 2adb3069b0e04-59dc935a992mr922204e87.44.1768922594521; Tue, 20 Jan 2026 07:23:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jinoo Joung Date: Wed, 21 Jan 2026 00:23:02 +0900 X-Gm-Features: AZwV_Qgy3h7VKA8NoygzhZ4qlZR3G1tJstcCy11E24q-D7W4gok_hxctrqmFExY Message-ID: To: Scott Mansfield Content-Type: multipart/alternative; boundary="000000000000e1c2a60648d36290" Message-ID-Hash: RUYXIDIHZYVV7VS2WUAHPD3LQCDZEXK2 X-Message-ID-Hash: RUYXIDIHZYVV7VS2WUAHPD3LQCDZEXK2 X-MailFrom: jjoung@smu.ac.kr X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-detnet.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "detnet@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BDetnet=5D_Re=3A_WG_adoption_poll=3A_joung-detnet-stateless-fair?= =?utf-8?q?-queuing-05?= List-Id: Discussions on Deterministic Networking BoF and Proposed WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000e1c2a60648d36290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Scott Mansfield 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 partie= s > comfortable I would suggest the following: > > > > Potential Action: > > The process of =E2=80=9Cgap analysis=E2=80=9D 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 wha= t > 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 th= e > 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 lon= g > 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 an= d > 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 fundamenta= l > 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 coordinate= d > 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 t= he > authors are the same in both groups, this is the best way to gain consens= us > 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 ca= n > 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 Fri, 02 January 2026 22:16 UTCShow header > > > 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=E2=80=AFAM Mike Blanche 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 do= ne > > > 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 inconsisten= t > 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 o= r > > > Y.3148. > > > > > > Thanks, > > > > > > Mike > > > > > > On Tue, 23 Dec 2025 at 00:08, Jinoo Joung 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 o= f > 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=E2=80=AFAM Mike Blanche > > >> 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 simila= r > - > > >>> 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 > >>> 40ericsson.com@dmarc.ietf.org> wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> > > >>>> > > >>>> This email begins a 4-week adoption poll for: > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> > https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuin= g/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-queuin= g/05 > > >>>> > > >>>> > > >>>> > https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forward= ing/18 > > >>>> > > >>>> > > >>>> > https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechan= ism/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=C3=A1nos (as Co-chair) > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> detnet mailing list -- detnet@ietf.org > > >>>> To unsubscribe send an email to detnet-leave@ietf.org > > >>>> > > >>> _______________________________________________ > > >>> detnet mailing list -- detnet@ietf.org > > >>> To unsubscribe send an email to detnet-leave@ietf.org > > >>> > > >> > > - [Detnet] WG adoption poll: joung-detnet-stateless=E2=80=A6 > Janos > Farkas > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Mike > Blanche > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > > song.xueyan2 > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Jinoo > Joung > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Yizhou > Li > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > > =EC=9C=A0=EC=97=B0=EC=B2=A0 > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Jeong-dong > Ryoo > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > > xiong.quan > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > > =EC=A0=95=ED=83=9C=EC=8B=9D > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Mike > Blanche > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Jinoo > Joung > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > > liupengyjy@chinamobile.com > - [Detnet] Re: WG adoption poll: joung-detnet-state=E2=80=A6 > Xuesong > Geng > > > _______________________________________________ > detnet mailing list -- detnet@ietf.org > To unsubscribe send an email to detnet-leave@ietf.org > --000000000000e1c2a60648d36290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Scott,

Thanks for your valua= ble suggestions.
I deeply appreciate your efforts to resolve this issue = in a fair and reasonable manner.
I agree with your proposed action.
<= br>I have answered your guidelines in-line marked with JJ. Please take a lo= ok.

In short, there is a clear gap between the ITU-T work and the IE= TF document.
While ITU-T work focuses on the requirements and framework,= the IETF document will elaborate on IP/MPLS specific information for deplo= yment, including header fields and formats, protocols for admission control= and time-difference compensation.
It will also include implementation d= etails for approximating fair queuing with a strict priority scheduler.
=
Many thanks and best regards,
Jinoo

On Tue,= Jan 20, 2026 at 6:11=E2=80=AFAM Scott Mansfield <scott.mansfield=3D40ericsson.com@dmarc.ietf.org<= /a>> wrote:
<= div class=3D"msg2408535913656230836">

Hi,

=C2=A0<= /span>

Speaking as a liaison= manager between the IETF and ITU-T, it is important to note a few guidelin= es.=C2=A0 Following this discussion, I observe there is concern that there = is work being duplicated.=C2=A0 In order to make all parties comfortable I would suggest the following:<= /span>

=C2=A0<= /span>

Potential Action:<= /u>

The process of =E2=80= =9Cgap analysis=E2=80=9D is used a lot in the ITU-T to ensure new work item= s do not duplicate work already done by the industry recognized center of c= ompetence.=C2=A0 The reverse is true as well.=C2=A0 I would want to see the gap that the IETF is filling here and how it augments or m= odifies what the ITU-T has already done.=C2=A0 If there are modifications t= o the ITU-T work needed, I would like to see the authors plans to progress = that work in the ITU-T.


- 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 th= e ITU-T.=C2=A0 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 wil= l explain how to use the fundamentals described in the ITU-T work.
=C2=A0

- If the IETF work is really changing the math, that should be coordinated = too.=C2=A0 If the ITU-T work missed something, or is not appropriate for th= e IETF use-case, again, coordination is needed.=C2=A0 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 gro= up is followed.


JJ: I definitely agree with you.

I find coordination a= nd cooperation is best handled when people work together and have people th= at attend each organization and follow the processes of the organization wh= en progressing the documents.=C2=A0 Liaison can be used, but they tend to be slow.=C2=A0 The IETF DetNet mailing list = is the proper place to have this discussion especially if there are partici= pants in this working group that need clarity to ensure work is not duplica= ted.

=C2=A0=

Many thanks,

-scott.=

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

[Detnet] Re: WG adopt= ion poll: joung-detnet-stateless-fair-queuing-05

Jinoo Joung <jjoung@smu.ac.kr>= =C2=A0Fri, 02 January 2026 22:16 UTCShow heade= r

Hello Mike, it's = great to hear from you.

Thanks for the valuab= le feedback.

It seems that your ma= jor concern is the discrepancy between the standards.<= /p>

=C2=A0<= /span>

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 e= quation into two or three sentences.

That is why it seems = the number of requirements are different.

If you find any discr= epancies, just let me know.

=C2=A0<= /span>

Y.3148 also deals wit= h considerations for metadata, but it still is at an

academic level.

These two ITU-T stand= ards are strictly based on the paper:

https://ieeexplore.i= eee.org/document/10261190

=C2=A0<= /span>

Best regards,<= u>

Jinoo

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

On Sat, Jan 3, 2026 a= t 4:09= =E2=80=AFAM Mike Blanche <mike-ietf@blanche.org> wrote:

=C2=A0<= /span>

>=C2=A0<= /u>

> Hi Jinoo and all= ,

>=C2=A0<= /u>

> Although the C-S= CORE approach may be an appropriate solution within the

> agreed taxonomy,= I am still concerned about duplicating work already done

> elsewhere.

>=C2=A0<= /u>

> What happens if = the IETF draft diverges from the ITU Recommendation?

> Y.3129 makes 9 &= quot;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 imp= lementations depending on which document implementers<= /p>

> follow.

>=C2=A0<= /u>

> I see the new dr= aft=C2=A0 (-06) focuses more on the necessary metadata. This is

> also already doc= umented in ITU-T Y.3148, which covers metadata creation and

> updating procedu= res in depth. Again, how will it be ensured that this draft

> does not diverge= from or conflict with the existing ITU Recommendation?

>=C2=A0<= /u>

> The latest draft= still does not cite either ITU Recommendation Y.3129 or

> Y.3148.

>=C2=A0<= /u>

> Thanks,

>=C2=A0<= /u>

> Mike

>=C2=A0<= /u>

> On Tue, 23 Dec 2= 025 at 00:08, Jinoo Joung <jjoung@smu.ac.kr> wrote:

>=C2=A0<= /u>

>>=C2=A0=

>> Hello Mike, = thanks for the comment regarding the work in ITU-T.

>> I understand= your concern.

>>=C2=A0=

>> Hello WG and= Mike,

>>=C2=A0=

>> The C-SCORE = draft, as indicated in the version 6, will have the following=

>> details in t= he future, once accepted as the WG draft.

>> 1) MPLS and = IP specific protocol details: This includes the header=

>> fields/forma= ts, interactions between nodes and between control/data planes.

>> 2) Implement= ation issues regarding the priority queue, which is currently=

>> required to = sort the packets in FT orders: This includes an approximation=

>> technique ba= sed on strict priority schedulers.

>>=C2=A0=

>> Y.3129 is fo= cused on the requirements and provides theoretical

>> justificatio= ns but the C-SCORE draft targets on the solution.

>> Some framewo= rk 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.

>>=C2=A0=

>> C-SCORE is n= ot a new invention.

>> It is an out= come of the numerous researches conducted during late '90 ~

>> early '0= 0s, which was the peak period of Internet research.

>> There are mo= re than hundreds of papers that are related to the fair

>> queuing, aft= er all.

>>=C2=A0=

>> I believe it= is worth being standardized by such virtues:

>> 1) flow isol= ation capability, which protects from other flows'=

>> join/leave, = bursts, or even malicious behaviours

>> 2) scalabili= ty due to its stateless nature

>> 3) flexibili= ty from network asymmetry such as link capacity variations

>> and uneven p= ropagation delays

>> 4) simple ad= mission criteria, which allows incremental flow acceptance,

>> without modi= fying existing network setup

>> 5) small ave= rage delay due to work conserving nature,

>> just to ment= ion a few. :-)

>>=C2=A0=

>> Best regards= ,

>> Jinoo (on be= half of authors)

>>=C2=A0=

>>=C2=A0=

>>=C2=A0=

>> On Fri, Dec = 12, 2025 at 12:10=E2=80=AFAM Mike Blanche <= ;mike-ietf@blanc= he.org>

>> wrote:

>>=C2=A0=

>>>= =C2=A0

>>> Hi all,<= u>

>>>= =C2=A0

>>> This pro= posal appears very similar to ITU-T Recommendation Y.3129, which<= /u>

>>> I believ= e was developed by some of the same authors.

>>>= =C2=A0

>>> https://www.itu.int/rec/T-REC-Y.3129-202404-I/en

>>>= =C2=A0

>>> The abst= ract text of the I-D is virtually identical to the summary of=

>>> Y.3129. = In addition, significant parts of the content are very similar -<= /u>

>>> e.g. par= ts of section 6.3 of the draft are word-for-word the same as parts

>>> of secti= on 8 of the ITU-T Recommendation.

>>>= =C2=A0

>>> The ITU-= T Recommendation is missing from the draft's References section.=

>>>= =C2=A0

>>> I am unc= lear why we are considering duplicating work that appears to be

>>> already = completed at the ITU.

>>>= =C2=A0

>>> Best reg= ards,

>>>= =C2=A0

>>> Mike<= /u>

>>>= =C2=A0

>>> On Fri, = 5 Dec 2025 at 15:49, Janos Farkas <Janos.Farkas=3D<= /p>

>>> 40ericsson.com@= dmarc.ietf.org> wrote:

>>>= =C2=A0

>>>> Hi,<= u>

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> This= email begins a 4-week adoption poll for:

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/= 05/

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> No I= PR has been disclosed for this document.

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> Plea= se voice your support or technical objections to adoption on the<= /u>

>>>>=C2=A0

>>>> list= by the end of the day (any time zone) January 2nd.

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> As a= reminder this document is part of the larger set of adoption calls<= u>

>>>>=C2=A0

>>>> of t= he documents discussed at IETF 124:

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-joung-detnet-stateless-fair-queuing/= 05

>>>>=C2=A0

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-deadline-based-forwardin= g/18

>>>>=C2=A0

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-peng-detnet-packet-timeslot-mechanis= m/13

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-tcqf/09<= /u>

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-eckert-detnet-glbf/06<= /u>

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-ryoo-detnet-ontime-forwarding/04=

>>>>=C2=A0

>>>> https://datatracker.ietf.org/doc/draft-ryoo-detnet-nscore/02<= /u>

>>>>=C2=A0

>>>>=C2=A0

>>>>=C2=A0

>>>> Than= k you,

>>>>=C2=A0

>>>> J=C3= =A1nos (as Co-chair)

>>>>=C2=A0

>>>>=C2=A0

>>>> ____= ___________________________________________

>>>> detn= et mailing list -- detnet@ietf.org

>>>> To u= nsubscribe send an email to detnet-leave@iet= f.org

>>>>=C2=A0

>>> ________= _______________________________________

>>> detnet m= ailing list -- detnet@ietf.org

>>> To unsub= scribe send an email to detnet-leave@iet= f.org

>>>= =C2=A0

>>=C2=A0=

=C2=A0<= /span>

_______________________________________________
detnet mailing list -- detnet@ietf.org
To unsubscribe send an email to detnet-leave@ietf.org
--000000000000e1c2a60648d36290--