Ballot for charter-ietf-fann
Yes
No Objection
Note: This ballot was opened for revision 00-01 and is now closed.
Ballot question: "Is this charter ready for external review?"
Hi all, Thank you for the effort put into the charter. # Overall The problem space is an interesting one. Although, it is not clear if the solution has to be at the routing level (at the first place), a network management (including INT/in-situ), a new application shim for advertisement of relevant events, or a combination therefore, I’m supportive of this work. Such matters can be the outcome of the exploration proposed here. The charter includes provisions for ops/deployment work item. That work can be the place to assess links and interference when similar efforts are also enabled at Layer 2 or Layer 4. I’m not suggesting to make any change to the charter to cover inter-layer dependency although I think that ignoring them may lead to biased results. # Responsiveness: application-specific CURRENT: Many network applications, including AI/ML training/inference and cloud services, require high bandwidth, low loss, low delay, and low jitter networks that can rapidly adapt to link faults, degradation, congestion, and other such adverse conditions to maintain service continuity and experience. .. The WG will initially focus on notifications for link failures, signal degradation, and port output queue congestion, while ensuring extensibility for additional conditions in the future. There is a dependency between the FANN component (whatsoever that means) and expectations of applications making use of a network. However, the technical work is scoped vs. specific events not traffic performance characteristics bounds that that can be provided. These bounds are application-specific. Should the work be scoped so that FANN outcome can be customized per application need? Or the expectation is that it is a generic component that is tweaked independent of applications running on a network? # Some minor comments ## Configuration is a management function OLD: YANG models for configuration and management of the solution NEW: YANG models for the management of the solution ## signal degradation Not sure which signal are we referring to here. Cheers, Med
I agree with Eric V re: is it necessary to have 'including AI/ML training/inference and cloud services'? I think it is fine without that phrase.
Thanks for the work done on this charter (and for being specific about the intended publication status). Some comments though: Unsure whether ` including AI/ML training/inference and cloud services` helps in a charter. I find the sentence `...is chartered to investigate this problem space...` conflicting with the text later about `the WG will work on the development`. Why not a "must" in `These mechanisms may include discovery and registration procedures ` ?
Removing the BLOCK to help move the charter discussion for External Review. The change in the charter text puts the management plane notification out of scope for the primary objective. In my mind, it was clear that the management plane was not the primary objective. But thanks for making it clear in the charter. The clarification I was looking for in the charter had to do with the secondary objective, which talks about supporting consumption by the management system. For that piece of work, can we clarify that the solution would look at existing definitions of management notification in other WGs? "IETF.", paragraph 16 > Jun 2027 - Submit Framework Document to IESG for publication > > Jun 2027 - Adopt Specifications Document(s) for Network Notifications > > Dec 2027 - Adopt Applicability Document > > Dec 2027 - Adopt YANG Modules Document > > Jul 2028 - Submit Specifications Document(s) for Network Notifications to IESG for > publication Can we make the last milestone date as Dec 2028
I believe this charter is ready for external review. It is well written and it describes a well-scoped area of work that has an understandable relationship to other WGs without much ambiguity.
One note: it opens with an emphasis on AI/ML use cases by giving this as the only example, which is misleading. I recommend either (1) adding other examples of use cases where existing data center networking performance is insufficient or (2) simply not list examples given the alternative to this charter's claim can be rejected ("data center networking performance is a solved problem"). AI/ML is not unique among use cases requiring the best of networking.