Hi Adrian, Thanks for the feedback. Please see my answers below inline.
Thanks, Yingzhen On Mon, Nov 4, 2024 at 3:47 PM Adrian Farrel <adr...@olddog.co.uk> wrote: > [Sorry for breaking the threading, but I lost the original email] > > > > Hi chairs, > > > > Thanks for circulating the charter update proposal. > > > > I think it is a big shame that no one has commented on the list so far. I > have been trying to psychoanalyse why that might be. It could be that the > changes don't seem as big as they actually are because (maybe) people > already thought that was covered in the charter - thus, it is like a minor > editorial erratum. After all, there has not been so much push-back in > recent years about "incubating" new routing work through discussion of I-Ds > and holding "mini-BoF" sessions in WG meetings. > > > > It seems to me (did I get this right) that the change of substance is the > addition of one bullet paragraph to read: > > - Incubation of routing-related new technologies, particularly > focusing on problem statements, prior to achieving consensus for creating a > new working group. This includes, but not limited to, the following topics: > satellite routing, routing in data centers, and networking for AI clusters. > > > [Yingzhen]: Yes, this is the main change to the charter besides some editorial changes for clarity. 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. > > - > - 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… > - What does this initial list actually add? > - 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. 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. > > Cheers, > > Adrian >
_______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
