Hi, Kent, Thanks a lot for the comments, please see my reply below inline…
From: Kent Watsen [mailto:[email protected]] Sent: Tuesday, May 20, 2025 10:17 PM To: maqiufang (A) <[email protected]> Cc: Mahesh Jethanandani <[email protected]>; [email protected]; [email protected] Subject: Re: [netmod] AD review of draft-ietf-netmod-schedule-yang-05 A couple comments below. Kent // contributor <snip/> Though utc format is favorable for interoperability, I think a local-time + time zone reference still has wide use in a lot of cases, e.g., timestamps in a lot of audits and logs are usually based on the local time of the device, and this document is intended to be common to accommodate different requirements. 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. Section 3.3.1, paragraph 5 > The "time-zone-identifier" parameter, if provided, specifies the time > zone reference [RFC7317] of the local date and time values. This > parameter MUST be specified if any of the date and time values are in > the format of local time. It MUST NOT be applied to date and time > values which are specified in the format of UTC or time zone offset > to UTC. If this is a MUST, why is the parameter not marked mandatory? And because of that, it shows up as optional in the tree diagram. I guess it should not be mandatory as it is uncertain whether the date-and-time formats specified in the grouping is in the format of UTC or local time. I think there are two questions that were hit. The first is whether the grouping should define default/mandatory statement. I still think that there are some parameters that must have a default value or be defined as mandatory, otherwise the behavior will be unspecified. But I think it would be better for the use-statement to refine with a default/mandatory statement, as it is unsure the default value will be applicable to all cases, and it would be problematic in some cases where a default value is not needed (there is no way to remove a default statement from a grouping). I agree with this. The NETCONF WG went through the same discussion with the client-server drafts. While the discussion with YangDoctor is that, Reshad understands it might be problematic to have default statement in generic groupings, but he is unsure whether a specific parameter should specify the default value in the description statement without a default statement. This is the one I think it would be good to have more discussion and feedback from the WG. To me, this feels to provide a safeguard to understand the default behavior if neither a default or mandatory statement is refined for a use-statement, and for those that really dislike this default value (they want a new value or don’t need the default value at all), it is always possible for the use-statement to refine the description. That is why I felt the current handling has some merit, but also happy to hear from others. 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? 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. 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. Kent // contributor Best Regards, Qiufang
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
