Erik Kline has entered the following ballot position for draft-ietf-netmod-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-netmod-schedule-yang/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Internet AD comments for draft-ietf-netmod-schedule-yang-08 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Discuss ### S4 * "The second for date and time values MUST have the value "60" at the end of months in which a leap second occurs." I think this ties too strongly to an outmoded way of handling leap seconds. It is widely documented by some cloud operators, for example, that "leap smearing" can be employed [1, 2]. A scheduler taking time from a leap smeared clock would never encode "60" at any time, nor should it. I think you can retain this MUST if you craft an exemption for schedule producers and consumers that have no other way of dealing with leap seconds. (Separately, I've taken a note to see about crafting some draft that might be a useful reference.) [1] https://developers.google.com/time/smear [2] https://aws.amazon.com/blogs/aws/look-before-you-leap-the-coming-leap-second-and-aws/ _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
