YANG Data Model for the Precision Time Protocol (PTP)
draft-ietf-tictoc-1588v2-yang-11

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.