[TICTOC] Ben Campbell's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-tictoc-1588v2-yang-10: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a process discuss, or maybe a discuss discuss. I expect to clear it
once a discussion has occurred regardless of the outcome, but I want to make
sure the discussion happens.

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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