Thanks, Qin. Joe
From: Qin Wu <[email protected]> Date: Tuesday, January 13, 2026 at 02:26 To: Joe Clarke (jclarke) <[email protected]>, opsawg <[email protected]> Cc: Victor Lopez (Nokia) <[email protected]>, LUIS MIGUEL CONTRERAS MURILLO <[email protected]> Subject: RE: Feedback on draft-ietf-opsawg-scheduling-oam-tests-03 Hi, Joe: Sorry for late follow up. I have created 2 issue tickets to keep track of your comments, https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/issues/37 https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/issues/36 please see reply inline below. 发件人: Joe Clarke (jclarke) [mailto:[email protected]] 发送时间: 2025年11月4日 22:02 收件人: opsawg <[email protected]> 主题: [OPSAWG]Feedback on draft-ietf-opsawg-scheduling-oam-tests-03 I’ve read this latest version, and I think the mount approach makes sense. The RPC reasoning makes sense. I do have a couple questions that I raised yesterday at the mic. • What is the purpose of the “twamp” identity expending basic-test-type? Why define this one identity? Moreover, the examples use a value of “twamp-test”. My understanding is that these test types would be augmented in. But why have this at all if you’re going to mount the desired module for the test? [Qin Wu] I think the usage example in the appendix will use identity defined in this document, so twamp-test should be replaced with "twamp", thanks for catching this. I think we should also allow YANG models extended from ietf-oam-unitary-test can add more child identities which are derived from basic-test-type. Also adding a new test-type don't conflict with mount desired module, with new test-type, we can explicitly indicate which OAM-test module is augmented in, e.g., test-type can pair with each augmented YANG model as one entry under ne-config list, make sense? • In Section 6.1, you describe various types of error conditions (e.g., resource contention, prioritization, etc.), but the YANG module doesn’t convey the error specificity. Presenting an error-cause would be helpful. [Qin Wu] 1. As described in section 6.1, this draft leverages the scheduling status groupings defined in the common schedule YANG module to detect and report such conflicts. But in the current YANG model, use specific grouping defined in draft-ietf-netmod-schedule-yang to report status, I think we should choose one of "schedule-status", "schedule-status-with-time-zone", and "schedule-status-with-name" Groupings to report such conflicts. See proposed change as follows: https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/pull/45 https://github.com/vlopezalvarez/draft-contreras-opsawg-scheduling-oam-tests/pull/46 2. In addition, as described in section 6.1, we uses the unitary-test-status and test-sequence-status grouping to indicate the current scheduling state of each OAM task. one of state we are using is 'error', but it doesn't provide fine granularity indication for error-cause, in addition, the unitary-test-status and test-sequence-status grouping are defined as enumeration types, doesn't allow extension, therefore I think we should redefined the unitary-test-status and test-sequence-status grouping as identity type, in addition, we can indicate error cause using child identity. Joe Cisco Confidential
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
