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

[Yingzhen Qu <[e-mail]>]

Hi Eric,

Sorry we missed this change in version -10. Version -11 has been uploaded
to address the DISCUSS and some other comments as well.

Here are some detailed replies to your comments:

### Supporting DISCUSS

I support Mahesh's DISCUSS about node-id not being compatible with the
IVY model (also about the hierachy of node components).

[YQ]: the ietf-tvr-topology module has been updated to augment the
ietf-network and ietf-network-topology modules defined in RFC8345.

### TVR in the title ?

Like Med, please add TVR in the title.

[YQ]: the title has been changed to "A YANG Data Model for Scheduled
Attributes".

### Section 1

In 2026, there is no need to justify the use of YANG, please consider
removing the first paragraph.

Unsure whether the module name should include the ".yang" extension as
module name is not the same as the filename containing the module.
Also applicable to other occurences of the module name.

My understanding is that there is no need to mention NMDA anymore
(also applicable in other places).

[YQ]: removed.

### Section 3.1

Unsure how to address this issue, but it is unclear on Figure 1 that
'va2' is using the default value, should the box be drawn with 'dots'
rather than with '-' ? See also my cosmetic nit about the use of SVG.

[YQ]: I changed the format a bit, so hopefully now it's eaiser to tell
that "va2" is different.

### Section 4.1

Please consider renaming 'node-power-schedule' into
'node-active-schedule' as being powered does not mean to be active.

I am really puzzled by the mix of a time-zone dependent leaf
`period-start` and UTC-based leaf `start-time-utc` (coming from
draft-ietf-netmod-schedule-yang
<https://datatracker.ietf.org/doc/draft-ietf-netmod-schedule-yang/>).
Is there a reason ? It seems confusing and error-prone. I also hope
that the netmod draft handles correctly the daylight saving and leap
seconds. But, this is good to re-use YANG modules ;)

[YQ]: this is defined in RFC9922.

### Section 4.2

As TVR could be used in "deep space", is the bandwidth unit in bit/sec
correct ? I.e., bandwidth will always be larger than 1 bit/second ? (I
guess so but just wanted to check).

[YQ]: we added some text in the "Operational Considerations" about deepspce.
"

   For simplicity, the modules are designed for terrestrial networking
   scenarios, including systems operating in near earth space, such as
   Low Earth Orbit (LEO) satellite networks.  Implementations for deep-
   space or interplanetary cases can be achieved through augmentations.

" ### Section 5.3 Why not a MUST rather than a SHOULD in `If the value
measured by the system is greater than this value the predicted value
SHOULD be used.`

[YQ]: This remains unchanged. ### Section 6 The operational considerations
are about TVR itself and not about the use of the YANG models per se.

[YQ]: I'd think it covers both. Any other aspects that you'd suggest to
add? ### Acknowledgements Suggest listing the tools used by the authors,
else this section is really vague ;-)

[YQ]: expanded. I had trouble with your name and will ask the RFC Editor's
help to fix it. ### Notifications ? Should these modules also have
notifications when the scheduled event occur ?
[YQ]: The authors didn't think notifications were needed. An implementation
can add a notification easily through augmentation if necessary. ## NITS
(non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML
rendering, suggest using the aasvg tool to generate SVG graphics. It is
worth a try especially if the I-D uses the Kramdown file format ;-)
[YQ]: maybe next time. :)


Thanks,
Yingzhen (On behalf of co-authors)

On Tue, Jun 9, 2026 at 11:56 PM Eric Vyncke (evyncke) <[e-mail]>
wrote:

> Hello Acee,
>
> Thanks for your patience waiting for my reply (May was a mix of hectic
> $dayjob and many European bank holidays).
>
> I note that the revised -10 has vastly ignored my non-blocking COMMENT
> review, which is OK.
>
> See below for EV> for the remaining DISCUSS.
>
> Regards,
>
> -éric
>
> *From: *Acee Lindem <[e-mail]>
> *Date: *Friday, 1 May 2026 at 19:11
> *To: *Eric Vyncke (evyncke) <[e-mail]>
> *Cc: *The IESG <[e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>;
> [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
> *Subject: *Re: Éric Vyncke's Discuss on draft-ietf-tvr-schedule-yang-08:
> (with DISCUSS and COMMENT)
>
> Hi Eric,
>
> > On Apr 13, 2026, at 8:40 AM, Éric Vyncke via Datatracker <
> [e-mail]> wrote:
> >
>
> ....%<.........%<.........
>
> > ### Section 4.2
> >
> > `destination-node` seems to be singular, i.e., does this model only cover
> > point-to-point links? It so, then it should be made clear in the
> > title/abstract/introduction. Section 5.2 leaf `neighbor` also appear to
> be
> > singular.
>
>
> We'll make destination-node a leaf-list to support P2MP. We'll also add a
> strict-destination flag
> indicating whether the destination connection is restricted to the
> specified destination-node(s).
>
> EV> I am afraid that I see neither of the proposed changes in -10
> EV> to address my DISCUSS either implement your suggested changes or
> EV> made the P2P restriction clear in the title/abstract/introduction
>
>
>
>