The correct link for the issues is https://github.com/ietf-wg-cats/draft-ietf-cats-framework/issues
", "time": "2025-03-18T10:11:21Z"}, {"author": "Julien Maisonneuve", "text": "There are still 10 issues in the tracker, some significant, is it appropriate to ask for last call just now ?
", "time": "2025-03-18T10:21:29Z"}, {"author": "Dhruv Dhody", "text": "https://datatracker.ietf.org/doc/rfc6123/
", "time": "2025-03-18T10:21:36Z"}, {"author": "Adrian Farrel", "text": "@Julien It's a presentation at an IETF WG meeting, how can it not say \"WGLC please\"?
", "time": "2025-03-18T10:25:46Z"}, {"author": "Joel Halpern", "text": "As far as I can tell, it is perfectly fine for CATS to be used by some traffic, while other traffic uses other means to select servers (for example, host based means that result in destination IP addresses that do not need CATS processing.
", "time": "2025-03-18T10:27:12Z"}, {"author": "Adrian Farrel", "text": "@Joel. Indeed. Incremental and support for legacy services is important.
", "time": "2025-03-18T10:30:59Z"}, {"author": "Cheng Li", "text": "Hi Joel, We are not asking the WGLC now. We ask for a round of deep review, and we need to address all the issues. Then, we can ask for WGLC
", "time": "2025-03-18T10:31:23Z"}, {"author": "Cheng Li", "text": "sorry, Julien, not Joel.
", "time": "2025-03-18T10:32:15Z"}, {"author": "Julien Maisonneuve", "text": "I don't understand the new R14
", "time": "2025-03-18T10:37:02Z"}, {"author": "Julien Maisonneuve", "text": "I think it needs to be rephrased.
", "time": "2025-03-18T10:41:22Z"}, {"author": "Julien Maisonneuve", "text": "I also feel it addresses two different topics frquency and distribution
", "time": "2025-03-18T10:42:02Z"}, {"author": "Julien Maisonneuve", "text": "R3 looks original but may be application and not CATS-related, others appear already implied.
", "time": "2025-03-18T10:48:00Z"}, {"author": "Dirk Trossen", "text": "As for R19, I would think this to be of relevance to the AI use case. As for R20, I would expect AR/VR relying on mobility support, possibly when thinking of mobile federated learning.
", "time": "2025-03-18T10:48:52Z"}, {"author": "Joel Halpern", "text": "Time of delivery sounds like soemthing outside of the scope fo CATS.
", "time": "2025-03-18T10:51:58Z"}, {"author": "Joel Halpern", "text": "As far as I know, there is no assumption in CATS that one CATS trafffic director knows anything about any other traffic sources beign serviced by other traffic steering entities. Trying to pick the point that is equi-distant from all the sources is a very different operational model.
", "time": "2025-03-18T10:54:34Z"}, {"author": "Julien Maisonneuve", "text": "Traffic steering, Latency sensitivity and Scalability are exactly the motivations to use CATS, they are not new requirements.
", "time": "2025-03-18T10:54:48Z"}, {"author": "Julien Maisonneuve", "text": "Oh, security BTW.
", "time": "2025-03-18T10:55:24Z"}, {"author": "Julien Maisonneuve", "text": "Same for security.
", "time": "2025-03-18T10:55:39Z"}, {"author": "Adrian Farrel", "text": "To all of this discussion: yes. I am looking for what are the new requirements
", "time": "2025-03-18T10:56:23Z"}, {"author": "Adrian Farrel", "text": "@Joel Queue Closed
", "time": "2025-03-18T10:59:15Z"}, {"author": "Dirk Trossen", "text": "@joel ultimately, I agree. Just trying to narrow down the problem (away from the synchronization problem) to then focus how the requirement ought to look like. I tend to agree that the decision model needed for that requirement is quite different from what we have had in mind so far.
", "time": "2025-03-18T10:59:18Z"}, {"author": "Joel Halpern", "text": "Multi-source coordination is not something an edge node reacting to the traffic it sees can do.
", "time": "2025-03-18T10:59:56Z"}, {"author": "Julien Maisonneuve", "text": "I think the sync requirement needs rewriting, and it may imply a specific \"validity period\" that can be used for CATS scheduling.
", "time": "2025-03-18T11:00:00Z"}, {"author": "Julien Maisonneuve", "text": "I don't understand how the task model relates to CATS requests.
", "time": "2025-03-18T11:06:10Z"}, {"author": "Peng Liu", "text": "it will select the service instances for several sub tasks according to both network and computing status I think.
", "time": "2025-03-18T11:09:32Z"}, {"author": "Dirk Trossen", "text": "Why would we expose a service level structure (of sub-tasks) to CATS to enforce joint TS handling of that structure? Just bundle it at service levels and the single transaction (from the CATS perspective) will be handling all sub-tasks in one decision process.
", "time": "2025-03-18T11:15:44Z"}, {"author": "Julien Maisonneuve", "text": "+1
", "time": "2025-03-18T11:27:22Z"}, {"author": "Adrian Farrel", "text": "@Dirk Sorry, queue closed
", "time": "2025-03-18T11:31:46Z"}, {"author": "Julien Maisonneuve", "text": "Did we discuss the CATS framework ?
", "time": "2025-03-18T11:33:08Z"}, {"author": "Adrian Farrel", "text": "@Julien We did :-)
", "time": "2025-03-18T11:33:21Z"}, {"author": "Julien Maisonneuve", "text": "OK, I'll send my comments on the list then.
", "time": "2025-03-18T11:34:29Z"}, {"author": "Dirk Trossen", "text": "Putting my comment here, following up on Julien: shouldn't the guidance for the metric definition, e.g. the motivation for various levels, come through the alignment with the respective requirements? I miss this alignment entirely in the document (finding no reference to the requirements).
", "time": "2025-03-18T11:35:21Z"}, {"author": "Julien Maisonneuve", "text": "+1
", "time": "2025-03-18T11:35:41Z"}]