[Tvr] Re: Call for adoption and IPR: draft-zdm-tvr-applicability-05 (Ends 2026-05-09)

[Jing Wang <[e-mail]>]

Hi Li,

Thank you for your prompt reply and thoughtful feedback on the suggestions I shared. ‌‌I sincerely appreciate that you have accepted most of the recommendations.

Please see my reply inline with <Jing>.

Best regards
Jing

From: zhangli (CE)
Date: 2026-05-11 16:54
To: Jing Wang
CC: \tvr\""; [e-mail]
Subject: [Tvr] Re: Call for adoption and IPR: draft-zdm-tvr-applicability-05 (Ends 2026-05-09)
Hi Jing,
 
Thanks a lot for your kind and careful review, it provides great value for improving the quality of this document. 
 
Please see my response inline with <Li>.
 
Best regards
Li
 
发件人: Jing Wang <[e-mail]> 
发送时间: 2026年5月10日 17:58
收件人: "Tony Li" <[e-mail]>; "tvr" <[e-mail]>; [e-mail]; [e-mail]
主题: Re: [Tvr] Call for adoption and IPR: draft-zdm-tvr-applicability-05 (Ends 2026-05-09)
 
Hi all,
 
I have reviewed the latest version of the draft and believe it will be very useful for the promotion of TVR. I support adopting this document.
 
Here is my review. I provided a full review and update of the operational considerations and schedule Operations section.  If have any comments, let me know.
 
My edits are below:
 
1. Introduction: 1st paragraph, replace "The Time-Variant Routing (TVR) Working Group addresses a need in network environments where predictable variations in topology of" with "The Time-Variant Routing (TVR) Working Group addresses the need for network environments that experience predictable variations in topology".
 
<Li> good.
 
2. Introduction: 2nd paragraph, replace "provides " with "presents".
 
 <Li> why? I think “provides examples” is more general than “presents examples”. Could you please give more explanation?
 
3. Applicability of TVR Node YANG Module: 2nd paragraph, "When the changes are caused by the environment changes (such as movement, sunlight changes, and weather changes) or by decisions made by the devices themselves". I'm not sure if this covers situations where the device itself malfunctions. Perhaps changing it to “When the changes are caused by the environment changes (such as movement, sunlight changes, and weather changes) or by decisions made by the devices themselves(For example, a device’s state changes proactively in accordance with preset operating rules—such as entering sleep mode when power is low—or reactively when the device encounters a system failure.)” would make it clearer.
 
<Li> good.
 
4. Applicability of TVR Topology YANG Module: 2st paragraph, replace "the scheduling generation locality and execution locality may be centralized or distributed" with "the scheduling generation and execution locality may be either centralized or distributed".
 
<Li> good.
 
5. Applicability of TVR Topology YANG Module: 4th paragraph, replace "When the schedules are generated and executed in centralized manner and within the same device, the topology YANG module is also not applicable" with "When schedules are generated and executed in a centralized manner within the same device, the topology YANG module is not applicable".
 
<Li> good.
 
6. Applicability of TVR Topology YANG Module: 5th paragraph, replace "in centralized manner" with "in a centralized manner".
 
<Li> good.
 
7. Applicability of TVR Topology YANG Module:7th paragraph, replace "Route computation runs in the controller" with "The route computation process takes place in the controller".
 
<Li> good.
 
8. Encoding of the YANG Model: 4th paragraph, replace "More detailed examples of the JSON example is provided in this documents Appendix." with "More detailed examples of the JSON example are provided in this documents Appendix.".
 
<Li> good.
 
9. Management Protocols for TVR: 4th paragraph, replace "CORECONF uses CoAP[RFC7252] methods to access structured data defined in YANG which is a complementary to RESTCONF" with "CORECONF uses CoAP[RFC7252] methods to access structured data defined in YANG,  which is a complementary to RESTCONF"
 
<Li> good.
 
10. Time Synchronization: 2nd paragraph, replace “may moving” with “may move”.
 
<Li> good.
 
11. Time Synchronization: 4th paragraph, replace “includes but not limited to” with “includes but is not limited to”.
 
<Li> good.
 
12. Hardware-based Time Synchronization Mechanisms: 2nd paragraph, replace “reviver hardware” with “receiver hardware”.
 
<Li>good.
 
13. Data Structure:3rd paragraph, replace "reference to the definitions" with "reference the definitions".
 
<Li> good.
 
14. Schedule Operations: 3rd paragraph, replace "should be failed" with "should fail".
 
<Li> good.
 
15. Schedule Operations: The description feels a bit too brief; adding more detail would make it easier to understand. I’ve updated the supplementary section below. You may use it as a reference.
 
<Li> good, I will add it to the draft.
 
16. Operational Considerations: 6th paragraph, replace "Since the all the schedules" with "Since all schedules".
 
<Li> good.
 
17. Operational Considerations:Lack of operational early warning mechanisms.  I’ve updated the supplementary section below. You may use it as a reference.
 
 
18. Denial-of-Service (DoS) Attack: 2nd paragraph, replace "whether the time signals from different sources or protocols" with " cross-checking time signals obtained from different sources or protocols".
 
<Li> good.
 
The following updates and additions pertain to schedule Operations and operational considerations：
 
Schedule Operations:
As the core support for the operation of TVR schedules, the schedule database should be equipped with comprehensive operational capabilities. It should support the addition, update, and deletion of schedule operations, ensuring that schedule data can be adjusted promptly in accordance with actual requirements so as to meet the demands of dynamic scheduling scenarios.
 
When conducting operations to add or update schedule entries, the relevant execution nodes should strictly fulfill their verification obligations. They should comprehensively compare the schedule to be entered with the existing schedule information stored in the database, with a focus on identifying conflicts in key dimensions. If a schedule conflict is detected, the addition or update operation should be terminated immediately with a failure notification to avoid scheduling chaos, and the operation should not be re-executed until the conflict is properly resolved.
 
Furthermore, both the update and deletion of schedules rely on the schedule IDs as the unique identifier; therefore, the schedule IDs should remain absolutely unique within the time-variant domain. This is a critical prerequisite for ensuring the accuracy of scheduling operations. To meet this requirement, ID management can be implemented through a dedicated allocation agent within the time-variant domain. This agent is responsible for the allocation, validation, and maintenance of IDs, thereby preventing ID duplication at the source and ensuring the orderly progress of all schedule. 
 
Operational Considerations：
6.5 Early Warning Mechanism
When the schedule received by a device exhibits significant short-term discrepancies, the device should send feedback to the the schedule originator to determine whether the problem arises from a system failure or operator error. Upon receiving the feedback, the the schedule originator should inspect logs to confirm whether a fault has occurred. If no fault is found, the the schedule originator should notify the user that the schedule is valid. If a fault is confirmed, the the schedule originator should distribute a corrected  schedule to all time-variant nodes within its management scope.
 
<Li> I did not get the meaning of “short-term discrepancies”? how do a managed device detect this?  Could you please give more explanation?

<Jing> The “short-term discrepancies” mentioned here could refer to changes in parameter values within the schedule. The supplement described above is a scenario of early warning feedback initiated proactively by the device. There is also another scenario in which the schedule originator can analyze and issue early warnings based on historically stored schedules.
 
Best regards
Jing Wang
 
From: Tony Li via Datatracker
Date: 2026-04-26 00:36
To: [e-mail]; [e-mail]; [e-mail]
Subject: [Tvr] Call for adoption and IPR: draft-zdm-tvr-applicability-05 (Ends 2026-05-09)
This message starts a tvr WG Call for Adoption and IPR of:
draft-zdm-tvr-applicability-05
 
This Working Group Call for Adoption and IPR ends on 2026-05-09
 
Abstract:
   Time-Variant Routing (TVR) is a routing system that can accommodate
   predicted topology changes caused by internal or external factors.
   Typical use cases include resource preservation networks, operating
   efficiency networks and dynamic reachability networks.  This document
   provides examples of how to implement the TVR scheduling capabilities
   for key use cases.  It describes which part of the TVR data model is
   used and why, and it outlines operational and security considerations
   when deploying TVR-based technologies.
 
Please reply to this message and indicate whether or not you support adoption
of this Internet-Draft by the tvr WG. Comments to explain your preference are
greatly appreciated. Please reply to all recipients of this message and
include this message in your response.
 
Authors, and WG participants in general, are reminded of the Intellectual
Property Rights (IPR) disclosure obligations described in BCP 79 [2].
Appropriate IPR disclosures required for full conformance with the provisions
of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be
found at [3].
 
Authors and contributors MUST reply to this message with either:
 
"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"
 
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?
 
If yes to the above, please state either:
 
"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"
 
If you answer no, please provide any additional details you think
appropriate. If you are listed as a document author or contributor
please answer the above by responding to this email regardless of 
whether or not you are aware of any relevant IPR. This document will not 
advance to the next stage until a response has been received from each 
author.
 
Thank you.
[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/
 
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-zdm-tvr-applicability/
 
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-zdm-tvr-applicability-05.html
 
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-zdm-tvr-applicability-05