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

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tictoc-1588v2-yang-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


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

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

We have leap59/leap61; might we need a leap62?

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