[Int-dir] Re: draft-ietf-tvr-requirements-08 telechat Intdir review

["King, Daniel" <[e-mail]>]

Hi Darren,

Many thanks for your INT-DIR review of draft-ietf-tvr-requirements-08, and for your kind assessment of the document's structure.

We have addressed the following:

Typographical corrections (all fixed)
References/Acronym Expansions (all fixed)
Grammar and structure (all fixed)
Now things become a little more complicated to address.

A few further observations and details:

1. Normative language

This was a deliberate choice. The document used BCP 14 boilerplate and uppercase keywords in its early revisions (-00 and -01), and these were intentionally removed in -02 following working group discussion, because the strength of individual requirements can legitimately differ across deployment scenarios and use cases. We then started using lowercase "must" and "should" in a "plain English" sense.

All that said, and to make our thinking clearer, we have revised the introduction of Section 4 to state that not every architectural option or property described in the document results in a hard requirement; rather, those aspects inform the requirements that TVR systems need to support when they are applicable to a deployment or use case.

2. Node/link state propagation (Section 2.3)

We have revised the Nodes and Termination Points subsections to make the propagation logic explicit: when a schedule indicates that a node or termination point is not valid, the model itself defines whether that condition affects the validity or usability of associated termination points or links, with an example noting that the power state of a node can affect the operational state of all of its interfaces whilst other node properties remain independent of link state.

3. Additional Figures

Finally, we do appreciate the suggestion for additional diagrams to help the reader, we did consider this, but felt that further figures risked implying a particular solution architecture in what is intentionally a solution-neutral requirements document. We hope the two scheduling figures in Section 2.1.4 provide sufficient visual grounding.

Obviously, open to further discussion if you feel strongly on the last few comments.

Best regards,

-----Original Message-----
From: Darren Dukes via Datatracker <[e-mail]> 
Sent: 12 April 2026 23:54
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [Int-dir] draft-ietf-tvr-requirements-08 telechat Intdir review

Document: draft-ietf-tvr-requirements
Title: Time-Variant Routing (TVR) Requirements
Reviewer: Darren Dukes
Review result: Ready with Nits

## Overall Observations
The document is  well structured and comprehensive, and the writing was clear and precise. It provided me a good foundation for understanding the concepts of TVR and the requirements for the design and implementation of systems which perform TVR and their different aspects.

It's worth noting I did not find any major issues, but I did find myself wanting more diagrams to visualize the topic, this is a personal preference to aid and verify my understanding of the text and my be considered. The remainder of this review is focused on minor edits and suggestions for improvmement that don't materially change the document but may help implementers.

## Typo's and minor edits

Section 1.1 s/goverened/governed/ (typo) Section 2.2 s/invarient/invariant/ (typo) Section 2.2.1 s/This is the temporality model of [AIXM]./This is the temporality model of Aeronautical Information Exchange Model [AIXM]./ (missing acronym expansion) Section 2.4.2 s/may distributed/may be distributed/ (typo) Section 2.5 s/Specific security considerations are discussed in the Section 6.
later in this document./Specific security considerations are discussed in Section 6 later in this document./ (extra the) Section 3.1 s/phenomina/phenomena/ (typo) Section 4.3 s/as described in 3.1/as described in Section 3.1/ (missing link and "Section") Section 6.5 s/Replay Attacks on Time-Sensitive Data: Time variant network data.../Time-variant network data.../ (title replay and hyphenation) Section 6.6 s/Compromised Time Sources: The reliance on.../The reliance on.../ (title replay)

## Inconsistencies in normative language Use of should or must is present in this informational document, which is understandable in the requirements section. But when should is used the document provides no clear consequence for non-compliance. Some examples:
section 3.2 (what happens if management entities cannot provide updates as fast as needed), 4.1 (what happens if a manager does not provide an advertisement methodology for responding to abnormal changes).

## State propagation
Section 2.3 Topologies - There's some ambiguity/inconsistency with respect to state propagation from nodes links and TPs. The text says "may define an interpolation method" for nodes and TPs "should define an interpolation method"
for links It wasn't obvious to me why a node state impacts a link state since "Nodes also contain termination points that anchor the links."  but in my experience links are independent of the node or TP state.