[Tvr] Re: Mohamed Boucadair's Discuss on draft-ietf-tvr-schedule-yang-08: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Yingzhen, all,

Thank you for sharing these additional context.

As indicated in my ballot, I think that we need the design rationale explained in the draft itself for the three parts (topo, LNE, interfaces). This covers also having a discussion on the expected interaction to prevent interference between some of these modules: for example, if a node also supports interface module, how to prevent contradicting instructions are being supplied? How to ensure that if/name is pointing to the interface to be managed, etc. Similar considerations apply for the node level as it seems that your design assumes that the control is not at the component level but system-wise, which precludes cases where several instances to be controlled are within the same node, etc. Likewise for the topology, you assume that a node belong to one and only one topology.

Do you think that you can have such discussion in the spec?

Cheers,
Med

De : Yingzhen Qu <[e-mail]>
Envoyé : mardi 21 avril 2026 05:32
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-tvr-schedule-yang-08: (with DISCUSS and COMMENT)


Hi Med and all,

Thanks for the reviews and comments.

The authors and the document shepherd (Tony Li) discussed the comments we received. The most important question we need to answer from the IESG DISCUSSes is why the model is not augmenting existing IETF modules, such as the network-topology module defined in RFC 8345, the interface and LNE modules.

 We've watched the video recordings and confirmed with the TVR-chairs about the WG consensus. Here are our answers to the IESG.

The draft was adopted by the WG in Apr 2024 after IETF 119, and there were discussions during the TVR sessions at both IETF 118 and 119.
Long discussions about whether to augment or be standalone at IETF 118:
Minutes of TVR at IETF 118: https://datatracker.ietf.org/doc/minutes-118-tvr-202311090830/
The discussion at IETF 119 was more about some model details: https://datatracker.ietf.org/doc/minutes-119-tvr-202403200300/

The draft was adopted by the WG with standalone modules without any objections. The authors believe that we have achieved WG consensus that the modules should be standalone.

If the IESG insists that augmentations should be used, then the draft needs to be sent back to the WG.

The authors will be happy to address other comments after we resolve this issue.

Thanks,
Yingzhen (on behalf of co-authors)


On Tue, Apr 7, 2026 at 5:58 AM Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
Mohamed Boucadair has entered the following ballot position for
draft-ietf-tvr-schedule-yang-08: Discuss

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-schedule-yang/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Yingzhen, Acee, Eric, Don, and Marc,

Thank you for the effort put into this specification.

Thanks to Chongfeng Xie for the OPSDIR review and to the authors for engaging
and addressing his review.

Please find below some points for DISCUSSion:

# Design Rationale

## ietf-tvr-schedule

This module is not TVR-sepcific but a generic one similar to the one defined in
RFC9922. Please update the module name and prefix to follow a patter similar to
RFC9922. The description should be updated as well to reflect the generic
nature of the module.

## Node module

CURRENT:
   Module ietf-tvr-node.yang is a device model and designed to manage a
   single node with scheduled attributes.

It is not clear to me how this is anchored in NE? What isn’t this defined as an
extension to ietf-logical-network-element?

Please consider adding a rationale of this design and how this is supposed to
work.

## Idem vs. interface

CURRENT:
   Each node has scheduled power at the node level.  At the interface
   level, a node has a list of interfaces, and each interface has its
   own schedule for availability/power up and down, scheduled bandwidth,
   and scheduled neighbors.

Idem why isn’t this defined as an augmentation of the interface module? How
overall consistency will be ensured.

# Idem for the topology

CURRENT:
   Module ietf-tvr-topology.yang describes a network topology with a
   time-variant availability schedule.

Why isn’t this defined as a new ietf-network type + augmentation to RFC 8345 -
A YANG Data Model for Network Topologies?

## Some elaboration about the design adopted in the draft compared to the
alternatives mentioned above is needed, IMO. Thanks.

# Broken JSON Examples

RF9907 requires the following:

  Examples that are meant to illustrate a valid
   data instance MUST be validated (Section 3.10).

At least all your JSON Examples are broken: namespace issues, type
mis-alignment, no quotes for duration, etc.

Please fix all these (you can run yangson or yanglint to fix those).


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Overall, consider adding a discussion how thsi spec meets the requirements of
TVR Use Cases.

# Title

## Consider

OLD: YANG Data Model for Scheduled Attributes

NEW: A YANG Data Model for Scheduled Attributes

## I wonder whether you can include TVR in the title as well.

## Please update the title in the reference clauses of your YANG modules.

# Please follow the guidance in Section 2.5 of RFC9907 about data model, model,
etc.

## For example, please make this change in the abstract:

OLD: The YANG model

NEW: The YANG data model

## Idem in the Introduction;

OLD:    The YANG model in this document can

NEW:    The YANG data model in this document can

## Please make sure this is used in a consistent manner through the document

# We don’t need to motivate the use of YANG!

I would delete this text:

CURRENT:
   YANG [RFC7950] is a data definition language used to define the
   contents of a conceptual data store that allows networked devices to
   be managed using NETCONF [RFC6241].  YANG is proving relevant beyond
   its initial confines, as bindings to other interfaces (e.g., ReST)
   and encodings other than XML (e.g., JSON) are being defined.
   Furthermore, YANG data models can be used as the basis for
   implementation of other interfaces, such as CLI and programmatic
   APIs.

If you keep it, then s/being defined/defined

# (nit) Reference use cases

OLD:
please reference to
   TVR (Time-Variant Routing) Use Cases [RFC9657].

NEW:
please refer to
   TVR (Time-Variant Routing) Use Cases [RFC9657].

# Please list the modules in the order they are defined in the document:

CURRENT:
   Module ietf-tvr-schedule.yang contains the schedule YANG definitions.
   Module ietf-tvr-topology.yang defines a network topology with time-
   variant availability.  Module ietf-tvr-node.yang is to be used to
   manage scheduled attributes of a single node.

# NMDA: The new guidance is to highlight when we deviate from NMDA

Please delete this statement:

CURRENT:
   The YANG modules in this document conform to the Network Management
   Datastore Architecture (NMDA) [RFC8342].

# RFC9922

CURRENT:
   time" and "recurrence-utc" as defined in
   [I-D.ietf-netmod-schedule-yang].

Please update this reference to RFC9922.

# Users: Not sure to get what is meant by users in this text. Please clarify
that in the text.

CURRENT:
  Users can supply attributes or containers that augment the schedule.

# Escape clause for RFC9911 and the like

CURRENT:
   The following RFC is not referenced in the document text but is
   referenced in the "ietf-tvr-schedule.yang" module and "ietf-tvr-
   topology.yang" module: [RFC9911].

You don’t need this text per RFC9907:

   If the module (or modules) defined by the specification imports
   definitions from other modules (except for those defined in [RFC7950]
   or [RFC9911]) or is always implemented in conjunction with other
   modules, then those facts MUST be noted in the overview section;

# Please consider adding a tree with ietf-tvr-schedule grouping

NEW:
module: ietf-tvr-schedule

  grouping tvr-schedule:
    +-- schedule* [schedule-id]
       +-- schedule-id                     uint32
       +-- (schedule-type)?
          +--:(period)
          |  +-- period-description?       string
          |  +-- period-start?             yang:date-and-time
          |  +-- time-zone-identifier?     sys:timezone-name
          |  +-- (period-type)?
          |     +--:(explicit)
          |     |  +-- period-end?         yang:date-and-time
          |     +--:(duration)
          |        +-- duration?           duration
          +--:(recurrence)
             +-- recurrence-first
             |  +-- start-time-utc?   yang:date-and-time
             |  +-- duration?         uint32
             +-- (recurrence-end)?
             |  +--:(until)
             |  |  +-- utc-until?          yang:date-and-time
             |  +--:(count)
             |     +-- count?              uint32
             +-- recurrence-description?   string
             +-- frequency?                identityref
             +-- interval?                 uint32

# Update reference clause

OLD:
     import ietf-schedule {
       prefix "schedule";
       reference
         "RFC XXXX: A Common YANG Data Model for Scheduling";
     }

NEW:
     import ietf-schedule {
       prefix "schedule";
       reference
         "RFC 9922: A Common YANG Data Model for Scheduling";
     }

# Update TLP Date of ietf-tvr-schedule s/2025/2026

# Update the description of your modules to follow the IET template in RFC9907,
in particular:

OLD:
        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX) see the RFC itself
        for full legal notices.";

NEW:
        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters)

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";

# Extra reference clause

OLD:
     reference
       "RFC XXXX: YANG Data Model for Scheduled Attributes";

     revision 2025-06-30 {
       description
         "Initial Version";
       reference
         "RFC XXXX: YANG Data Model for Scheduled Attributes.";
     }

NEW:

     revision 2025-06-30 {
       description
         "Initial Version";
       reference
         "RFC XXXX: A YANG Data Model for Scheduled Attributes.";
     }

# NMDA Again: Please delete the following:

CURRENT:
        This YANG model conforms to the Network Management
        Datastore Architecture (NMDA) as described in RFC 8342.

# The module will live outside the RFC

OLD:
  import ietf-tvr-schedule {
    prefix "tvr-schd";
  }

NEW:
  import ietf-tvr-schedule {
    prefix "tvr-schd";
    reference
      "RFC XXXX: A YANG Data Model for Scheduled Attributes";
  }

# Redundant descriptions

CURRENT:
          type boolean;
          default false;
          description
            "By default, the link is not available.";

        leaf default-bandwidth {
          type yang:gauge64;
          units "bits/second";
          default "0";
          description
            "The default interface bandwidth in bits

The description for both nodes is redundant with “default” clause. Please
consider a more meaningful description of the node, without repeating the
default clause.

# use “units” statement

CURRENT:
          description
            "The default one-way delay in microseconds.";

Please use units statant rather than having this in the description.

# Explain the recommendation

CURRENT:
   recurrence.  The model defined in this document doesn't prevent a
   configuration to mix both styles.  However, it's not recommended.

I would use NOT RECOMMENDED here. Also, please consider motivate the
recommendation.

# Help identify the relevant data nodes

CURRENT:
   The TVR schedule modules are meant to work together with other models
   that manage node or interface attributes.

You list in your modules some identifiers that might be common (node-id, etc.).
I would call these here for awareness.

# Security Considerations

Consider updating to follow the template in RFC9907, Section 3.7.1

# Reference

Please move the following from Normative to Informative

   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              <https://www.rfc-editor.org/info/rfc6241>.

   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              <https://www.rfc-editor.org/info/rfc6242>.

   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              <https://www.rfc-editor.org/info/rfc8040>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

# Appendix “Example: Add a scheduled cost to OSPF interface”

What is the purpose of this example? Please consider clarifying that in the
text.

# Please add a reference to RFC9129 in the following:

CURRENT:
By default, the OSPF interface cost is calculated
   based on the bandwidth of the interface, and it is also configurable.

Cheers,
Med


____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.