Sorry for the extraordinary delay. =) I'm not sure what I meant either, at this point. :D However, I think my overarching concern is that calendaring systems have been notoriously difficult to implement in a way that isn't crappy in some corner cases. For example, scheduling something that happens at 2am every Sunday -- what should happen at daylight savings changes?
I think for this reason, I'd just be in favor of simplicity for the routers' sake, and separate out some of the "calendaring" of tasks from the commanding of those tasks sent to routers/nodes. In other words, it might be more reliable to have some of the richer recurrence information managed in a controller and only the simplest of timed task information be sent to routers. In the case of the 2am Sunday daylight saving change, for example, the controller could maintain the policy of what is meant to happen and send recurrence task info for the period prior to the change, the period after the change, and one or more timed tasks during the time change. In other words, what might need to be representable within a controller might not need to be sent -- in all its complex glory -- to routers. two cents, though, -ek On Thu, Jun 20, 2024 at 4:50 AM <[email protected]> wrote: > Hi Erik, > > > > At TVR@IETF119, you raised the following comment ( > https://datatracker.ietf.org/doc/minutes-119-tvr-202403200300/): > > > > == > > Erik Kline: sldie 5, timezones makes everything worse. datetime start is > > bad name. call it "utc start time". interval vs duration? > > > > possibly going to be removed, working with schedule authors for specific > > grouping for tvr > > > > Erik Kline: If you want to recurr make the control system do it if want > > to make truly simple. so remove that from model. > > === > > > > We updated the common module to address the comments about use explicit > names for utc groupings + clarify interval vs. duration). The changes can > be seen at > https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.html#name-the-recurrence-utc-grouping. > These changes will be inherited by the TVR spec. > > > > I’m not sure to understand the last part of your comment above. I would > appreciate if you can clarify. Thanks. > > > > Cheers, > > Med > > > > ____________________________________________________________________________________________________________ > 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. > >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
