IETF Last Call Review of draft-ietf-tvr-requirements-07
review-ietf-tvr-requirements-07-opsdir-lc-wu-2026-02-10-00

Dear Authors,

Thank you for your work on this requirements document for Time-Variant Routing.

As an OPS area reviewer, I have reviewed the draft and would appreciate your
clarification on some points I see.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

This informational draft defines and categorizes design requirements for
Time-Variant Routing (TVR) systems to guide implementations and facilitate
operator understanding.

- Has Issues: I have some minor concerns about this document that I think
should be resolved before publication.

This document comprehensively identifies and structures the key operational
paradigm shift introduced by TVR: managing pre-planned, non-disruptive network
variation versus reacting to faults. It effectively addresses core operational
concerns like time synchronization, schedule distribution, and domain
coordination. However, the relationship to RFC 9657 is not clear, and the use
of "Information Model" (Section 2.2), "Data Model" (Figure 1), and "Network
Model" (Section 2.3) interchangeably without establishing their relationships.

Here are some questions:

1. Document Scope and Relationship to RFC 9657

  The Abstract and Introduction provide definitions of TVR and scenario
  descriptions that appear similar to content in RFC 9657. Could you help me
  understand:
- How would you characterize the relationship between this document and RFC
9657 for readers who may not be familiar with the use cases document? - Would
it be helpful to include an explicit statement clarifying whether this document
extends, or operates independently from the use cases described in RFC 9657?

2.Figure 1 and Management Architecture

Figure 1 presents a "Data Model" between Manager and Agent components. I want
to make sure I understand your intent correctly: Could you clarify what you
envision this "Data Model" represents? For example, are you referring to a YANG
data model, an abstract information model, or something else? Would it be
appropriate to reference established management protocols such as NETCONF,
RESTCONF, or gNMI to provide context for the Manager-Agent interaction shown?
How does this "Data Model" relate to the "Information Model" discussed in
Section 2.2? Could you clarify whether the "Data Model" shown in Figure 1 is
intended to correspond to the YANG modules defined in
[I-D.ietf-tvr-schedule-yang], or does it represent a more abstract concept? If
there is a relationship, would an informative reference or mapping be helpful
to readers?

3.Terminology Consistency

I noticed the document uses several related terms across different sections,
and I want to ensure I am interpreting them correctly: Section 2.2 refers to an
"information model," Figure 1 shows a "data model," and Section 2.3 discusses a
"network model." Could you help me understand how these three models relate to
each other in your architecture? When Section 2.2.1 mentions "model," which of
these are you referring to?

4.Structure and Requirements Derivation

Section 2 provides extensive technical discussion of architectural concepts,
temporal dimensions, and topology mappings. As I read through Section 4, I
found myself wondering: How do the architectural concepts in Section 2.1 (such
as Schedule Domains, Generation Locality, and Execution Locality) map to the
requirements in Section 4? Would readers benefit from explicit requirements
derived from the temporal dimensions discussed in Section 2.2, such as Time
Horizon, Periodicity, or Continuity?

5.Deployment and Migration Considerations

I noticed that the requirements in Chapter 4 (Sections 4.1-4.6) appear to focus
primarily on operational behaviors. Given TVR's potential impact on existing
infrastructure, I would appreciate your thoughts on: Whether
deployment-oriented requirements would be valuable—for example, is TVR intended
for greenfield deployments, brownfield environments, or both? Are there
considerations for migration from non-TVR to TVR-enabled operation, or for
coexistence during transition periods?

6.Section 2 overall Flow

I am trying to understand the logical progression through Section 2:
How do the architectural options in Section 2.1, the temporal concepts in
Section 2.2, and the topology mappings in Section 2.3 fit together in your
view? Would a brief overview at the beginning of Section 2 help readers follow
the relationships between these subsections?

Thank you for considering these questions.

Best regards,
Bo