[Tvr] Mohamed Boucadair's No Objection on draft-ietf-tvr-requirements-08: (with COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-tvr-requirements-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/



----------------------------------------------------------------------
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,
              <https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/
              aixm_temporality_1.0.pdf>.

Cheers,
Med