Hi all, (as contributor) I echo Qiufang comment about the first point below and I appreciate Kent’s position on this. I think no further change is needed for that point.
OK to remove the default from the description as this seems to be confusing for many reviewers. Kent, for your last point, the approach followed since we started this work is to leverage rfc5545 (secondly and the like were defined there). Cheers, Med De : Kent Watsen <[email protected]> Envoyé : vendredi 23 mai 2025 04:28 À : maqiufang (A) <[email protected]> Cc : Mahesh Jethanandani <[email protected]>; [email protected]; [email protected] Objet : Re: [netmod] AD review of draft-ietf-netmod-schedule-yang-05 Hi Qiufang, IDK if there is any harm from accommodating local+zone formats, but I think that it is (should always be) the case that time is persisted in UTC in the storage layer. Time is typically sent in UTC over the wire too, leaving it to the client to convert to local time. FWIW, syslog files are both a persistence-format and a display format, and hence outside YANG ecosystem. My preference is for a YANG server to send UTC by default, but may send local time if the client passes a parameter (e.g., with-local-time), which would pass the preferred time-zone (e.g., +04:00). Yes, this sounds good to me. As a local+zone format may enhance readability and usability for end users without requiring further converting in some cases, the authors would like keep the related groupings in the draft if there is no objections. FWIW, we used to have one grouping that accommodates both the format of UTC and local+zone, but then split as some grouping consumers claim that they need UTC format only and never use the time-zone parameter and request separate definitions of both formats. I personally would only support UTC. I do not know any client unable to convert UTC to local time, and servers rarely prefer clients send local time. I don't know if I can "object", as I have no plan to implement this YANG module, as I already have a solution (shared before) that I like better. That said, to the extent that it is hoped this module will be used by other YANG modules, I may find myself needing to implement it someday... The biggest problem with a grouping specifying "mandatory" or "default" is that they are mutually exclusive and, whilst they can be "refined", they cannot be removed. In general, YANG designers should carefully scrutinize the use of either of these statements in groupings. Agree. But I think the point is whether it’s acceptable for some default value to be specified in the description only without having a “default” statement in the generic grouping? This is not in a normative way, but specifies a value if the client fails to configure the value of it. Besides, it is always possible for a uses-statement to refine a “description” statement. E.g, leaf interval { type uint32 { range "1..max"; } description "A positive integer representing at which interval the recurrence rule repeats. For example, within a 'daily' recurrence rule, a value of '8' means every eight days. The default value is '1', means every second for a 'secondly' recurrence rule, every minute for a 'minutely' rule, and so on."; } Or should we just remove this and require the uses statement to refine the grouping with a formal “default” statement? I would remove the default text from the "description" statement. That said, for the "recurrence-basic" grouping, it seems inconsistent that "frequency" be mandatory and "interval" is not. It seems that, if the model forces the configuration of one, then it should for the other as well. You are right, I guess the “mandatory” statement for “frequency” should be removed. And maybe require the uses statement to refine the grouping with a “mandatory” or “default” statement for it if necessary. Better, but notice what my "amount-and-units" grouping does below with "must" statement. With this idiom, neither value is "mandatory" but, if one value is configured, the other must be as well. Of course, this doesn't support "default" statements, but my use case is such that defaults are never desired. FWIW, in a YANG module I have something like this, which seems like a more natural tuple than the "frequency/interval" tuple: grouping amount-and-units { leaf amount { must '../units'; type uint16 { range "1..max"; } } leaf units { must '../amount'; type enumeration { enum seconds; enum minutes; enum hours; enum days; enum weeks; enum months; enum years; } } } grouping foobar-timeout { <-- there are many of these uses amount-and-units { refine "amount" { default "3"; } refine "units" { default "months"; } } Yes, this is a best practice in my mind as well. I think that you didn't get my comment. I'm suggesting this module renames nodes to be clearer (since "frequency" and "interval" are synonyms) and have better English (since, e.g., "secondly" is not a word). Of course, this document is past WGLC, so such comments are too late, but know that this is the one reason why I am disinclined to even implement this module. Kent // contributor ____________________________________________________________________________________________________________ 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]
