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

[[e-mail]]

Hi Yingzhen, all,

Thank you for the follow-up, changes, and detailed explanations below. -10 looks good to me.

I will clear my DISUCSS right now.

Cheers,
Med

De : Yingzhen Qu <[e-mail]>
Envoyé : mercredi 10 juin 2026 00:56
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Acee Lindem <[e-mail]>; Mahesh Jethanandani <[e-mail]>; Gunter van de Velde <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: [iesg] Re: Mohamed Boucadair's Discuss on draft-ietf-tvr-schedule-yang-08: (with DISCUSS and COMMENT)


Hi Med and all,

Sorry for the delay.

The authors discussed how to address the IESG comments, especially regarding augmentations. We have modified the ietf-tvr-topology.yang module to augment ietf-network.yang and ietf-network-topology.yang defined in RFC 8345. We decided to keep the ietf-tvr-node.yang module as independent as it is, considering the ietf-logical-network-element.yang and ietf-interfaces.yang are not widely deployed, and there are either openconfig or proprietary interface modules in use.

Version -10 has been uploaded with the changes.

The following are other comments from Med with replies:

# 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.

[YQ]: the title is changed to "A YANG Data Model for Scheduled Attributes", and the referce clauses in the modules are updated as well.



# Please follow the guidance in Section 2.5 of RFC9907<https://datatracker.ietf.org/doc/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



[YQ]: fixed.



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



I would delete this text:



CURRENT:

   YANG [RFC7950<https://datatracker.ietf.org/doc/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<https://datatracker.ietf.org/doc/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

[YQ]: this has been removed.


# (nit) Reference use cases



OLD:

please reference to

   TVR (Time-Variant Routing) Use Cases [RFC9657<https://datatracker.ietf.org/doc/rfc9657/>]



NEW:

please refer to

   TVR (Time-Variant Routing) Use Cases [RFC9657<https://datatracker.ietf.org/doc/rfc9657/>]



[YQ]: fixed.





# 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.



[YQ]: fixed.





# 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<https://datatracker.ietf.org/doc/rfc8342/>]



[YQ]: removed.





# RFC9922<https://datatracker.ietf.org/doc/rfc9922/>



CURRENT:

   time" and "recurrence-utc" as defined in

   [I-D.ietf-netmod-schedule-yang<https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/>]



Please update this reference to RFC9922<https://datatracker.ietf.org/doc/rfc9922/>.



[YQ]: fixed.





# 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.

[YQ]: changed to "The schedule in the grouping can be augmented with attributes or containers.".



# Escape clause for RFC9911<https://datatracker.ietf.org/doc/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<https://datatracker.ietf.org/doc/rfc9911/>]



You don’t need this text per RFC9907<https://datatracker.ietf.org/doc/rfc9907/>:



   If the module (or modules) defined by the specification imports

   definitions from other modules (except for those defined in [RFC7950<https://datatracker.ietf.org/doc/rfc7950/>]

   or [RFC9911<https://datatracker.ietf.org/doc/rfc9911/>] or is always implemented in conjunction with other

   modules, then those facts MUST be noted in the overview section;

[YQ]: removed.



# 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

[YQ]: added as suggested.



# 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<https://datatracker.ietf.org/doc/rfc9922/>: A Common YANG Data Model for Scheduling";

     }

[YQ]: fixed.



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

[YQ]: fixed.



# Update the description of your modules to follow the IET template in RFC9907<https://datatracker.ietf.org/doc/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.";

[YQ]: fixed.



# 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.";

     }

[YQ]: fixed.



# NMDA Again: Please delete the following:



CURRENT:

        This YANG model conforms to the Network Management

        Datastore Architecture (NMDA) as described in RFC 8342<https://datatracker.ietf.org/doc/rfc8342/>.

[YQ]: removed.



# 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";

  }

[YQ]: fixed.


# 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.

[YQ]: removed "default" from the default-bandwidth description.



# use “units” statement



CURRENT:

          description

            "The default one-way delay in microseconds.";



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

[YQ]: added "units:.



# 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.

[YQ]: changed this to "However, it's NOT RECOMMENDED for simplicity and easy readability."



# 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.

[YQ]: added "For example, the "node-id" in the ietf-tvr-node.yang module."



# Security Considerations



Consider updating to follow the template in RFC9907<https://datatracker.ietf.org/doc/rfc9907/>, Section 3.7.1

[YQ]: done.



# Reference



Please move the following from Normative to Informative



   [RFC6241<https://datatracker.ietf.org/doc/rfc6241/>]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,

              and A. Bierman, Ed., "Network Configuration Protocol

              (NETCONF)", RFC 6241<https://datatracker.ietf.org/doc/rfc6241/>, DOI 10.17487/RFC6241, June 2011,

              <https://www.rfc-editor.org/info/rfc6241><https://www.rfc-editor.org/info/rfc6241%3E>.



   [RFC6242<https://datatracker.ietf.org/doc/rfc6242/>]  Wasserman, M., "Using the NETCONF Protocol over Secure

              Shell (SSH)", RFC 6242<https://datatracker.ietf.org/doc/rfc6242/>, DOI 10.17487/RFC6242, June 2011,

              <https://www.rfc-editor.org/info/rfc6242><https://www.rfc-editor.org/info/rfc6242%3E>.



   [RFC8040<https://datatracker.ietf.org/doc/rfc8040/>]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF

              Protocol", RFC 8040<https://datatracker.ietf.org/doc/rfc8040/>, DOI 10.17487/RFC8040, January 2017,

              <https://www.rfc-editor.org/info/rfc8040><https://www.rfc-editor.org/info/rfc8040%3E>.



   [RFC8446<https://datatracker.ietf.org/doc/rfc8446/>]  Rescorla, E., "The Transport Layer Security (TLS) Protocol

              Version 1.3", RFC 8446<https://datatracker.ietf.org/doc/rfc8446/>, DOI 10.17487/RFC8446, August 2018,

              <https://www.rfc-editor.org/info/rfc8446><https://www.rfc-editor.org/info/rfc8446%3E>.

[YQ]: done.



# 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<https://datatracker.ietf.org/doc/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.

[YQ]: Changed the text to
"
   This example demonstrates how an OSPF interface [RFC9129] can be
   extended with a cost that changes with a schedule using the grouping
   defined in ietf-tvr-schedule.yang.
"

Thanks,
Yingzhen (on behalf of co-authors)

On Thu, May 21, 2026 at 10:57 AM <[e-mail]<mailto:[e-mail]>> wrote:
Re-,

Yes, ietf-network-topology.

I fully agree that ietf-te-topology and ietf-network-inventory-topology are not relevant to this discussion.

Cheers,
Med

> -----Message d'origine-----
> De : Acee Lindem <[e-mail]<mailto:[e-mail]>>
> Envoyé : jeudi 21 mai 2026 19:48
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
> Cc : Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>; Gunter van de
> Velde <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu
> <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; draft-ietf-
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>
> Objet : [iesg] Re: Mohamed Boucadair's Discuss on draft-ietf-tvr-
> schedule-yang-08: (with DISCUSS and COMMENT)
>
>
> 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]<mailto:[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]<mailto:[e-mail]>> Envoyé : jeudi 21 mai
> 2026
> >> 18:18 À : Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>;
> BOUCADAIR
> >> Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>> Cc : Gunter
> van de
> >> Velde <[e-mail]<mailto:[e-mail]>>; Yingzhen Qu
> >> <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>; draft-
> >> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; tvr-
> >> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<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]>>; draft-ietf-tvr-schedule-
> >> [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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >> dat
> >>>> atracker.ietf.org<http://atracker.ietf.org/>%2Fdoc%2Fminutes-118-tvr-
> >> 202311090830%2F&data=05%7C0
> >>>>
> >>
> 2%7Cmohamed.boucadair%40orange.com<http://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<http://atracker.ietf.org/>%2Fdoc%2Fminutes-119-tvr-
> >> 202403200300%2F&data=05%7C0
> >>>>
> >>
> 2%7Cmohamed.boucadair%40orange.com<http://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]<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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> >> www
> >>>> .ietf.org<http://ietf.org/>%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-
> >> ballot-posi
> >>>>
> >>
> tions%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://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<http://atracker.ietf.org/>%2Fdoc%2Fdraft-ietf-tvr-schedule-
> >> yang%2F&data=05%7C0
> >>>>
> >>
> 2%7Cmohamed.boucadair%40orange.com<http://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<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> >> Fwww.rfc-
> >>
> editor.org<http://editor.org/>%2Finfo%2FrfcXXXX&data=05%7C02%7Cmohamed.boucadair%40ora
> >>
> nge.com<http://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<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> >> Fwww.iana.org<http://fwww.iana.org/>%2Fassignments%2Fyang-
> >>
> parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com<http://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<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> >> Fwww.rfc-
> >>
> editor.org<http://editor.org/>%2Finfo%2Frfc6241&data=05%7C02%7Cmohamed.boucadair%40ora
> >>
> nge.com<http://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<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> >> Fwww.rfc-
> >>
> editor.org<http://editor.org/>%2Finfo%2Frfc6242&data=05%7C02%7Cmohamed.boucadair%40ora
> >>
> nge.com<http://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<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> >> Fwww.rfc-
> >>
> editor.org<http://editor.org/>%2Finfo%2Frfc8040&data=05%7C02%7Cmohamed.boucadair%40ora
> >>
> nge.com<http://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<https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%252>
> >> Fwww.rfc-
> >>
> editor.org<http://editor.org/>%2Finfo%2Frfc8446&data=05%7C02%7Cmohamed.boucadair%40ora
> >>
> nge.com<http://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]<mailto:[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.

____________________________________________________________________________________________________________
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.
____________________________________________________________________________________________________________
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.