Time-Variant Routing (TVR) Requirements
draft-ietf-tvr-requirements-11

[Ballot comment]

Thank you for the TSV-ART review by Mirja Kühlewind, and the issues raised in that review.

Minor: Section 1:
/This document is an informational specification meant to inform .../ -- is it better to state:
/This document was written to inform.../

Minor:
/orchestrator/ - ought this to be /Orchestrator/

Minor:
Why does an International document discuss GPS, whilst coordinated Universal Time (UTC) is a primary time standard?

Minor:
Is a "MAC address" sufficient in Layer 2? - Does this document need to consider a wider set, i.e. EUI-48, or EUI-64?

Thank you for addressing my discussion topics in draft-ietf-tvr-requirements-10.

Gorry

[Ballot comment]
Thanks for the work done in this document and some changes done in -10. I still believe that the requirements are not crisp and look more like considerations, this is still not reflected correctly, hence my ABSTAIN as I do not want to prevent publication (as the TVR WG has consensus on it).

Previous DISCUSS at: https://mailarchive.ietf.org/arch/msg/iesg/dWp2MAZafov9D2lgYv3IWSjgEhw/

[Ballot comment]
I support the positions of Éric Vyncke and Gorry Fairhurst on clarifying text around the requirements.

Thank you for addressing my DISCUSS and COMMENT feedback.

[Ballot comment]
Overall, the document is well written and extensively covers issues relating to the terminology and considerations of building a time-variant routing network.  I will support many of the other AD’s comments in that for as extensive as a document as this is, it is relatively thin on the requirements for implementing a TVR network.  The draft is more “TVR Concerns, Consideratons, Terminology, and Requirements”.

### Comments

* The link in this reference is broken:
> EUROCONTROL and Federal Aviation Administration, "AIXM 5 Temporality Model", 15 September 2010, <~[https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_temporality_1.0.pdf](https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_temporality_1.0.pdf)~>.

* This possibility seems like in a time-variant resource constrained system that it could cause extreme complexity and challenges to realize, but there is no menton of that.  It’s also not clear if this applies to store-and-forward type queueing for the routing model or the scheduling of resources for nodes.  For example, if one if communicating with an overhead resource (statellite, drone, heliostat, etc.) using free space optics maybe, then shining multiple lasers at its receiver is likely not to be resolved easily.  But a system using something more akin to cellular with a control channel and OFDM schedulable data channels can much more easily make use of priority decisions and reallocate communication bandwidth.  If this refers to queueing, then the implicatons on queue depth, slow sender, and drops should be considered.  Should this be covered?
> 675 2.2.8.  Time-Overlap and Priority
>
> 677   In an ideal situation a model would be guaranteed by design to
> 678   contain only contiguous and non-overlapping schedules for each time-
> 679   variant scope.  In a realized model this kind of invariant might not
> 680   be enforceable or might lead to overly complex schedule structures.
> 681   One way a model can handle this is to establish a concept of schedule
> 682   priority, where some intervals of the schedule timeline contain
> 683   overlapping schedules for the same properties and only the highest-
> 684   priority schedule applies.  When priorities are allowed by a model,
> 685   it enables the concept of an "overlay" where a long-duration state
> 686   can be temporarily (in schedule time) superseded by a short-duration
> 687   state.

[Ballot comment]
-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1.1, paragraph 3
>  true timeline, measured in some time scale by some local ticker. The notion
>                                  ^^^^^^^^^^
This word is normally spelled as one. [EN_COMPOUNDS_TIME_SCALE]

Section 2.2.2, paragraph 2
> eed to model repetitive states in a concise way. One way to model a periodic
>                                ^^^^^^^^^^^^^^^^
Consider replacing this phrase with the adverb "concisely" to avoid wordiness.
[IN_A_X_MANNER]

Section 2.2.9, paragraph 1
> s, relating schedules to entities in an network model used for routing is me
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university". [EN_A_VS_AN]

Section 2.3.3, paragraph 3
> ents, scheduling information may distributed through a management plane mecha
>                                  ^^^^^^^^^^^
The modal verb "may" requires the verb's base form. [MD_BASEFORM]

Section 5, paragraph 1
> exity, make schedule scope more fine grained, or expand time horizons as dev
>                                ^^^^^^^^^^^^
This word is normally spelled with a hyphen. [EN_COMPOUNDS_FINE_GRAINED]

[Ballot discuss]
** Section 4.2. 
4.2.  Support Proxy Advertisement

  Proxies can help to improve the efficiency of the network.  There are
  some entities in the network that do not have routing functions.
  When their properties change, they are unable to notify other
  entities in the network.  Proxy nodes can help nodes without routing
  functions to advertise information, thus improving the efficiency of
  the network.  Therefore,

  Systems must support proxy entities to help non-routing nodes
  implement information advertisement.

-- What is a proxy in this context? 
-- What does it mean to “support proxy entities”?

[Ballot comment]
I support the positions of Éric Vyncke and Gorry Fairhurst on clarifying text around the requirements.

** Are the requirements in Section 4, as the name would imply, a “Requirements Summary”, of those in Section 3?  There are various clauses in Section 3 which talk about “should” which don’t appear to me to cleanly align with the Section 4 text.

** Section 4.5

4.5.  Support Appropriate Time Accuracy
  The accuracy of the time cannot be too large or too small; otherwise,
  convergence may not be possible.  Therefore,

  Systems must support appropriate time tolerance.

With no definition or framing of “appropriate”, isn’t any time tolerance acceptable?  It isn’t clear how this text establishes a requirement.

[Ballot discuss]
I have many comments and curioisitis about this document, and would like to DISCUSS the strengths of the recommendations, since the WG has requested publication in the RFC-Series.

1) I see the Charter text calls for: "Requirements: This document should include definitions, requirements, notes, rationales, and examples." - However, the supplied document is mainly descriptive at present. Sections 2 and 3 describe broad use cases, but section 4 does not currently derive strong requirements; such as a numbered set of precisely defined requirements. So, is/could the document provide formal requirements using RFC2119 language in section 4 to clearly indicate what is needed.

Here are some specific questions to discuss on the specific 'requirements" below:

2)
/  A Manager should provide an advertisement methodology for responding
  to abnormal changes in the system./
-- It was not clear to me what was needed here, or what the exepected response included - is it enough to log, might this imply alerting or taking action?

3) Recommended, optional or needed?
/  Systems must support proxy entities to help non-routing nodes
  implement information advertisement./
- this is specified as a "should", but the text above suggests this is optional. Please clarify the position.

4) What would be compliant?
/  Systems must support system schedule changes.
  Systems must support time interval changes./
- What does the requirement imply as a constraint on the solution space? How often is this needed? Is rollback needed in event of a fault, and how is this authenticated?
and
/  Systems must support appropriate time tolerance./
- This is a "must" - but what is actually required for a design to be conformant, and how will this  be specified?... this seems a difficult conformance requiremenrt, please indicate how it will be achieved?

5)
/  Resilience Against Malicious or Erroneous Inputs:  A TVR network must
      be resilient against the injection of incorrect or maliciously
      crafted scheduling information./
- How?
and
/TVR implementations should
      include fallback mechanisms to maintain network stability./
- Why is this not a requirement (MUST?)

6)
There are also presumably requirements for data integrity and timely delivery of information - ought these also to be called out in the list of requirements (even if the chosen way to mittigate these is to use strong security mechanisms)?

Best wishes,
Gorry (WIT AD)

[Ballot comment]

Thank you for the TSV-ART review by Mirja Kühlewind, and the issues raised in that review.

Minor: Section 1:
/This document is an informational specification meant to inform .../ -- is it better to state:
/This document was written to inform.../

Minor:
/orchestrator/ - ought this to be /Orchestrator/

Minor:
Why does an International document discuss GPS, whilst coordinated Universal Time (UTC) is a primary time standard?

Minor:
Is a "MAC address" sufficient in Layer 2? - Does this document need to consider a wider set, i.e. EUI-48, or EUI-64?

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-tvr-requirements-08
CC @evyncke

Thank you for the work put into this document.

Please find below blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Ed Birrane for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Darren Dukes, the Internet directorate reviewer (at my request), please consider this recent int-dir review:
https://datatracker.ietf.org/doc/review-ietf-tvr-requirements-08-intdir-telechat-dukes-2026-04-12/ (I hope that authors will engage with Darren)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Requirements or considerations ?

Most of the document is about considerations, only the very short section 4 is about actual requirements. Should the title and abstract better fit the actual content ?

Moreover, the section 4 contains two subsections with "should" and not "must":

- section 4.1: `A Manager should provide an advertisement methodology`
- section 4.6: `The following security-related requirements should be considered`

Has the WG considered categorizing requirements by priority ?

### Time accuracy

Should the document require a specific format & accuracy for time ? (e.g., UTC to the msec)

[Ballot comment]

## COMMENTS (non-blocking)

### Predictability in real life

What happens when reality deviates from the predicted schedule? Is there a requirement for a fallback mechanism ? (I may have failed to spot the text though)

### Section 1

`This document is an *informational specification*` seems like an oxymoron to me.

### Section 2.1

You may consider s/unmanned aerial vehicles/*uncrewed* aerial vehicles/

### Section 2.1.4

Why does an IETF document mention a specific service from USA (`GPS time`) rather than the global GNSS (Global Navigation Satellite System) term ? The IETF is a global organisation.

Not to mention that I am unsure whether GNSS time is accurate outside of the Earth surface and some TVR use case are not on the Earth surface.

Moreover, the last sentence of the section 6.1 (security considerations) is only about NTP and not GNSS. Suggest to be consistent.

### Section 6.2

In the security section, nothing is said that if the schedule is divulgated for some operators (e.g., military) then this could disclosed critical plans or for a normal SP information about business.

### Acknowledgements

Suggest removing `This work has benefited from the participation of the TVR working group and the discussions on the mailing list.` as it is a WG document anyway.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
Hi Dan, Luis, Brian, and Li,

Thank you for the effort put in this document.

Thanks also to Bo Wu for the excellent OPSDIR review and the authors for engaging and implementing changes in -08.

The document reads well. I have few comments:

# How these requirements are expected to inform the solution space? For example, how these requirements are used to derive the work in draft-ietf-tvr-schedule-yang?

# Abstract

## It is about forwarding paths

OLD:    Time-Variant Routing (TVR) refers to calculating a path ..

NEW:    Time-Variant Routing (TVR) refers to calculating a forwarding path …

## Subpaths

I’m not sure I would mention paths and subpaths as that is too subtle for an abstract. More importantly, the notion of path and subpath is not defined, while it should be if this is important.

# TVR System

Please add a definition of what is meant by that concept.

# On devices, data model, internal decompositions

CURRENT:
        +--------------------+            +-------------------+
        |  Managing Device  |            |  Managed Device  |
        |                    |            |                  |
        |  +--------------+  |            |  +-------------+  |
        |  | Orchestrator |  |            |  | Application |  |
        |  +--------------+  |            |  +-------------+  |
        |        |          |  Management |        |        |
        |  +--------------+  |  Protocol  |  +-------------+  |
        |  |    Manager  |  |------+------|  |    Agent  |  |
        |  +--------------+  |      :      |  +-------------+  |
        +--------------------+      :      +-------------------+
                                    :
                              +-------------+
                              |  Data Model |
                              +-------------+

## I suggest s/Managing Device/Managing Entity and s/Managed Device/Managed Entity as the current architecture is restrictive and may not cover deployment when such entities are virtual instances that co-exist with other instances.

## Why the orchestrator and manager are enclosed in the same entity? Why isn’t allowed from an operational standpoint to have those separated?

## Idem, what is there one single application that interacts with an Agent?

## There might be several data models invoked on the management interface. The current arch is restrictive.

# Samples

CURRENT:
  However,
  there are a growing number of use cases where changes to the routing
  topology are an expected part of network operations. 

Can we please provide examples of these “growing number of use cases”?

# Terminology

Maybe add: route, path, and Termination Points entries.

# Unmanned vs. Uncrewed

Maybe better to use

OLD: such as unmanned aerial vehicles

NEW: such as uncrewed aerial vehicles

# Green computing vs energy efficiency

CURRENT:
  prioritising green computing and energy efficiency over data rate.

What is referred to concretely here by “green computing”? Do we target more than “energy efficiency”? If not, consider deleting “green computing”.

If maintained, please consider adding a reference of “green computing”.

# For this figure and similar, indicate in the narrative text that this assume that no scheduling conflicts, execution errors are encountered.

CURRENT:
                Schedule        Schedule          Config
                Generation      Execution      Distribution
                    |              |              |
          --inputs-->|              |              |--config-->
          --inputs-->|---schedule--->|---snapshot--->|--config-->
          --inputs-->|              |              |--config-->

          <----------------------------------------------------->
          Information                              Configuration
          Sources                                      Consumers

        Figure 2: Centralized Generation with Centralized Execution

# Periodic vs recurrent

CURRENT:
  One way to model a periodic change of state is to

This statement and similar may suggest that the document assumes some regularity, while recurrence may happen without that regularity. Some of the authors are familiar with the modeling concepts in RFC9922.

Maybe clarify the intent in the document.

# What is the point of this sentence?

CURRENT:
      The predicted topology-change information may
      change due to forecasted or unforecasted changes. 

# Condider labelling the requirements for ease of reference within or outside this document. For example:

OLD:
  An entity must support the identification and advertisement of non-
  scheduled property changes.

NEW:
  REQ_NON_SCH_CHANGE: An entity must support the identification and advertisement of non-
  scheduled property changes.

# I don’t parse what this requirement is about

CURRENT:
  A Manager should provide an advertisement methodology for responding
  to abnormal changes in the system.

Can we please clarify?

# Idem, what is meant concretely here?

CURRENT:
  Systems must support appropriate time tolerance.

# Section 4.6.  Support Robust Security

How this unique to TVR? Shouldn’t this be applicable to any routing information schemes?

# New guidance

OLD:
  This section discusses considerations for those
  areas in the spirit of [RFC5706] but without concrete details of a
  specific TVR system design.

NEW:
This section discusses considerations for those
  areas in the spirit of [I-D. ietf-opsawg-rfc5706bis] but without concrete details of a
  specific TVR system design.

# I have “The requested page could not be found.” when accessing this file:

CURRENT:
  [AIXM]    EUROCONTROL and Federal Aviation Administration, "AIXM 5
              Temporality Model", 15 September 2010,
              .

Cheers,
Med

Request for IETF Last Call review by OPSDIR Completed: Clarification Needed. Reviewer: Bo Wu. Sent review to list. Submission of review completed at an earlier date.

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-02-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tvr-requirements@ietf.org, edward.birrane@jhuapl.edu, gunter@vandevelde.cc, tvr-chairs@ietf.org, tvr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (TVR (Time-Variant Routing) Requirements) to Informational RFC


The IESG has received a request from the Time-Variant Routing WG (tvr) to
consider the following document: - 'TVR (Time-Variant Routing) Requirements'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-02-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Time-Variant Routing (TVR) refers to calculating a path or subpath
  through a network where the time of message transmission (or receipt)
  is part of the overall route computation.  This means that, all
  things being equal, a TVR computation might produce different results
  depending on the time that the computation is performed without other
  detectable changes to the network topology or other cost functions
  associated with the route.

  This document introduces requirements where TVR computations could
  improve message exchange in a network.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/



No IPR declarations have been submitted directly on this I-D.

Document Shepherd Writeup for Time-Variant Routing Requirements
Ed Birrane
30 November 2025


# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?
---
WG consensus represents broad agreement within the TVRWG. This document was presented at each TVRWG meeting and there were multiple discussions on the mailing list involving at least one dozen working group members. A github set up for the document recorded 29 issues all of which have been satisfactorily resolved.

A TVRWG last call completed successfully in August, 2025. Since then, two sections of the document were added to address comments/issues from that WGLC.  A new WGLC is in place until mid-December based on those changes.

This writeup will be updated following the most recent WGLC for this document to capture any change to the above description of concurrence.


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
---
There were some discussions around common terminology, security considerations, and potential requirements on timing resolution. In each case, the discussion was informative and converged on a common answer. None of the consensus was particularly rough.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)
---
There is no known discontent related to this document.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?
---
This is not a protocol document.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
---
This is an informational document capturing requirements specific to time-variant routing.

No formal external review of this requirements document was requested and such review was not considered necessary. External entities and interested parties participated in the review of this document through their participation in the TVRWG.

External formal reviews of TVR documents informed by this requirements document (such as YANG models) will be undertaken where appropriate.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
---
No formal expert reviews apply to this document.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?
---
This document does not contain a YANG module.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.
---
This document does not contain any sections written in a formal language.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?
---
Yes



10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?
---
Common issues from the routing area that have been identified and addressed include the application of centralized control architectures, security considerations, and operational considerations. Each of these topics were included in the discussion of this document and explicitly addressed in the document.

For example, control architectures are discussed in sections such as "Section 2.1.3 Generation Locality" and "Section 2.1.4 Execution Locality".  Security considerations are discussed in "Section 5 Security Considerations". Operational considerations are discussed in sections such as "Section 2.1.5 Configuration and Operational State" and "Section 3.1 Operating Efficiency Use Case".

There are no applicable expert topics or common issues from any of the routing areas that remain to be addressed in this document.


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
---
Publication as an Informational document is being requested.

Informational is the proper type of RFC because the stated intention of the document is to provide general materials that can be tailored for other specific TVR-implementing systems. The requirements in this document are captured at a high enough level of abstraction that avoid predisposing a given design or implementation.

Datatracker state attributes correctly reflect the intent of this document being published as informational.


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.
---
All authors have been reminded of the disclosure obligations described in BCP 79. There have been no IPR disclosures related to this document on the mailing list or otherwise discussed in any TVRWG meeting.


13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.
---
The document has a total of four authors and each are willing to be listed as such.


14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)
---
This document has no nits reported by the idnits tool.

Otherwise, this document conforms with all applicable guidelines listed in the "Content Guidelines" section of authors.ietf.org.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.
---
This informational document contains a single normative reference to RFC9657 "TVR Use Cases" which is, itself, an informational RFC. Having an informational document with a normative section is unusual. Having a normative reference that is an informational document is unusual.

An argument is made that the purpose of this document is to support the TVR use cases defined in RFC9657, thus making RFC9657 a normative reference. It is possible that this reasoning will be reversed prior to publication and that RFC9657 be reclassified as informational.


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
---
There are no such references in this document.


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
---
There are no normative downward references in this document.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?
---
There are no such references in this document.


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.
---
No, publication of this document will not update any existing RFC.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
---
The IANA considerations section of this document appropriately determines that there are no IANA actions.



21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.
---
There are no such registries or required IANA actions.

Document Shepherd Writeup for Time-Variant Routing Requirements
Ed Birrane
30 November 2025


# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?
---
WG consensus represents broad agreement within the TVRWG. This document was presented at each TVRWG meeting and there were multiple discussions on the mailing list involving at least one dozen working group members. A github set up for the document recorded 29 issues all of which have been satisfactorily resolved.

A TVRWG last call completed successfully in August, 2025. Since then, two sections of the document were added to address comments/issues from that WGLC.  A new WGLC is in place until mid-December based on those changes.

This writeup will be updated following the most recent WGLC for this document to capture any change to the above description of concurrence.


2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
---
There were some discussions around common terminology, security considerations, and potential requirements on timing resolution. In each case, the discussion was informative and converged on a common answer. None of the consensus was particularly rough.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)
---
There is no known discontent related to this document.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?
---
This is not a protocol document.


## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
---
This is an informational document capturing requirements specific to time-variant routing.

No formal external review of this requirements document was requested and such review was not considered necessary. External entities and interested parties participated in the review of this document through their participation in the TVRWG.

External formal reviews of TVR documents informed by this requirements document (such as YANG models) will be undertaken where appropriate.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
---
No formal expert reviews apply to this document.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?
---
This document does not contain a YANG module.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.
---
This document does not contain any sections written in a formal language.


## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?
---
Yes



10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?
---
Common issues from the routing area that have been identified and addressed include the application of centralized control architectures, security considerations, and operational considerations. Each of these topics were included in the discussion of this document and explicitly addressed in the document.

For example, control architectures are discussed in sections such as "Section 2.1.3 Generation Locality" and "Section 2.1.4 Execution Locality".  Security considerations are discussed in "Section 5 Security Considerations". Operational considerations are discussed in sections such as "Section 2.1.5 Configuration and Operational State" and "Section 3.1 Operating Efficiency Use Case".

There are no applicable expert topics or common issues from any of the routing areas that remain to be addressed in this document.


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
---
Publication as an Informational document is being requested.

Informational is the proper type of RFC because the stated intention of the document is to provide general materials that can be tailored for other specific TVR-implementing systems. The requirements in this document are captured at a high enough level of abstraction that avoid predisposing a given design or implementation.

Datatracker state attributes correctly reflect the intent of this document being published as informational.


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.
---
All authors have been reminded of the disclosure obligations described in BCP 79. There have been no IPR disclosures related to this document on the mailing list or otherwise discussed in any TVRWG meeting.


13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.
---
The document has a total of four authors and each are willing to be listed as such.


14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)
---
This document has no nits reported by the idnits tool.

Otherwise, this document conforms with all applicable guidelines listed in the "Content Guidelines" section of authors.ietf.org.


15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.
---
This informational document contains a single normative reference to RFC9657 "TVR Use Cases" which is, itself, an informational RFC. Having an informational document with a normative section is unusual. Having a normative reference that is an informational document is unusual.

An argument is made that the purpose of this document is to support the TVR use cases defined in RFC9657, thus making RFC9657 a normative reference. It is possible that this reasoning will be reversed prior to publication and that RFC9657 be reclassified as informational.


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
---
There are no such references in this document.


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
---
There are no normative downward references in this document.


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?
---
There are no such references in this document.


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.
---
No, publication of this document will not update any existing RFC.


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
---
The IANA considerations section of this document appropriately determines that there are no IANA actions.



21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.
---
There are no such registries or required IANA actions.