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






_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to