Hi Adam, Thanks much for the review and comments, please see my replies prefixed with [YJ].
Regards, Yuanlong > -----Original Message----- > From: Adam Roach [mailto:[email protected]] > Sent: Thursday, October 11, 2018 12:30 PM > To: The IESG > Cc: [email protected]; Karen O'Donoghue; > [email protected]; [email protected]; [email protected] > Subject: Adam Roach's No Objection on draft-ietf-tictoc-1588v2-yang-10: > (with COMMENT) > > Adam Roach has entered the following ballot position for > draft-ietf-tictoc-1588v2-yang-10: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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. > [YJ] According to https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-20, Section 3.4: "If YANG tree diagrams are used, then an informative reference to the YANG tree diagrams specification MUST be included in the document." My interpretation is, a tree diagram only helps a reader to understand the overall structure of a YANG module, but not a piece of YANG module by itself, and an implementation does not need to include it in the actual YANG codes, thus the tree diagram is only informational, and the same also applies to this 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? > [YJ] I have not heard of any implementation that falls out of this common case yet. If there is such an implementation, the YANG "deviate" mechanism can still be used, though the value of standardizing this option is much in doubt as the implementation will deviate much from the documented module. > --------------------------------------------------------------------------- > > 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. > [YJ] Just as Karen and Rodney said in their emails, it is more appropriate to refer to the IEEE 1588 recommendation for IEEE 1588 terms rather than redefine these terms in the IETF. Here I would like to explain the terms you are concerned in some more details (though still incomplete): priority1: a value indicates the order of a clock in the selection of clocks, a clock with a lower value of priority1 takes precedence over a clock with a greater value of priority1. priority2: a value indicates a finer grained order of a clock among otherwise equivalent clocks. That is, if it fails to order the clocks based on the values of priority1 and clock-quality (including clock-class, clock-accuracy, and offset-scaled-log-variance), priority2 provides a tiebreaker. clock-quality: a composite attribute which represents the quality of a clock, it includes clock-class, clock-accuracy, offset-scaled-log-variance. > --------------------------------------------------------------------------- > > 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, [YJ] this is the purpose of this draft. > obsoleted by an IETF document that points to the First IEEE 1588 YANG > module, [YJ] needs to transfer IEEE 1588 YANG back to the IETF? I think that requires a different procedure, and seems not likely to happen in the near future. > 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. > [YJ] The intention of this Appendix is to help transferring this specific document, not targeted as a generic guideline for other transfer tasks. My interpretation is that after the transfer of this module to IEEE 1588 WG, participants there will develop YANG modules for newer revisions of IEEE 1588 (such as V2.1) on their own, while this module will still be valid for IEEE 1588-2008 for a long run (IEEE 1588 has no sunsetting yet, and both IEEE 1588-2002 and IEEE 1588-2008 are valid recommendations). If a generic transfer process is pursued, especially if a separate document is to be developed based on this Appendix, I believe a wider scope of audiences and more discussions will be needed, as sunsetting depends heavily on the expiration of a basic standard in another specific SDO. _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
