[netmod] Re: AD review of draft-ietf-netmod-schedule-yang-05

[Kent Watsen <[e-mail]>]

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).



> 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.

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.



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";
       }
    }


Kent // contributor