[Tvr] Re: draft-ietf-tvr-requirements-07 ietf last call Opsdir review

[Brian Sipos <[e-mail]>]

Bo,
Thank you for the review and feedback. I can provide my own responses to
your topics and will let the other authors give their thoughts before
getting into any editing. To track possible changes, I have added review
issues to the document repository [1] but will be discussing just on an
email thread for now.

To your questions:
1. This is an important topic when looking at these documents for the first
time. I think that while the Use Cases document explains the justification
for why there is value in having some form of time-variance in a system,
this Requirements document gets into more technical detail of aspects that
solutions could adopt and considerations for when (or when not) to need to
incorporate each of these aspects in a system design. The relationship
should be explained more explicitly, probably somewhere in the introduction.

2. The line marked "data model" in Figure 1 is meant to indicate the
concrete model used by the associated "management protocol" (which is a
label missing from the diagram). So when the management protocol is
NETCONF/RESTCONF the data model truly is the collection of YANG modules
that apply to that managed Agent. To make understanding this easier, I
think there is value in giving informative references to an example case of
using NETCONF protocol with YANG modules. This will also show a distinction
that the "intrinsic schedule" needs modules augmented to contain entities
with schedules, while the "extrinsic schedule" keeps all schedule activity
on the Manager side.

3. Thank you for checking the consistency of terms, because there is liable
to be some confusion as parts of the document have evolved. I think the
term "TVR information model" in Section 2.2 can be substituted by
"time-variant data model" or "scheduled data model" to be consistent with
other sections and avoid the term "information model" entirely. The uses in
Section 2.2.1 should more explicitly say "data model" to be consistent.
The point of specifically identifying a "network model" in Section 2.3 is
to relate to entities from RFC 8345 and explain how schedules can be
applied to a topology model specifically. Since "TVR" is really focused on
the routing aspect, relating schedules to entities in a network model used
for routing is meant to give concrete grounding of "where would you
actually put a schedule in a data model?"

4. I agree that Section 4 could use more terminology from Section 3 to make
the relations more explicit (or at least easier to search within the
document). I don't have any specific updates to propose here, just a scrub
of Section 4 text.

5. There already are some explanations for environments where different
"domains" consider time-variance differently, but there could be additional
operational consideration about how the boundaries of those domains could
change over time to start with small TVR and expand over time, or to evolve
from extrinsic schedule to intrinsic schedule with more fine control over
entities' schedules. I don't have specific proposals here, but could
discuss in the context of edits to the section (i.e. in a PR).

6. This is helpful feedback, an outline of the Section 2 material would be
helpful. Some explanation about Section 2.1 being "what is a schedule?",
2.2 being "what goes into a schedule?", and 2.3 being "where do schedules
belong in the data model?", and 2.4 being "what complex behaviors do
intrinsic schedules enable?", and 2.5 (along with 5.) being "what
vulnerabilities do schedules enable?" if all of those seem like good
outline explanations.

Any more thoughts for these topics are appreciated,
Brian S.

[1] https://github.com/danielkinguk/tvr-requirements/issues

On Tue, Feb 10, 2026 at 10:31 PM Bo Wu via Datatracker <[e-mail]>
wrote:

> Document: draft-ietf-tvr-requirements
> Title: TVR (Time-Variant Routing) Requirements
> Reviewer: Bo Wu
> Review result: Clarification Needed
>
> 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
>
>
>
>