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

[Benjamin Kaduk <[e-mail]>]

On Fri, Oct 12, 2018 at 02:26:08PM +0000, Jiangyuanlong wrote:
> 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. 

Indeed, this topic is quite related to Ben's point about document access.
Though I think generally we still want our documents to be able to stand
alone in some sense, so there's a balance to find.

> 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.  My apologies for some of the incomplete/incoherent comments;
I had to stop mid-review and forgot to do a cleanup pass before balloting.
Thank you for doing your best to pick out what I was trying to say!

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

I was suggesting "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".
> [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.

I'm not suggesting to change it, no.  There's a tradeoff to make when the
existing terms are well-known already, and this is not the right place to
start to make a change, especially since we don't have an IETF consensus
position yet.

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

I had done some more research after I wrote this note (which was supposed
to just be a note to myself, sorry).  I guess ANSI C has some confusing
text in it (viz.
https://groups.google.com/forum/#!topic/comp.protocols.time.ntp/HvZBLs413ng)
and this confusion has been hard to stamp out.

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


Thanks,

Benjamin