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

[Mahesh Jethanandani <[e-mail]>]

Hi Yingzhen,

> On Apr 23, 2026, at 2:55 PM, Yingzhen Qu <[e-mail]> wrote:
> 
> Hi Mahesh,
> 
> Currently although we're not augmenting or using a leafref, it's mentioned in the description about RFC 8345.
> 
>        leaf node-id {
>          type inet:uri;
>          description
>            "Identifier for a node; uniquely identifies a node. This
>             may be the same as the node-id defined in the ietf-network
>             module defined in RFC 8345.";
>        }
> 
> If the leafref is used as you suggested, should the node-id be specified as a union? Otherwise, what if RFC 8345 is not implemented?

No. The leafref I am suggesting is not a hard dependency, it is a consistency requirement and an effort to avoid operational burden.

TVR is explicitly a topology-aware scheduling model. It schedules availability of nodes and links in a network. If you are implementing TVR, you are necessarily in the domain of network topology. RFC 8345 is the IETF's standard model for that domain.

The leafref doesn't impose a gratuitous dependency — it says: "the node you are scheduling is the same node you already have in your topology model." If a system is running TVR scheduling but has no RFC 8345 topology, what nodes is it scheduling, and how does anything correlate with the rest of the management stack?

The inet:uri type without a leafref is effectively a free-text field — there's nothing enforcing referential integrity between the TVR node being scheduled and any actual node in the network topology. That's a real operational problem: collectors, orchestrators, and analytics tools all need to join TVR scheduling data with topology data, and without a leafref there's no machine-readable assurance that the identifiers match.

The more fundamental issue Med raised — and which you're now pointing at — is whether the TVR topology module should exist at all as a standalone model.

Consider what TVR is doing: it is defining when nodes and links in a network are available. That is a property of a network topology, not a separate topology. The established YANG design pattern for this is precisely augmentation:

augment "/nw:networks/nw:network/nw:node" {
  uses tvr:availability-schedule;
}
augment "/nw:networks/nw:network/nt:link" {
  uses tvr:availability-schedule;
}

This is exactly how RFC 8346 (L3 topology), RFC 8944 (L2 topology), and other models extend RFC 8345. The pattern is well-established and broadly implemented.

The WG chose standalone for "deployment simplicity," but that argument undermines itself: if TVR scheduling data can't be correlated with the RFC 8345 topology, operators will have to maintain two parallel node/link inventories and manually reconcile them. That's more operational burden, not less.

Rather than insisting that the model be changed to an augmented module of RFC 8345, which in my mind is still the right solution, I am suggesting a middle ground. Make the node, link, and interface consistent with what is defined in RFC 8345 and RFC 8343. That will allow for nodes, links and interfaces to be corelated across the management stack and maintaining identifier integrity.

Cheers.

> 
> Thanks,
> Yingzhen
> 
> On Thu, Apr 23, 2026 at 2:46 PM Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Yingzhe/Gunter,
>> 
>> I have explained this a couple of times, but I guess that explanation is not coming across. I will repeat it one more time here, but if that still does not make sense, it might be helpful to get on a call to explain this. Yingzhen, you know how to get hold of me.
>> 
>> See inline with [mj]
>> 
>>> On Apr 23, 2026, at 2:11 AM, Gunter van de Velde (Nokia) <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi Med, Mahesh,
>>> 
>>> The draft-ietf-tvr-schedule-yang authors provided additional context and clarified the WG’s consensus on the relationship with RFC8345, including supporting data and rationale.
>>> 
>>> Does this address your RFC8345 DISCUSS on draft-ietf-tvr-schedule-yang?
>>> 
>>> If not, the alternative is to return the document to the WG for further discussion on the same topic. I would prefer to avoid that, given the prior extensive discussion and limited new input likely to change the outcome.
>>> 
>>> Brgds,
>>> G/
>>> 
>>> 
>>> 
>>> From: Yingzhen Qu <[e-mail] <mailto:[e-mail]>>
>>> Sent: Tuesday, April 21, 2026 5:32 AM
>>> To: Mohamed Boucadair <[e-mail] <mailto:[e-mail]>>
>>> Cc: The IESG <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
>>> Subject: [iesg] Re: Mohamed Boucadair's Discuss on draft-ietf-tvr-schedule-yang-08: (with DISCUSS and COMMENT)
>>> 
>>>  
>>> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext <http://nok.it/ext> for additional information.
>>>  
>>> 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.
>> 
>> [mj] Here is what I said in my response on 4/15.
>> 
>>>> However, we need to clarify one thing. When we started the work, we discussed whether to augment the network topology module defined in RFC 8345. The WG's consensus was to keep the TVR model independent for easier implementation and deployment. This also applies to the IVY model (ietf-network-inventory).
>>> 
>>> Augmentation would have been ideal, but I can understand if there were design choices for not wanting to do it.
>>> 
>>> When we think of networks and network topology in a holistic way, there is usually one network topology, or at least there is one way to refer to all the nodes in the network. The change below is the min way to refer to a node in the network the same way, Since the module referred to RFC 8345, I gave you an example of a RFC 8345 definition of ne-id, so the two can be consistent.
>> 
>> 
>> and even suggested a simple solution:
>> 
>>>>> All I am asking is that, rather than augmenting it, it should have a leafref to the node in RFC 8345. Something like
>>>>> 
>>>>>       leaf node-id {
>>>>>         type leafref {
>>>>>           path "path "/nw:networks/nw:network[nw:network-id=current()/../"+
>>>>>                             "network-ref]/nw:node/nw:node-id”;
>>>>>         }
>>>>>         description
>>>>>           "Identifier for a node; uniquely identifies a node.";
>>>>>       }
>>>>> 
>>>>> where ‘nw’ is the prefix for ‘ietf-network’ module, so that implementations and users know we are talking about the same node-id. 
>> 
>> That way, you are not augmenting the RFC 8345 model, that your model is still standalone, but you are still using the same ’node-id’ consistently across all the models.
>> 
>> Does that help explain the ask?
>> 
>> Cheers.
>> 
>>> 
>>> 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
>> 
>> 
>> Mahesh Jethanandani
>> [e-mail] <mailto:[e-mail]>
>> 
>> 
>> 
>> 
>> 
>> 


Mahesh Jethanandani
[e-mail]