Ballot for draft-ietf-tictoc-1588v2-yang
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
Thanks for the work on this document to everyone involved. I have a few minor comments and one question. --------------------------------------------------------------------------- > A simplified YANG tree diagram [RFC8340] representing the data > model is typically used by YANG modules. This document uses the > same tree diagram syntax as described in [RFC8340]. As RFC 8340 is necessary reading to understand this section, I believe it should be a normative reference rather than an informative reference. --------------------------------------------------------------------------- §2.1: > Based on statements in IEEE 1588-2008 subclauses 8.3.1 and 10.1, > most transparent clock products have interpreted the transparent > clock data sets to reside as a singleton at the root level of the > managed product, and this YANG model reflects that location. I'll note that "most" is not "all." Is there any guidance that can be provided to implementors of this module for products that fall outside this common case? --------------------------------------------------------------------------- Page 14: > leaf priority1 { > type uint8; > description > "The priority1 attribute of the local clock."; > } This description seems to be of very limited utility. Consider adding a description that will be more informative to operators. This is true for clock-quality and priority2 as well. --------------------------------------------------------------------------- Appendix A: I'm a little surprised that this appendix doesn't treat the matter of whether the Last IETF 1588 YANG module will be left as a standards track document, obsoleted by an IETF document that points to the First IEEE 1588 YANG module, or simply moved to historic. While we can certainly figure this mechanism out when the time comes for a transfer, it would probably make such a transfer more smooth if the documented plan included a proposed process for the formal sunsetting of the IETF document.
I've cleared my discuss, since the discussion I wanted to make sure happened has happened. I'm copying it below for reference purposes: <old-discuss> §2 contains the following paragraph: " The readers are assumed to be familiar with IEEE 1588-2008. As all PTP terminologies and PTP data set attributes are described in details in IEEE 1588-2008 [IEEE1588], this document only outlines each of them in the YANG module." If I understand correctly, IEEE 1588-2008 is not available without payment. If so, then I don't see how we can assume that reviewers of this draft are actually familiar with IEEE 1588-2008. It seems like that makes it hard for the draft to get sufficient review to be considered a standards-track IETF consensus document. I recognize that we do not have a policy against normative references to paywalled sources, but I read the disclaimer to make the IEEE document more foundational than just any normative reference. </old-discuss> §1, 2nd bullet: "The YANG module of this document MAY be revised..." That seems more a statement of fact than permission. §2.2, definition of "static": If it "typically" doesn't change, does that mean it sometimes does change? -- 5th paragraph: "In such a case, an implementation MAY choose to return a warning upon writing to a read-only member" MAY seems week here; does it ever make sense to silently write to a read-only member? Appendix A: The appendix seems more like a liaison statement than something that belongs in an RFC defining a data model. Won't this become outdated whenever the change of control is (or is not) made? If it does need to go in an RFC, have people considered publishing it separately from the model?
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 ietf@ietf.org 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.)
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3264 I concur with Ben Campbell's DISCUSS. COMMENTS S 1. > 2008. > > 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 Nit: this looks like it's more a statement of fact than normative langauge. S 1. > dedicated YANG module for its profile. The profile's YANG module > SHOULD use YANG "import" to import the IEEE 1588-2008 YANG module > as its foundation. Then the profile's YANG module SHOULD use YANG > "augment" to add any profile-specific enhancements. > > o A product that conforms to a profile standard can also create Is the "can" in this statement different from the "may" in the previous bullet. S 7. > create derivative works from this document. Those IEEE forms and > mechanisms will be updated as needed for any future IETF YANG > modules for IEEE 1588 (The signed forms are held by the IEEE > Standards Association department of Risk Management and Licensing.). > This will help to make the future transfer of work from IETF to > IEEE occur as smoothly as possible. I don't mean to be overly legal, but why is it that you think that the named authors consent is what's relevant here as opposed to the IETF, or everyone who has submitted text?
Original DISCUSS notes for the record: Discuss (2018-10-11 for -10) The model was not reviewed by YANG doctors, at least there is no record of such review. It should be, especially given the subject area of the model is not a native IETF technology.