[rtgwg] Re: [fantel] Re: Call for adoption: draft-dong-fantel-problem-statement-03 (Ends 2026-01-30)

[Adrian Farrel <[e-mail]>]

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 <David.Black=[e-mail]> 
Sent: 16 January 2026 15:27
To: Yingzhen Qu <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Cc: Black, David <[e-mail]>
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 <[e-mail]>
Sent: Thursday, January 15, 2026 2:12 PM
To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
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 -- [e-mail]
To unsubscribe send an email to [e-mail]

_______________________________________________
fantel mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]