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

[Mahesh Jethanandani <[e-mail]>]

Hi Yingzhen,

> On Apr 15, 2026, at 1:02 PM, Yingzhen Qu <[e-mail]> wrote:
> 
> Hi Mahesh and all,
> 
> Thanks for all the reviews and comments. The authors are scheduled to have a meeting tomorrow (4/16) to discuss all the comments received; we will get back to you with solid answers after.
> 
> 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.

Cheers.

> 
> Thanks,
> Yingzhen
> 
> On Wed, Apr 15, 2026 at 10:19 AM Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Gunter,
>> 
>> For the specific comment/change, the ietf-tvr-topology model by its own admission says that:
>> 
>>       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.";
>>       }
>> 
>> It even uses the same definition for the type - ‘type inet:uri’ as RFC 8345. All I am asking is that, rather than redefining it, with no bearing to the generic topology model, 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. 
>> 
>> Note, the module will have to import the ietf-network module.
>> 
>> For the remaining comments, see inline with [mj]
>> 
>> 
>>> On Apr 15, 2026, at 1:21 AM, Gunter van de Velde (Nokia) <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Mahesh,
>>> 
>>> One more note: IVY’s draft-ietf-ivy-network-inventory-topology already defines the mapping between inventory and topology and how to navigate between them. There is no need to address this in the TVR module.
>>> 
>>> G/
>>> 
>>> 
>>> From: Gunter van de Velde (Nokia) <gunter.van_de_velde=[e-mail] <mailto:[e-mail]>>
>>> Sent: Wednesday, April 15, 2026 10:06 AM
>>> To: The IESG <[e-mail] <mailto:[e-mail]>>; Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
>>> Cc: [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: Mahesh Jethanandani's Discuss on draft-ietf-tvr-schedule-yang-08: (with DISCUSS and COMMENT)
>>> 
>>> Hi Mahesh,
>>> 
>>> Many thanks for sharing your observations.
>>> I am a bit surprised about mixing IVY (an inventory) with TVR (scheduling). Please see inline on some of my thoughts around this item: GV>
>>> 
>>> 
>>> From: Mahesh Jethanandani via Datatracker <[e-mail] <mailto:[e-mail]>>
>>> Sent: Sunday, April 12, 2026 11:39 PM
>>> To: The IESG <[e-mail] <mailto:[e-mail]>>
>>> Cc: [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] Mahesh Jethanandani'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.
>>> 
>>> 
>>> 
>>> Mahesh Jethanandani 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:
>>> ----------------------------------------------------------------------
>>> 
>>> Section 5.2, paragraph 10
>>> >     revision 2022-02-09 {
>>> >       description
>>> >         "Initial Version";
>>> >       reference
>>> >         "RFC XXXX: YANG Data Model for Scheduled Attributes.";
>>> >     }
>>> 
>>> The revision date here must have been just a typo error, as it does
>>> not match the date on the CODE BEGINS line.
>>> 
>>> Section 5.2, paragraph 10
>>> >       leaf node-id {
>>> >         type inet:uri;
>>> >         description
>>> >           "Identifier for a node, uniquely identifies a node.";
>>> >       }
>>> 
>>> The IVY model (ietf-network-inventory) provides a read-only,
>>> network-wide inventory of physical network elements and their
>>> components, as seen from a controller. While that is a network
>>> level model, there is specific linkage points between the two
>>> drafts. They are:
>>> 
>>> - node-id <-> ne-id: ietf-tvr-topology uses node-id of type
>>> inet:uri and notes it "may be the same as the node-id defined
>>> in the ietf-network module (RFC 8345)." IVY's ne-id is a string.
>>> In practice, both identify the same physical network element
>>> from the controller's perspective — but there is no formal
>>> binding or leafref between them. This is a gap that could cause
>>> correlation ambiguity in deployments. Considering changing the
>>> node-id to a leafref.
>>> 
>>> GV> The draft draft-ietf-tvr-schedule-yang-08 normatively references RFC 8245, which seems reasonable.
>>> GV> If a linkage is needed between IVY’s ne-id and the node-id defined in RFC 8345, it would be better to address this via an errata to RFC 8345 or by updating the IVY (draft-ietf-ivy-network-inventory-yang) draft since it is not yet published. This ensures the relationship is consistently inherited by all models referencing RFC 8345 or IVY draft.
>>> GV> Silently sneaking in such linkage in the TVR draft appears, at least to me, inappropriate and potentially incorrect.
>> 
>> [mj] See above for the specific change.
>> 
>>> 
>>> - Augmentation opportunity: IVY is designed to be extended.
>>> A natural companion module could augment
>>> /nwi:network-inventory/nwi:network-elements/nwi:network-element
>>> with TVR schedule groupings to attach planned maintenance windows,
>>> scheduled power-down periods, or availability schedules to inventory
>>> entries. This work does not yet exist in either draft.
>>> 
>>> GV> This may be an opportunity, but it goes beyond what TVR set out to do when the work was chartered.
>>> GV> The draft draft-ietf-tvr-schedule-yang focuses on scheduling, not inventory. If needed, a separate augmentation draft can address TVR-specific scheduling aspects. It does not have to be in this specific draft.
>> 
>> [mj] True. That is for a new/different draft.
>> 
>>> 
>>> - Component-level scheduling gap: IVY goes down to the component
>>> level (cards, ports, chassis). The TVR schedule models only go to the
>>> interface level in ietf-tvr-node. There is no TVR mechanism to attach
>>> schedules to sub-interface components or hardware chassis as
>>> represented in IVY's component list. This could matter in cases
>>> where the sub-interfaces are used (with tagging such as VLAN) to
>>> create different "links".
>>> 
>>> GV> The TVR yang model focusses upon what time-varient networks pragmatically need based upon the use cases described in RFC9657.
>>> GV> I'll leave it to the authors and the WG to decide if component level (cards/ports/chassis) makes pragmatic sense considering RFC9657.  
>> 
>> [mj] Ok.
>> 
>> Thanks
>> 
>>> 
>>> Section 7, paragraph 2
>>> >       /node-schedule/node-power-schedule
>>> >       /node-schedule/interface-schedule
>>> >       /topology-schedule/nodes/available
>>> >       /topology-schedule/links/available
>>> 
>>> The ietf-tvr-topology module (Section 5.3) defines list node and list
>>> link (both singular) as children of container topology-schedule.
>>> The correct YANG instance-identifier paths are therefore:
>>> 
>>> /topology-schedule/node/available
>>> /topology-schedule/link/available
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> >From a process perspective, the YANG Doctors review was performed
>>> against -03 (five revisions ago). The -08 document has addressed
>>> some but not all of the issues raised. No re-review was requested
>>> for the later revisions. The authors should confirm with the YANG
>>> Doctors that the outstanding issues have been satisfactorily
>>> addressed, but I will let the AD decide how he wants to handle it.
>>> 
>>> Section 3.2, paragraph 0
>>> >    Module ietf-tvr-node.yang is a device model and designed to manage a
>>> >    single node with scheduled attributes.
>>> 
>>> Chongfeng Xie (thanks Chongfeng) in his OPSDIR review noted that examples
>>> would be good to have, which the authors have added. Thanks for doing that.
>>> The readers could further benefit from a pointer like "See Appendix B for
>>> an example" from each of these sections.
>>> 
>>> Section 3.3, paragraph 1
>>> >    The module has a list of nodes, identified by a unique "node-id".
>>> >    Each node has a list of links.  Links are modeled as unidirectional.
>>> >    Link availability is described from the viewpoint of a particular
>>> >    source node (the transmitting node) and beginning at a particular
>>> >    time.  Each link in the list contains the range of times during which
>>> >    it is available.
>>> 
>>> The YANG Doctors review by Xufeng Liu (thanks Xufeng) noted that this
>>> module models links as unidirectional, described from the viewpoint
>>> of a source node. RFC 8346 calls the equivalent concept a
>>> "link termination-point" rather than a "link." The current document
>>> does not explain this divergence, even as they have used other terms
>>> from RFC8345/8346 like node. Authors should add a sentence in
>>> Section 3.3 either acknowledging the design difference and rationale,
>>> or clarifying how this module relates to the RFC 8345/8346 topology model.
>>> 
>>> Section 3.3, paragraph 1
>>> >    The "source-link-id" is a string and used to identify a link as
>>> >    viewed from the source-node.  Bandwidth and delay are predicted link
>>> >    attributes.  Delay is the link propagation time and does not include
>>> >    any queuing delays. "destination-node" of a link may follow a
>>> >    schedule as well.
>>> 
>>> This section states "Delay is the link propagation time and does not
>>> include any queuing delays," but does not say how this value is expected
>>> to be determined (e.g., computed from physical distance, measured via
>>> probing, or operator-configured). A clarifying sentence would help implementors.
>>> 
>>> Section 5, paragraph 0
>>> >    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].
>>> 
>>> This sentence is confusing. How about just saying that "This module
>>> uses definitions from [RFC9911]."?
>>> 
>>> Section 5.1, paragraph 4
>>> >      description
>>> >        "The YANG module contains common YANG definitions for
>>> >         time-variant schedule.
>>> 
>>> This model exists to define a single grouping. That grouping
>>> could as well have been defined in the ietf-tvr-node or the
>>> ietf-tvr-topology module. Why the need to define a separate module?
>>> 
>>> If the reason was to allow this grouping could be used by other
>>> modules, that can happen even if it is part of the ietf-tvr-node.
>>> 
>>> Section 5.2, paragraph 3
>>> >     import ietf-tvr-schedule {
>>> >       prefix "tvr-schd";
>>> >     }
>>> 
>>> Please add a reference statement to this draft.
>>> 
>>> Section 5.2, paragraph 13
>>> >           leaf default-bandwidth {
>>> >             type yang:gauge64;
>>> >             units "bits/second";
>>> >             default "0";
>>> >             description
>>> >               "The default interface bandwidth in bits
>>> >                per second";
>>> >           }
>>> 
>>> The type is set to guage64. It is defined in RFC9911 as:
>>> The gauge64 type represents a non-negative integer, which
>>> may increase or decrease, but shall never exceed a maximum
>>> value, nor fall below a minimum value.
>>> 
>>> Curious as to why a gauge was used and not something like
>>> uint64, which can also be used to represent a non-negative
>>> number. Is the default-bandwidth value expected to
>>> increase/decrease during operations?
>>> 
>>> Section 5.3, paragraph 4
>>> >    import ietf-tvr-schedule {
>>> >      prefix "tvr-schd";
>>> >    }
>>> 
>>> Please add a reference statement here.
>>> 
>>> Section 7, paragraph 1
>>> >    Some of the readable data nodes in the ietf-tvr-node.yang module and
>>> >    ietf-tvr-topolgy.yang module may be considered sensitive or
>>> >    vulnerable in some network environments.  It is thus important to
>>> >    control read access (e.g., via get, get-config, or notification) to
>>> >    these data nodes.
>>> 
>>> This section states, "Some of the readable data nodes in the
>>> ietf-tvr-node.yang module and ietf-tvr-topology.yang module may be
>>> considered sensitive," but does not enumerate which nodes. The YANG
>>> security guidance (as applied in many similar YANG documents) expects
>>> that sensitive readable nodes be specifically called out, just as
>>> writable nodes are. Consider listing the specific subtrees
>>> (e.g., scheduled neighbor information, interface availability)
>>> that operators should consider protecting via read access control.
>>> 
>>> Also
>>> s/ietf-tvr-topolgy/ietf-tvr-topology/
>>> 
>>> -------------------------------------------------------------------------------
>>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flarseggert%2Fietf-reviewtool&data=05%7C02%7Cgunter.van_de_velde%40nokia.com%7Cfb3a85fa56fe468879f208de98dc0e34%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C639116268060380961%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cQRJyqVm0d4Pdmmz3A2zUtHmxYobzNIwDeOfB6o%2BoR0%3D&reserved=0) <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.
>>> 
>>> "Abstract", paragraph 0
>>> >    The YANG model in this document includes three modules, and can be
>>> >    used to manage network resources and topologies with scheduled
>>> >    attributes, such as predictable link loss and link connectivity as a
>>> >    function of time.  The intent is to have this information be utilized
>>> >    by Time-Variant Routing systems.
>>> 
>>> 
>>> s/three modules,/three modules/
>>> 
>>> Section 1, paragraph 0
>>> >    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.
>>> 
>>> 
>>> s/ReST/REST/
>>> 
>>> Section 7, paragraph 2
>>> >    There are a number of data nodes defined in ietf-tvr-node.yang module
>>> >    and ietf-tvr-topology.yang that are writable/creatable/deletable
>>> >    (i.e., config true, which is the default).  These data nodes may be
>>> >    considered sensitive or vulnerable in some network environments.
>>> >    Write operations (e.g., edit-config) to these data nodes without
>>> >    proper protection can have a negative effect on network operations.
>>> >    There are the subtrees and data nodes and their sensitivity/
>>> >    vulnerability:
>>> 
>>> 
>>> s/There are the/These are the/
>>> 
>>> Document references draft-ietf-netmod-schedule-yang, but that has been
>>> published as RFC9922{quote}.
>>> 
>>> These URLs in the document can probably be converted to HTTPS:
>>> 
>>>  * http://datatracker.ietf.org/wg/tvr
>> 
>> 
>> Mahesh Jethanandani
>> [e-mail] <mailto:[e-mail]>
>> 
>> 
>> 
>> 
>> 
>> 


Mahesh Jethanandani
[e-mail]