[Tvr] Re: Review of FW: New Version Notification for draft-zdm-tvr-applicability-04.txt

["zhangli (CE)" <[e-mail]>]

Hi Dan,

Thanks a lot for the detailed review, your comments and suggestions are quite valuable, I will respond for anything not clear. 

I have other updates and will post as a new version soon. 

Do you have an opinion on the code examples we discuss in the draft? 

Best regards
Li
-----邮件原件-----
发件人: King, Daniel <[e-mail]> 
发送时间: 2026年1月21日 1:26
收件人: zhangli (CE) <[e-mail]>
抄送: Dongjie (Jimmy) <[e-mail]>; Mohamed Boucadair <[e-mail]>; tvr <[e-mail]>
主题: Review of [Tvr] FW: New Version Notification for draft-zdm-tvr-applicability-04.txt

Dear Li, Med and Jie,

Thanks for continuing to work on this document.

Please find a review of the latest (04) version of the draft.

Hopefully, my comments are straightforward to parse; if anything is unclear, please let me know.

#1 Abstract update.

Replace text "can support the predicted topology changes caused by internal or external reasons" with "can accommodate predicted topology changes caused by internal or external factors".

#2 Introduction YANG clarification.

You could also add one sentence: "The examples assume YANG instance data encoding as per RFC 7951 for JSON and the TVR schedule YANG modules."

#3 Introduction readability.

In Section 1, split the long sentence about "dynamic networks with mobile nodes …" and "highly predictable traffic patterns …" into two sentences (one for mobility, one for predictable/energy-saving scenarios).

#4 Terminology fix.

Replace "Yang" with "YANG" throughout (titles, headings, body text), including "Topology Yang Module" and "Node Yang Module".

#5 Typo fix.

Replace "schedule domian" with "schedule domain".

#6 Definitions addition.

In Section 2 (Conventions/Definitions), add explicit definitions for "managing device", "network controller", and "managed device", and you could also state whether "managing device" can be the controller.

#7 Section title update.

Replace "Applicability of TVR Yang Model" with "Applicability of the TVR YANG Model".

#8 Grammar fix (3.1).

Replace "or the devices themselves decisions" with "or by decisions made by the devices themselves".

#9 Grammar fix (3.1).

Replace "two nodes's distance" with "the distance between two nodes".

#10 Grammar fix (3.1).

Replace "the devices themselves does not know" with "the devices themselves do not know".

#11 Wording improvement (3.1).

Replace "the scheduled attributes changes" with "the scheduled attribute changes".

#12 Scenario clarity (3.2).

After introducing "Centralized" and "Distributed", it might be useful to add a short bullet list stating: who generates the schedules, who stores them, who executes them, where route computation runs, and where routing results are pushed.

#13 English fix (3.2).

Replace "In the meanwhile," with "Meanwhile,".

#14 Technical precision (3.2).

Replace the sentence about routing results being sent "in wall-clock time or … packed and sent at some special points" with a more concrete statement:
"Routing results MAY be delivered ahead of time and activated using an explicit time reference (e.g., absolute UTC), or via pre-staging plus an activation trigger."

#15 NMDA clarity (3.3).

It may be worth adding some text around which datastore(s) the examples target (intended/running vs. operational) and how "state" is retrieved.

#16 Example validity (3.3).

Need to fix the JSON example so it's valid: trailing commas, correct brackets/braces, and ensure strings are properly quoted.

#17 Field-name consistency (3.3).

Need to fix the consistency of "utc-start-time" and "start-time-utc", and make the chosen field name consistent across all examples.

#18 Schedule field consistency (Appendix).

#19 Duration unit clarity.

Maybe add a sentence stating the unit for `duration` (e.g., seconds), then ensure all example durations match that unit.

#20 English fix (3.4).

Replace "which is a complementary to RESTCONF" with "which is complementary to RESTCONF".

#21 English fix (3.4).

Replace "Contrary to RESTCONF, CORECONF many design decisions…" with "Unlike RESTCONF, many CORECONF design decisions are motivated by minimising message size."

#22 Typo fix (4).

Replace "dose not require" with "does not require".

#23 English fix (4).

Replace "guarded under seconds" with "kept within seconds" (or "maintained within seconds").

#24 Operational requirement (4).

Add guidance on deriving a maximum acceptable time-error bound from schedule granularity, execution jitter, and activation windows.

#25 English simplification (5).

Replace "may be diversified" with "may be created from multiple sources".

#26 Future-work statement (5).

Replace "These options will be discussed …" could close with a tighter statement indicating whether schedule distribution is out of scope or intended for future work.

#27 Capitalisation (6).

Replace "when distributing schedules…" with "When distributing schedules…".

#28 Grammar fix (6).

Replace "devices that receives" with "devices that receive".

#29 Robustness (6).

Replace "it must ignore it on receipt" with:

"it SHOULD reject the update with an appropriate error, or ignore it if the management interface does not support error reporting."

#30 Timing guidance (6).

Replace "should be earlier than the earliest start time" with "SHOULD be delivered at least X (operator-defined) time before the earliest start time".

#31 Clarify tone (6.2.2).

Replace "benefits … appear to be very small" with "Pre-computation MAY be used; operators should weigh compute cost versus reduced activation latency."

#32 Grammar fix (6). Replace "addition and deleting" with "addition and deletion".

#33 Typo fix (6). Replace "executer" with "executor".

#34 Error-handling English (6.4.1).

Replace "period-start bigger than period-end" with "period-start later than period-end".

#35 Error-handling target (6.4.1).

Replace "an error should be returned to the managed device" with "an error should be returned to the schedule originator (e.g., the managing device or management client)".

#36 Conflict policy (6.4.1).

Replace "all conflicting schedules should be discarded" with a safer policy: reject only the conflicting update (retain last-known-good), and require logging/audit.

#37 Update semantics (6.4.1).

After "same schedule ID means update", add explicit rules on replace vs merge, versioning/etag/last-modified, and whether partial updates are allowed.

#38 Grammar fix (7).

Replace "the redundancy time synchronization mechanisms" with "redundant time synchronisation mechanisms".

#39 Security wording (7).

Replace "identification authentication" with "peer authentication" (or maybe "entity authentication"?).

#40 Wrong word fix (7).

Replace "TLS … for the conservation" with "TLS is RECOMMENDED to provide confidentiality and integrity protection".

#41 Self-reference bug (7.3).

Replace "mitigated by the solutions mentioned in Section 7.3" with the correct earlier section that contains the mitigations (likely 7.1).

#42 Security addition (7).

Add an explicit paragraph on schedule tampering impact (traffic blackholing, costly reroutes, SLA degradation, targeted interception) and map mitigations to authentication, authorisation, audit logs, and rate limiting.

#43 Appendix preface.

At the start of Appendix A, you could mention "All examples are intended as RFC 7951 JSON instance data." assuming you plan to follow the encoding rules. :-D

#44 Appendix JSON validity.

Need to check examples as some appear to be invalid JSON, as above.

#45 Editorial tidy-up.

Replace "json codes" with "JSON examples", and replace "this documents Appendix" with "this document's Appendix".

BR, Dan.

-----Original Message-----
From: zhangli (CE) <zhangli344=[e-mail]>
Sent: 16 October 2025 09:18
To: tvr <[e-mail]>
Cc: Dongjie (Jimmy) <[e-mail]>; Mohamed Boucadair <[e-mail]>
Subject: [External] [Tvr] FW: New Version Notification for draft-zdm-tvr-applicability-04.txt

This email originated outside the University. Check before clicking links or attachments.

Hi All,

We just submitted a new version of draft-zdm-tvr-applicability.
In this version, we addressed the two comments collected in the last meeting.

Welcome for comments and suggestions.

Best regards
Li


-----邮件原件-----
发件人: [e-mail] <[e-mail]>
发送时间: 2025年10月16日 15:25
收件人: Dongjie (Jimmy) <[e-mail]>; zhangli (CE) <[e-mail]>; Mohamed Boucadair <[e-mail]>
主题: New Version Notification for draft-zdm-tvr-applicability-04.txt

A new version of Internet-Draft draft-zdm-tvr-applicability-04.txt has been successfully submitted by Li Zhang and posted to the IETF repository.

Name:     draft-zdm-tvr-applicability
Revision: 04
Title:    Applicability of TVR YANG Data Models
Date:     2025-10-16
Group:    Individual Submission
Pages:    37
URL:      https://www.ietf.org/archive/id/draft-zdm-tvr-applicability-04.txt
Status:   https://datatracker.ietf.org/doc/draft-zdm-tvr-applicability/
HTML:     https://www.ietf.org/archive/id/draft-zdm-tvr-applicability-04.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-zdm-tvr-applicability
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-zdm-tvr-applicability-04

Abstract:

   Time-Variant Routing (TVR) is a routing system that can support the
   predicted topology changes caused by internal or external reasons.
   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.



The IETF Secretariat


--
Tvr mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]