[TICTOC] Adam Roach's No Objection on draft-ietf-tictoc-1588v2-yang-10: (with COMMENT)

[Adam Roach <[e-mail]>]

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.

---------------------------------------------------------------------------

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