Re: [Netconf] mbj's WGLC review of yang-push-17

[Alexander Clemm <[e-mail]>]

We should stay with uint32.
uint16 would mean just under 11 minutes – too short imho.
--- Alex

From: Andy Bierman [mailto:[e-mail]]
Sent: Tuesday, September 25, 2018 9:57 AM
To: t.petch <[e-mail]>
Cc: Kent Watsen <[e-mail]>; Martin Bjorklund <[e-mail]>; Alexander Clemm <[e-mail]>; Netconf <[e-mail]>
Subject: Re: [Netconf] mbj's WGLC review of yang-push-17


On Tue, Sep 25, 2018 at 2:01 AM tom petch <[e-mail]<mailto:[e-mail]>> wrote:
----- Original Message -----
From: "Kent Watsen" <[e-mail]<mailto:[e-mail]>>
Sent: Monday, September 24, 2018 7:15 PM

> >Alexander Clemm <[e-mail]<mailto:[e-mail]>> wrote:
> >> I am about to post -19 but I do not like the suggested change to go
> >> from timeticks to seconds.
> >>
> >> Seconds is a fairly coarse unit.  I would not be surprised to see
> >> requirements for finer granularity in the future, even more so in
> >> virtualization and controller scenarios in which we start to see
YANG
> >> being used.  There are applications that use single second periods
> >> today so I think it is entirely conceivable to see need for
subsecond
> >> support down the line.  To allow periods only in units of seconds
> >> would seem to unnecessarily hobble ourselves.  Keeping things to
> >> timeticks is more futureproof IMHO.
> >
> > Ok.
>
> I agree that seconds is too course. Hundredths of a second is maybe
too
> fine, but I won't complain.  That said, I think that it might be an
> uncommon scenario and that having hundredths of a second will likely
> result in very large numbers.
>
> FWIW, yang:timeticks doesn't seem as intuitive as "units" - for
example:

Kent

It may depend where you come from.  As RFC6991 points out, timeticks is
designed to be compatible with SMI TimeTicks and so will likely to be
familiar,  expected even, for those who have been at this for, say, 10
years or more.


Or even 30 years!
https://tools.ietf.org/html/rfc1065

I do not understand the motivation for using uint16.
This would limit the maximum period to 655.35 seconds.

Tom Petch

Andy


>           leaf period {
> -           type yang:timeticks;
> +           type uint16;
> +           units "Hundredths of a second";
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>
> At least I know what this means right away.  I was hoping to find an
example
> in -19 illustrating its use, but it's none is present.
>
> BTW, I note that RFC 6991 says:
>
>          When a schema
>          node is defined that uses this type, the description of
>          the schema node identifies both of the reference epochs.
>
> Which I don't see in -19.
>
> Would it make sense to use a 2-tuple?  Something like:
>
>           leaf period {
>             type uint16;
>             mandatory true;
>             description
>               "Duration of time which should occur between periodic
>                push updates.";
>           }
>           leaf period-units {
>             type enumeration {
>               enum hundredths;
>               enum tenths;
>               enum seconds;
>               enum minutes;
>               enum hours;
>             }
>             mandatory true;
>           }
>
>
>
> Kent // contributor
>
>
> _______________________________________________
> Netconf mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netconf

_______________________________________________
Netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf