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

[Marc Blanchet <[e-mail]>]

> Le 15 avr. 2026 à 20:32, stndrds-inacio stndrds-inacio <[e-mail]> a écrit :
> 
> 
> 
> On Wed, Apr 15, 2026 at 5:38 PM Marc Blanchet <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>>> Le 15 avr. 2026 à 17:24, Christopher Inacio via Datatracker <[e-mail] <mailto:[e-mail]>> a écrit :
>>> 
>>> Christopher Inacio 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:
>>> ----------------------------------------------------------------------
>>> 
>>> Thanks for the presenting the TVR YANG model.  I don't know if I get to use it,
>>> but I'm excited about it.
>>> 
>>> * The model seems capable of modeling linear availability and periodicity.  If
>>> the availability is not linear, then I assume the model would approach this
>>> with some type of piece-wise linear approach.  Is that correct?  Is it possible
>>> to have the model say a node is available with two entries at the same time? 
>>> (I didn’t see any reason this couldn’t be true.). Would those be additive?
>>> 
>>> * There is a timezone for the various schedule entries.  If a non-earth
>>> timezone is created, let’s say lunar, what would the `frequency` entry mean if
>>> it said something such as `daily`?
>> 
>> Co-author here (and the least contributor) speaking only for himself. I was involved in this work because of the deep space use case where we need to manage the scheduling of links/nodes/network. However, when dealing with implementing it for some space projects and simulations, it occurred to me that the (terrestrial) timezone/time reference component by itself is far from enough, as you pointed out. One implementation I tried to make is to simulate a satellite around Mars using the raw data from JPL. Space missions use various timezones and time references, such as the spacecraft own time reference and others (see this for a quick list: https://science.nasa.gov/learn/basics-of-space-flight/chapter2-3/)  I presented this work during one of the tvr meeting. My own assessment: this is too complex and brings a lot of considerations for an easy "hack". So my conclusion is that we should punt this (deep space use case comprehensive support) for now, keep the current model simple for terrestrial case (and likely LEO/... cases) and implement the deep space later as an augmentation and thoughtful consideration.  Again, my personal opinion, not necessarily in sync with my co-authors. 
>> 
>> Hope to answer (or not ;-) your question.
>> Marc.
>> 
> 
> Åctually, this is very helpful.  If the co-authors agree, I would love to see a small disclaimer early in the document that says something to the effect of "not intended for use past (LEO/MEO/GEO) and all time references intended to be used in terrestrial frames."  
> 
> Not a space expert, but LEO seems like it wouldn't be too difficult, but the orbits may not be easily amenable to the availability model here.  I'm not sure what would happen with an elliptical orbit etc if you really tried to create the schedule for that in this model.

Fine by me. 

Just a caveat: anything regarding time in our IETF protocols may have the same "consideration". So I'm not sure we shall write a warning in all our protocols specs when time is involved (aka, all security/crypto, any time-based acks, any expiration (dns or caching or ...), ...). There is on-going work to study how to use/manage time in space, under the IP stack protocol perspective, but very early at the moment. 

Marc.

> 
> chris
> 
>>> 
>>> 
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>> 
>>> Thanks to Peter Yee for the SECDIR review.  Some additional comments to
>>> consider:
>>> 
>>> * what does available mean in the interface definition:
>>>> 235              +--rw interface* [name]
>>>> 236                 +--rw name                  union
>>>> 237                 +--rw default-available?    boolean
>>>> 238                 +--rw default-bandwidth?    yang:gauge64
>>>> 239                 +--rw attribute-schedule
>>> there are multiple `booleans` for available, but even if the top level
>>> available is true, the schedule could be resourced to be unavailable or the
>>> particular schedule could also be not available?  What would the implementation
>>> useage logic of all that add up to be?
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> --
> Chris Inacio
> Carnegie Mellon University