Hi Mike, Thanks for the review.
A diff to track the changes 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/mike-review/draft-ietf-netmod-schedule-yang.txt. Please see inline for more context. Cheers, Med (as author) > -----Message d'origine----- > De : Mike Bishop via Datatracker <[email protected]> > Envoyé : mardi 5 août 2025 17:41 > À : The IESG <[email protected]> > Cc : [email protected]; netmod- > [email protected]; [email protected]; [email protected]; > [email protected] > Objet : Mike Bishop's No Objection on draft-ietf-netmod-schedule- > yang-09: (with COMMENT) > > > Mike Bishop has entered the following ballot position for > draft-ietf-netmod-schedule-yang-09: No Objection > > 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.) > > > -------------------------------------------------------------------- > COMMENT: > -------------------------------------------------------------------- > > How will new values of schedule-type be defined? [Med] These are typically defined in other modules. See the examples provided in the base spec: rfc7950#section-7.18.3 What should a > client do if it > encounters an unknown value? The text implies that there could be > more defined > in the future, but describes no forward-compatible handling. [Med] We don't repeat the behavior here as the base YANG/protocols specs will be followed here. Refer, for example, to rfc7950#section-9.10.2 Valid values for an identityref are any identities derived from all the identityref's base identities. On a particular server, the valid values are further restricted to the set of identities defined in the modules implemented by the server. and rfc7950#section-8.3.1 for validation. > > In 3.3.4, it's fine to say that this document doesn't prohibit > intervals > shorter than durations; should this have a note similar to 3.3.3 > recommending > that users add restrictions if they require that recurrences not > overlap? [Med] We don't need to repeat it here because this one "uses the grouping defined in 3.3.3: The "recurrence-utc" grouping (Figure 4) uses the "recurrence-basic" ^^^^^^^^^^^^^^^^^^^^^^^^^^ grouping and specifies a simple recurrence rule in UTC format.^ ^^^^^^^^ "uses" has a special meaning in YANG. Please see: rfc7950#section-7.13 That's said, I added a point to 3.3.3 to make that clearer. > > Several comments in 3.3.4 seem like they apply equally to subsequent > sections; > a reference to those comments would be useful if they're not going > to be > repeated, or move them to apply more broadly. [Med] Added an explicit citation to 3.3.5. Other subsections will import that because the "use" the other groupings. > > In 3.3.9, is "bumped" a formally defined YANG term? Would > "incremented" be > better? [Med] Sure. Done. > > With regard to the leap second discussion, shouldn't it be > sufficient to > specify that :60 is a valid value that MUST be tolerated on receipt > and MAY be > produced if the implementation represents leap seconds that way? [Med] I think that I like the text agreed with Erik. > > === NITS FOLLOW === > > - Abstract, "recurrence related" => "recurrence-related" > > - 3.1, "iCalender like" => "iCalendar-like" or "like iCalendar" > > - 3.3.2, "no later the end" => "no later than the end" > > [Med] ACK. ____________________________________________________________________________________________________________ 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]
