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
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
