Yingzhen and all, From my POV the latest proposed text: Incubating new routing-related technologies by developing and discussing problem statements and requirements documents, prior to determining whether there is consensus or not for the creation of a new working group. If the working group agrees to pursue a problem statement or requirements document, it will be added to the group's milestones
disambiguates (to the degree possibleš) āincubationā and links it to the IETF process in a reasonable way. I support adding this text to the new Charter. Regards, Sasha From: Yingzhen Qu <yingzhen.i...@gmail.com> Sent: Tuesday, November 12, 2024 1:04 AM To: adr...@olddog.co.uk Cc: rtgwg-cha...@ietf.org; rtgwg@ietf.org Subject: [EXTERNAL] [rtgwg] Re: Charter updates Hi Adrian, Sorry for the late reply. Please see my answers below inline. Thanks, Yingzhen On Wed, Nov 6, 2024 at 3:38āÆAM Adrian Farrel <adr...@olddog.co.uk<mailto:adr...@olddog.co.uk>> wrote: Hey, Yingzhen. [snip] I am happy with the concept of providing an initial discussion venue for such topics, but: Ā· What does āincubationā mean in practice? I think this needs to be spelled out in the charter text because, as it stands, it is unclear where you would draw the line. Why would this not result in tens of documents being pushed to RFC on the topic of (for example) wet-string routing? How would the WG handle requests to discuss 12 new I-Ds on a new topic at an IETF? How would the WG protect the other chartered work of the working group against being swamped? Iād suggest that āparticularly focusing on problem statementsā be made more limiting such as, āby developing and discussing problem statement and requirements documentsā, and that āprior to achieving consensusā be end-limited as āprior to determining whether there is consensus or not for the creation of a new working group.ā [Yingzhen]: The "incubation" means to provide a venue for initial discussion which RTGWG has been doing already. Ideally we may give a new proposal/work one or two opportunities to present, and based on the feedback of the community we'll decide whether to continue. Use your wet-string routing example, if we really get tens of documents on the topic, and assuming they're not from the same author, I'd say most likely the community is interested in the topic. We should help to define the problem scope and recommend for a BoF before there are tens of documents on this topic. As for agenda building, we will always put WG documents on higher priority. Meanwhile we can always make use of interims and side meetings. I'm actually not too worried about getting too much work. It's way better than having nothing to work on. Regarding the charter update, I merged your suggestion. So how about something like: Incubating new routing-related technologies by developing and discussing problem statements and requirements documents, prior to determining whether there is consensus or not for the creation of a new working group. Initial topics include, but are not limited to, satellite routing, data center routing, and networking for AI clusters. [AF] This is all good stuff, and I donāt see anything I disagree with substantially. Butā¦ :-) The way to think about charter text is not just about how to guide the current (wise and competent) chairs, but how to guide the future (evil or dumb) chairs, and how to guide the highly-excitable and inventive WG participants. So, probably, we just need to cook some words that not rely on a single key word, but sets the scope and process and priority. [Yingzhen]: thanks for this "But". This is what we need. I agree with you that the charter of a WG should be specific, but not so specific that it may go out of date in a week of recharter. Ā· The text āThis includes, but is not limited toā is, I think intended to say āThe initial list of candidate topics is,ā with an addition of āother topics may be added after discussion with the WG chairsā. Butā¦ o What does this initial list actually add? o Will you track those other topics? How do the chairs decide? What happens when an idea wonāt go away, or keeps coming back? [Yingzhen]: Are you suggesting we shouldn't include this initial list? The "not limited to" meant to say we may also work on other topics. We can't predict the topics that may pop up, and recharter does have some overhead and take some time. Of course, if there is a topic that the community thinks RTGWG should work on, we can always recharter to include it. [AF] If you are saying that further topics will be added to the charter before they can be discussed (I donāt think you are saying that) then having the list would be fine. But otherwise, I think you are just making a list that will be out of date by the end of the week. So, how about, āA list of topics currently under consideration by the WG for incubation will be maintained on the WG Wiki pageā? [Yingzhen]: A new topic may pop up in RTGWG any time, so it's not possible for us to make a complete list of topics that the WG will be working on. How about if the WG agrees to work on the problem statement of a topic, for example the problem statement of wet-string routing, we will add this to the milestones of the WG. How about the following text for charter update: Incubating new routing-related technologies by developing and discussing problem statements and requirements documents, prior to determining whether there is consensus or not for the creation of a new working group. If the working group agrees to pursue a problem statement or requirements document, it will be added to the group's milestones. Since we just had the perceptive/adaptive routing side meeting, and since we have the AIDC mailing list, would you imagine that the day after rechartering all of that work would immediately move into RTGWG? [Yingzhen]: The preceptive/adaptive routing side meeting is actually a good example to show that efforts will also be made outside of RTGWG to figure out the problem space and whether there is something that the IETF can work on. Same for the AIDC side meetings and the mailing list where we also share the latest technology developments in the industry. [AF] Right. Two things should be clear. 1. New topics can be spun up in the RTG Area without āincubatingā them in RTGWG. Thus, side meetings, I-Ds, BoFs, WG formation do not need to use RTGWG. 2. RTGWG is available as *an* option for airing new topics. However, in this particular case, when stuff has advanced on several fronts, I think there is a search for coordination adviceā¦. - If perceptive/adaptive routing is already under RTGWG incubation, it would be helpful to know - If it is an option for the perceptive/adaptive routing proponents to incubate in RTGWG, then they need to self-organise to that end - If the AIDC list is the place to self-organise for perceptive/adaptive routing, this is *highly* non-obvious from the name of the list :-) [Yingzhen]: There are already drafts in RTGWG about different aspects of networking technologies in data centers for LLM training. I'm not sure whether you consider them related to perceptive/adaptive routing. These drafts are still at early stages and need further work. As for the AIDC mailing list, it was created to facilitate discussions related to the AIDC side meetings, where we discuss new technologies in DCs for AI. I thought the name was obvious, and it seems I'm mistaken. :) Cheers, Adrian Disclaimer This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
