[Chairs] BASH!
We will take item 3 first to help with the presenter's meeting conflict.
[Adrian and Peng] Thanks to Med for all his help as a co-chair in the
last year.
[Chairs] We had an interim meeting after the previous meeting,
focusing on the metric related discussion, and we had a good
achivements.(will be shared and discussed in this meeting)
Goals:
[Med] Regarding the encrypted traffic issue on the Github repo, we
need to dive deeper of the packet handling for encrpted packets.
Encourage the WG to have discussion on this.
[Cheng ]Hope you can send your comments to the Mailing list, we can
follow up.
[Joel] We may treat this carefully. We identify a flow by using IP
address, port, etc, but encryption does not change this. We might have
some challenge for handling QUIC flows, but for flow stickness, we still
use IP address and port, so the mechanism may be the same.
[Med] We do need to have some more concrete text on Provisioning.
Otherwise, we do not know how to configure the boxes.
[Adrian] Please look at the PCE WG's Manageability Consideratons
guidance and see what you might add to this
document.(https://datatracker.ietf.org/doc/rfc6123/, shared by Dhruv in
the Chat)
[Adrian] Looking for a volunteer to be document shepherd.
[Julien] Should we ask for WGLC when there are few issues open?
[Cheng] We will not ask for WGLC before we close all the open issues.
[Erum Welling] Please say what happens if there are still major issues
when the deadline for publication arrives.
[Adrian] The milestones are aspirational. We do not publish until we
are complete. The AD may beat up the chairs if we miss the dates, but
the priority is to get the document correct.
[Joel from the Chatbox] 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.)
Goals:
[Adrian] Quite a few deleted requirements. Thanks for flagging this
fact. I would particularly ask that authors who have been working on use
cases please look hard to make sure that there have been no requirements
deleted that their use case actually requires.
[Adrian] I find Figure 6 really helpful to my understanding of the
requirements. It is striking that all use cases need all requirements
except R19 and R20 which are hardly needed by the use cases. That
triggers me to ask us to think hard about whether these are really CATS
requirements. If they are, that's OK, but we should check.
[Julien via chat] I'm not clear about R14
[Kehan] MUST NOT be sensitive to the update frequency of the metrics,
and MUST NOT be dependent on or vulnerable to the mechnisms used to
distribute the metrics.
[Adrian] I will help with providing clearer words
[Carlos] Goal is to include some text from our draft to the Use Case
draft in CATS. An ETSI liasion can be sent to the IETF CATS WG.
[Adrian] Do you see some NEW requirements from your use case?
[Carlos] Now we only focus on the general reqs for ISAC, will review
again to see if we have some NEW CATS reqs, and share to the list.
[Adrian] The whole point is to catch the new requirements, instead of
only adding more use cases.
[Carlos] Fully agree with that.
[Adrian] So, please try to pull these out more clearly. Then it would
be really good for the ISAC people to review the framework and the
requirements and give us feedback.
[Julien] Why do you think this is related to CATS (pointing to Slide
3)
[Carlos] We need to transfer the data from multiple sensors to
receivers, need to consider more metrics to meet the time/latency
constrains of it. Time synchronization is required in this case, so
latency is import in this case.
[Julien] It may be done in the application level. Suggest to reprase a
bit, to make it clear.
[Dirk] If traffic steering is not the solution to your problem, why is
this a "CATS requirement"?
[Carlos] I think traffic steering is the solution. We need to handle
the traffic steering among multiple nodes, to guarantee the time
synchronization. So we believe this is a CATS related problem.
[Joel from Chatbox] Time of delivery sounds like soemthing outside of
the scope fo CATS. 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.
[Julien from Chatbox] Traffic steering, Latency sensitivity and
Scalability are exactly the motivations to use CATS, they are not new
requirements.
[Carlos] Time sync may not be the best use case to prove ISAC is a
CATS related use case. Will try to find better angles.
[Dirk] If you also believe time synchronization is not good enough,
suggest to delete it to avoid confusing.
[Greg] Second to Julien and Dirk. Time sync may not be appropriate to
prove this is a CATS use case.the requirements seem not so unique to
ISAC, and not so related to CATS. You might use other mechanisms to
guarantee the latency like IOAM, STAMP, etc.
[Carlos] It is a time critical problem.
[Greg] Then you need latency guarantee, not best effort.
[Adrian]We may need a longer time slot to discuss the use case, to
understand better. Also, you may need to update the draft, because we
see more info in the slides than your draft.
[Cheng] Happy to see the AI related use case, suggest the authors to
send an email to the mail list, so that more people can read and
discuss.
Who would like to see Usecases and Requirements published as an RFC
Present in Meetecho when poll closed: 54
Result:
[Jim as AD] Ok to see the document to be published as an informational
RFC as long as I see the strong consensus from the WG.
[Jim as AD] Regarding prioritizing the use cases, it might seem to
boil the ocean. We can prioritize the requirements instead of use cases.
Can find a minimal set of requirements? We could add more in the future.
[Med] Agree with that. So we can publish the draft as an informational
RFC later.
[Adrian] Even if we do not publish this as an informational RFC, we
will still ask for WGLC to get consensus on the requirements.
[Julien] Would like to know which requirements are more important, so
suggest to priorite the use cases and requirements.
[Erum Welling] How do you know we have a good set of the requirements?
[Adrian] Publication is not the end of this work. We may revise the
document when needed.
Goals:
[Cheng] Suggest to add the text of the three options of how to
implement the metric classification and aggregation in the document. But
only focus on the high level, do not need to describe the details,
because this document is about metric definition.
[Adrian] The metric classification and aggregation should be added
into the framework instead of the metric definition draft, because this
draft shoulf focus on the definition of metric only.
[Cheng] Happy to add this part into the framework draft.
[Julien] The document should add a problem statement, to explain why
we need to classify the metrics into three levels.
[Kehan] Luis has explained. In the beginning, I think 2 level is
enough, but in the end, we think 3 level may be better. But for a
vendor, they may invent more levels. Will add explaination text in the
draft.
[Adrian] The point is to explain this in the draft or the mailing
list.
[Dirk] Finding no reference to the requirements regarding the 3-level
metrics.
No time for discussion.
No time for discussion.