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 [email protected] 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 _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
