Re: [TICTOC] Benjamin Kaduk's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)

[Jiangyuanlong <[e-mail]>]

Hi Ben,

I think all the questions on terminologies or units are mainly triggered due to the lack of access to the IEEE 1588-2008 standard. They are defined there (with much more details and explanations) and have been used widely in the industry for quite a long time. 
Perhaps Karen can help to make an arrangement with the IEEE 1588 WG, so that some electronic copies of IEEE 1588-2008 can be sent to the reviewers in the IETF.

Please see my further replies prefixed with [YJ]. 
Thanks much for the review and comments.

Regards,
Yuanlong

----------------Snipped----------------------------
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I appreciate that there has been some previous work in this area, but it
> seems that there are still many instances of bare integral types with no
> indication of what units are used to report a numerical value, whether
> larger or smaller priority values indicate a more preferred status, how the
> sign of an "offset" measurement should be interpreted, etc.  This leaves
> the specification unimplementable in an interoperable way.  A (possibly
> incomplete) list of such values includes:
> 
> clock-class (is this really more like an enum than an int?)
> clock-accuracy (ditto?)
> offset-scaled-log-variance
> priority1 (are small or large values more-preferred?)
> priority2 (ditto)
> offset-from-master (interpretation of sign bit)
> observed-parent-offset-scaled-log-variance
> observed-parent-clock-phase-change-rate
> grandmaster-priority1
> grandmaster-priority2
> current-utc-offset (sign bit)
> time-source (is this more like an enum?)
> log-min-delay-req-interval (units have to be scaled out before log operation)
> log-announce-intervale (ditto)
> log-sync-interval (ditto)
> log-min-pdelay-req-interval (ditto, two different nodes)
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 1
> 
>    o  When the IEEE 1588 standard is revised (e.g. the IEEE 1588
>    revision in progress at the time of writing this document), it will
>    add some new optional features to its data sets.  The YANG module
>    of this document MAY be revised and extended to support these new
>    features. Moreover, the YANG "revision" SHOULD be used to indicate
>    changes to the YANG module under such a circumstance.
> 
> It's not clear that a 2119 SHOULD is best here; I would have expected
> either an 8174 "should" or a 2119 "MUST".
> 
[YJ] Are you suggesting to use "must" or "MUST"? Otherwise, I think "should" is similar to "SHOULD".


> Section 3
> 
> time-interval-type says "units of nanoseconds and multiplied by 2^16".
> I assume I'm interperting that wrong, since there doesn't seem to be much
> point in claiming a precision in yoctoseconds.
> 
> Most "log" values specify the "base-two logarithm", but
> offsetScaledLogVariance has a much more vague description.  Lacking access
> to IEEE 1588-2008, I can't tell if it is possible to be more precise for
> describing this field.  (Also, you can only take the log of a dimensionless
> quantity, so the input units need to be specified, per my Discuss.)
> 
> > slave-only clock
> 
> So we had this long discussion on [e-mail] about potentially offensive
> terminology, including "master"/"slave".
[YJ] Are you suggesting to change the terminologies? These are well accepted terms in the IEEE 1588, people there will be much confused if terms are changed.

> 
> We have leap59/leap61; might we need a leap62?
> 
[YJ] A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC) in order to keep its time of day close to the mean solar time (UT1). Thus, only 59 or 61 is possible (i.e., 1 second ahead or backward), and we don't need a leap62 or any other bigger leaps.


> Section 4
> 
> (I guess you don't need to talk about sensitive ro nodes when all the nodes
> are under the sensitive rw nodes already mentioned.)
> 
[YJ] No, we don't talk about any read-only nodes in Section 4.