Hi All, Based on comments from this adoption poll and offline queries, I would like to clarify that this call is a follow-up to the FANTEL BoF at IETF 123, as previously shared [1].
Incubation in the RTGWG provides a forum for detailed work on applicability, problem statements, and requirements. This is particularly useful when a BoF does not allow sufficient time to build consensus or when a project benefits from the diverse expertise within this group—a factor that is very important in this case. Adrian’s email [2] captures this sentiment well. If successful, adoption marks the start of the Working Group's development and consensus-building efforts. The goal here is not the usual publication as an RFC, but rather to improve the chances of successful incubation as requested in [1]. Thanks, Ketan (Responsible AD for the FANTEL BoF) [1] https://mailarchive.ietf.org/arch/msg/rtgwg/9NYD38DwXj8bjLoVm3fRri4H2ck/ (https://mailarchive.ietf.org/arch/msg/rtgwg/9NYD38DwXj8bjLoVm3fRri4H2ck/) [2] https://mailarchive.ietf.org/arch/msg/rtgwg/l99pktmU0nHJDYJNeXIw4MeX3Xg/ (https://mailarchive.ietf.org/arch/msg/rtgwg/l99pktmU0nHJDYJNeXIw4MeX3Xg/) On Fri, Jan 16, 2026 at 10:21 PM Yingzhen Qu <[email protected]> wrote: > Hi all, > > The adoption call for this draft doesn't mean that RTGWG intends to > publish it or will do the protocol work, but rather RTGWG is performing the > incubation function. Like Adrian mentioned, the adoption call is a poll to > gather more reviews and reach consensus on the problem scope. > > Assuming there is consensus, the proponents can work on a charter. "Developing > a charter and establishing consensus for a new WG" is in RTGWG's charter, > and RTGWG is a venue for such work. RTGWG chairs can recommend forming a > new WG to the RTG ADs. The ADs will determine whether another BoF is needed. > > Thanks, > Yingzhen (RTGWG Co-chair) > > On Fri, Jan 16, 2026 at 7:55 AM Adrian Farrel <[email protected]> wrote: > >> Hi David, >> >> I was NOT speaking against adoption, but was asking the RTGWG chairs what >> they think the next step in the incubation process is. >> >> It would be helpful if the chairs explained a little about the purpose of >> the adoption poll that they issued. How does this drive the future of the >> Fantel work? >> >> I would say: >> - The chairs appear to think that the best approach to getting input and >> opinions on the Fantel problem statement is to do an adoption poll that >> "forces" some reviews and determines whether there is consensus that this >> is a problem to work on. >> - While the proponents could BoF this again, that seems to go against the >> idea of RTGWG incubating the topic. >> - Adopting a draft does not imply future plans for publication as an RFC, >> but places the work under the care of the WG so that updates reflect WG >> opinions (not just the whims of the authors). >> - Adopting this draft does not imply that the WG will do protocol work (I >> think it would have to recharter) or that the AD will form a Fantel WG >> (that would require chartering). It simply advances the stability of this >> work. >> - Listing 13 authors on the front page of a draft is not good and must be >> fixed before the draft is adopted. >> >> Separate email to follow on whether I think this draft is ready for >> adoption. >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: Black, David <[email protected]> >> Sent: 16 January 2026 15:27 >> To: Yingzhen Qu <[email protected]>; [email protected]; >> [email protected]; [email protected]; >> [email protected] >> Cc: Black, David <[email protected]> >> Subject: [fantel] Re: [rtgwg] Call for adoption: >> draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) >> >> At this time, I oppose adoption of this draft by itself primarily for >> reasons already stated by Adrian and Joel. >> >> Adrian: >> > Obviously, RTGWG has been doing a good job nurturing the effort and >> giving us a place to discuss the drafts. The question is: how does this >> incubation proceed? >> > Do we adopt drafts into RTGWG and continue to work on them there, or do >> we BoF Fantel now that we have a fairly clear problem statement? >> >> Joel: >> > Net: While I see a nice sketch of a topic for investigation, I do not >> see enough clarity for adoption. >> >> By itself, RFC publication of a problem statement (intended outcome of WG >> adoption of a problem statement draft) without follow-on work would be a >> waste of time and effort, so WG adoption of this draft would be an implicit >> commitment that RTGWG will do some protocol work, but it's unclear what >> protocol work is being implicitly committed to. For that reason, this >> draft needs to be accompanied by a scope and plan for initial protocol work >> - I would suggest that the initial work focus on network operators and >> traffic engineering, leaving end-nodes and application considerations to be >> addressed in possible later stages, but that's only my opinion, and there >> are other possibilities. >> >> A problem statement draft is not a good vehicle for proposing and >> describing initial work because the resulting RFC will be an archive >> document and the proposed work scope and plan will likely be "overtaken by >> events" ;-). Work scope and plan topics are much better addressed in a >> draft WG charter, as WG charters are not archive documents. If that is >> done, then a BoF would be an appropriate next step, although not the only >> possible one, as Adrian has observed. >> >> Also, the number of authors (13) of this draft is excessive - that will >> need to change at some point (not necessarily now). See section 4.1.1 of >> RFC 7322 (https://www.rfc-editor.org/rfc/rfc7322.html#section-4.1.1). >> >> Thanks, --David >> >> -----Original Message----- >> From: Yingzhen Qu via Datatracker <[email protected]> >> Sent: Thursday, January 15, 2026 2:12 PM >> To: [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: [rtgwg] Call for adoption: >> draft-dong-fantel-problem-statement-03 (Ends 2026-01-30) >> >> [EXTERNAL EMAIL] >> >> This message starts a rtgwg WG Call for Adoption of: >> draft-dong-fantel-problem-statement-03 >> >> This Working Group Call for Adoption ends on 2026-01-30 >> >> Abstract: >> Modern networks require adaptive traffic manipulation including >> Traffic Engineering (TE), load balancing, flow control, and >> protection, to support high-throughput, low-latency, and lossless >> applications such as Artificial Intelligence (AI) /Machine Learning >> (ML) training and real-time services. A good and timely >> understanding of network operational status, such as congestion and >> failures, can help to improve network utilization, enable the >> selection of paths with reduced latency, and enable faster response >> to critical events. This document describes the existing problems >> and why a new set of fast network notification solutions are needed. >> >> Please reply to this message and indicate whether or not you support >> adoption >> of this Internet-Draft by the rtgwg WG. Comments to explain your >> preference >> are greatly appreciated. Please reply to all recipients of this message >> and >> include this message in your response. >> >> Authors, and WG participants in general, are reminded of the Intellectual >> Property Rights (IPR) disclosure obligations described in BCP 79 [2]. >> Appropriate IPR disclosures required for full conformance with the >> provisions >> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. >> Sanctions available for application to violators of IETF IPR Policy can be >> found at [3]. >> >> Thank you. >> [1] https://datatracker.ietf.org/doc/bcp78/ >> [2] https://datatracker.ietf.org/doc/bcp79/ >> [3] https://datatracker.ietf.org/doc/rfc6701/ >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-dong-fantel-problem-statement/ >> >> There is also an HTMLized version available at: >> >> https://datatracker.ietf.org/doc/html/draft-dong-fantel-problem-statement-03 >> >> A diff from the previous version is available at: >> >> https://author-tools.ietf.org/iddiff?url2=draft-dong-fantel-problem-statement-03 >> >> _______________________________________________ >> rtgwg mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> fantel mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ > fantel mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
