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

[Yingzhen Qu <[e-mail]>]

Hi Med,

Thanks for your review and comments. The authors will discuss the issues
and get back to you soon.

Thanks,
Yingzhen

On Tue, Apr 7, 2026 at 8:58 PM Mohamed Boucadair via Datatracker <
[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
>
>
>
>