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