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

[Acee Lindem <[e-mail]>]

Hi Med, 

There were many different modules mentioned by either Mahesh and yourself including ietf-interface,  ietf-te-topology, and ietf-network-inventory-topology.
So, the that is being proposed is ietf-network-topology.yang - correct? 

Acee


> On May 21, 2026, at 1:12 PM, [e-mail] wrote:
> 
> Hi Acee,
> 
> Thank you for the follow-up.
> 
> As far as I'm concerned (and I think Mahesh as well), I wasn't asking why TE model/RFC8795 isn't used.
> 
> Our question was vs. RFC8345 which provides the minimal nodes/links you need. The design in draft-ietf-tvr-schedule-yang seems to duplicate what is already there (no need to restate the ops consistency issues shared in previous messages by both Mahesh and Myself), hence the DISCUSSion about building on 8345 unless there are good reasons.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Acee Lindem <[e-mail]>
>> Envoyé : jeudi 21 mai 2026 18:18
>> À : Mahesh Jethanandani <[e-mail]>; BOUCADAIR
>> Mohamed INNOV/NET <[e-mail]>
>> Cc : Gunter van de Velde <[e-mail]>; Yingzhen
>> Qu <[e-mail]>; The IESG <[e-mail]>; draft-
>> [e-mail]; [e-mail]; tvr-
>> [e-mail]; [e-mail]
>> Objet : Re: [iesg] Mohamed Boucadair's Discuss on draft-ietf-tvr-
>> schedule-yang-08: (with DISCUSS and COMMENT)
>> 
>> Mahesh, Mohamed,
>> 
>> While I don't agree with using DISCUS to propose a different YANG
>> module for node/link scheduling, I'm going to add the following
>> text to the draft to satisfy your request for justification of the
>> ietf-tvr-topology.yang module. I've also refactored the module
>> itself with reusable groupings which you or any other ADs can
>> augment any of the modules you suggested (the list was all over
>> the map).
>> 
>> 3.3.1.  Relationship to the Traffic Engineering YANG Module
>> 
>>   The ietf-te-topology YANG module is specified in [RFC8795].
>> One
>>   design option would have been to augment this module rather
>> than
>>   define a separate time-variant routing topology module.  This
>> option
>>   was not pursued due to concerns about modularity and the
>> overall
>>   scope of the ietf-te-topology module.  Defining a separate
>> ietf-tvr-
>>   topology module facilitates implementation and deployment
>>   flexibility.
>> 
>>   The ietf-te-topology module is defined as a single, relatively
>> large
>>   YANG module and does not make extensive use of YANG features to
>> allow
>>   selective implementation of subsets of functionality.
>> 
>>   While ietf-te-topology provides a comprehensive model for
>> traffic
>>   engineering topologies, it is not necessarily intended to serve
>> as
>>   the base for all topology-related augmentations.  A more
>> minimal base
>>   topology model, containing only nodes and links, could provide
>> a more
>>   flexible foundation for augmentation by different applications.
>> 
>>   Other IETF YANG modules have similarly defined separate
>> topology
>>   models rather than augmenting ietf-te-topology, for example,
>>   [I-D.ietf-ivy-network-inventory-topology].
>> 
>>   To promote modularity and reuse, the time-variant scheduling
>>   definitions for nodes and links are specified as reusable YANG
>>   groupings.  These groupings can be used to augment ietf-te-
>> topology
>>   or other IETF YANG modules, as needed.  The reusable groupings
>>   include node-availability-schedule, link-availability-schedule,
>> and
>>   link-default-attributes.
>> 
>> I hope this satisfies this aspect of your DISCUSS. As I stated
>> previously, I feel that using DISCUSS to propose a different
>> technical solution from the one advanced by the TVR WG exceeds the
>> role of the the IESG.
>> 
>> Acee
>> 
>> 
>> 
>> 
>>> On Apr 23, 2026, at 5:46 PM, Mahesh Jethanandani
>> <[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]> 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]>
>>>> Sent: Tuesday, April 21, 2026 5:32 AM
>>>> To: Mohamed Boucadair <[e-mail]>
>>>> Cc: The IESG <[e-mail]>; draft-ietf-tvr-schedule-
>> [e-mail]
>>>> <[e-mail]>; [e-mail]
>>>> <[e-mail]>; [e-mail] <[e-mail]>;
>>>> [e-mail] <[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
>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> dat
>>>> atracker.ietf.org%2Fdoc%2Fminutes-118-tvr-
>> 202311090830%2F&data=05%7C0
>>>> 
>> 2%7Cmohamed.boucadair%40orange.com%7C1c14b34df2614500b1c708deb7549
>> 469
>>>> 
>> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639149771067779960%7
>> CUn
>>>> 
>> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> AiO
>>>> 
>> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EEg
>> HAo
>>>> 7xzgfH5PTq2y4RxiqVUlkNgBCOejLeWp5kGdw%3D&reserved=0
>>>> The discussion at IETF 119 was more about some model details:
>>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> dat
>>>> atracker.ietf.org%2Fdoc%2Fminutes-119-tvr-
>> 202403200300%2F&data=05%7C0
>>>> 
>> 2%7Cmohamed.boucadair%40orange.com%7C1c14b34df2614500b1c708deb7549
>> 469
>>>> 
>> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639149771067825250%7
>> CUn
>>>> 
>> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> AiO
>>>> 
>> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8NF
>> 5pT
>>>> 4zHJjqHUfbMJxdMZes2%2Bh7rgft29bG3S3gxdU%3D&reserved=0
>>>> 
>>>> 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]> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> www
>>>> .ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-
>> ballot-posi
>>>> 
>> tions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1c14b34df
>> 261
>>>> 
>> 4500b1c708deb7549469%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
>> 639
>>>> 
>> 149771067855442%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIl
>> YiO
>>>> 
>> iIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C
>> 0%7
>>>> 
>> C%7C%7C&sdata=F4nWOWj%2F9H1pypO8J4vIuLh1YUq4ZgS5jh0n7GdiBo0%3D&res
>> erv
>>>> ed=0 for more information about how to handle DISCUSS and
>> COMMENT
>>>> positions.
>>>> 
>>>> 
>>>> The document, along with other ballot positions, can be found
>> here:
>>>> 
>> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
>> dat
>>>> atracker.ietf.org%2Fdoc%2Fdraft-ietf-tvr-schedule-
>> yang%2F&data=05%7C0
>>>> 
>> 2%7Cmohamed.boucadair%40orange.com%7C1c14b34df2614500b1c708deb7549
>> 469
>>>> 
>> %7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639149771067881746%7
>> CUn
>>>> 
>> known%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl
>> AiO
>>>> 
>> iJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=fa4
>> BfN
>>>> PNRHO4l5kO8JVkBysY2vPVOpycU%2Babi4b%2FzIs%3D&reserved=0
>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------
>> ------
>>>> -
>>>> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7C1c14b34df2614500b1c708deb7549469%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C639149771067903451%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=K6p8IFlQCxh4braIttccs
>> Pbgv3bSy90zbpzkclsyfJg%3D&reserved=0); 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.iana.org%2Fassignments%2Fyang-
>> parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1c14b34
>> df2614500b1c708deb7549469%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7
>> C0%7C639149771067924300%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn
>> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy
>> fQ%3D%3D%7C0%7C%7C%7C&sdata=yMlcQIT7QkTSIcCZ4QwZVqLHe%2Bqi9GaMiadV
>> RiVgjMI%3D&reserved=0).
>>>> 
>>>>        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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2Frfc6241&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7C1c14b34df2614500b1c708deb7549469%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C639149771067960209%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BSDq4WUjOUMpt9ds5vi
>> PjYAmWl5QglFiW9PEWT0R1lw%3D&reserved=0>.
>>>> 
>>>>   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over
>> Secure
>>>>              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242,
>> June 2011,
>>>> 
>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2Frfc6242&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7C1c14b34df2614500b1c708deb7549469%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C639149771067979308%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=v0gTWzCIVkWuaE3r4xzU6
>> HPbLFP6L%2Fti6NCvBCiXG9U%3D&reserved=0>.
>>>> 
>>>>   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen,
>> "RESTCONF
>>>>              Protocol", RFC 8040, DOI 10.17487/RFC8040,
>> January 2017,
>>>> 
>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2Frfc8040&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7C1c14b34df2614500b1c708deb7549469%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C639149771067997721%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=8aAV0au5wrHzoNqM9njoy
>> cJXTJ3m0evGM676YREKZPc%3D&reserved=0>.
>>>> 
>>>>   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS)
>> Protocol
>>>>              Version 1.3", RFC 8446, DOI 10.17487/RFC8446,
>> August 2018,
>>>> 
>> <https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2
>> Fwww.rfc-
>> editor.org%2Finfo%2Frfc8446&data=05%7C02%7Cmohamed.boucadair%40ora
>> nge.com%7C1c14b34df2614500b1c708deb7549469%7C90c7a20af34b40bfbc48b
>> 9253b6f5d20%7C0%7C0%7C639149771068018031%7CUnknown%7CTWFpbGZsb3d8e
>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo
>> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=E6%2FK0Yw3855BVhx0uEp
>> yxDabcXsxPaT9So6U9sch1Kc%3D&reserved=0>.
>>>> 
>>>> # 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]
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> ____________________________________________________________________________________________________________
> 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.