Yeah, I'm good with this diff, thanks. Happy to clear the discuss when it gets posted.
Thanks again, -ek On Mon, Aug 4, 2025 at 2:56 AM Qin Wu <bill...@huawei.com> wrote: > Agree with Med, two points to make > 1. There are no existing RFC to document those practices implemented by > Google and Amazon. Do we have a concrete reference in IETF instead of [1] > and [2]. > 2. In 2022, the world’s timekeepers have decided to get rid of leap > seconds by the year 2035. See [3] for more details. So is it still useful > to document these good practices when it will be abandoned by the year 2035. > maybe 10 year time frame is still worth. > > [3] > https://www.nationalgeographic.com/premium/article/leap-second-year-utc-atomic-clock-nist > > -Qin > -----邮件原件----- > 发件人: mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com] > 发送时间: 2025年8月4日 15:19 > 收件人: Erik Kline <ek.i...@gmail.com>; The IESG <i...@ietf.org> > 抄送: draft-ietf-netmod-schedule-y...@ietf.org; netmod-cha...@ietf.org; > netmod@ietf.org; james.cumm...@nokia.com > 主题: RE: Erik Kline's Discuss on draft-ietf-netmod-schedule-yang-08: (with > DISCUSS) > > Hi Erik, > > Fair point to record. I went with the following: > > NEW: > * Unless deployed in contexts where time synchronization is not > subject to leap second adjustments (e.g., Section 4.3 of > [I-D.ietf-ntp-ntpv5]), the second for date and time values SHOULD > have the value "60" at the end of months in which a leap second > occurs. > > For convenience, the diff can be seen at: > https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/schedule-yang/draft-ietf-netmod-schedule-yang.txt&url_2=https://netmod-wg.github.io/schedule-yang/erik-review/draft-ietf-netmod-schedule-yang.txt > > Let me know if we need to say more. Thanks. > > Cheers, > Med (as author) > > > > -----Message d'origine----- > > De : Erik Kline via Datatracker <nore...@ietf.org> Envoyé : lundi 4 > > août 2025 07:27 À : The IESG <i...@ietf.org> Cc : > > draft-ietf-netmod-schedule-y...@ietf.org; netmod- cha...@ietf.org; > > netmod@ietf.org; james.cumm...@nokia.com; james.cumm...@nokia.com > > Objet : Erik Kline's Discuss on draft-ietf-netmod-schedule-yang-08: > > (with DISCUSS) > > > > > > 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.) > > > > > > > > -------------------------------------------------------------------- > > DISCUSS: > > -------------------------------------------------------------------- > > > > # Internet AD comments for draft-ietf-netmod-schedule-yang-08 > > CC @ekline > > > > > > ## 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fde > > velopers.google.com%2Ftime%2Fsmear&data=05%7C02%7Cmohamed.boucadair% > > 40orange.com%7C73168df9ac0740afb89808ddd3178bf1%7C90c7a20af34b40bfbc > > 48b9253b6f5d20%7C0%7C0%7C638898820278854251%7CUnknown%7CTWFpbGZsb3d8 > > eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoi > > TWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=L9ZJ%2BexYJsvgI8hUFALpr9 > > RKjaTaHN9zMT1YjFdfcPI%3D&reserved=0 > > [2] > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faw > > s.amazon.com%2Fblogs%2Faws%2Flook-before-you-leap-the-coming-leap- > > second-and- > > aws%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C73168df9ac074 > > 0afb89808ddd3178bf1%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638 > > 898820278867719%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > > OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0 > > %7C%7C%7C&sdata=HWDNbhUicXDKJs0lbfK2Q2HB4JRWkFwZSDtzOrt1uLU%3D&reser > > ved=0 > > > > > > > > > > > ____________________________________________________________________________________________________________ > 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 -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
