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

From: Ben Campbell <[email-masked]>
Date: Wed, 10 Oct 2018 13:43:53 -0700

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?

---

From: Jiangyuanlong <[email-masked]>
Date: Thu, 11 Oct 2018 09:16:00 +0000

Ben, 

Thanks much for the review and the opinions, please see my replies prefixed with [JY].

Regards,
Yuanlong

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, October 11, 2018 4:44 AM
> To: The IESG
> Cc: [email-masked]; Karen O'Donoghue;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's Discuss on draft-ietf-tictoc-1588v2-yang-10: (with
> DISCUSS and COMMENT)
> 
[YJ] I realized that most IEEE standards needs to be bought or accessed via subscription (such as 802.1, 802.3 and etc). Most SDOs will keep their documents in development only internally available. In such a case, one typical cooperation mechanism between SDOs is via official liaisons, for example, a document from a SDO (whether it is published or not) can be liaised to another SDO for reviews. Maybe we can establish such a relationship at an early stage next time so that IETF reviews can be more smooth.

[YJ] agreed, to align with these bullets, "MAY" will change to "may", and "can" in bullet 4 will also change to "may" for consistency. 

> week here; does it ever make sense to silently write to a read-only member?
[YJ] "MAY" will change to "SHOULD".

> RFC, have people considered publishing it separately from the model?
[YJ] My opinion is: the appendix can be published alone, similar to RFC 4663. But I'd like to hear more opinion from my coauthor Rodney on this issue, as he contributed most materials in this appendix.

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 11 Oct 2018 12:19:18 +0000

Hi Ben,

I’d like to take a moment to respond to your DISCUSS comment below as both working group chair of TICTOC and also as a participant in the IEEE 1588 working group. 

I understand the desire for open access to standards, and the distaste for paywalls that limit that access. However, I also believe that there are sometimes reasons where we should be a bit more flexible in our approach. 

IEEE 1588 is not part of the IEEE 802 family of activities and is therefore not currently covered under the “Get IEEE 802” program (https://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68) that provides open access to completed IEEE 802 specifications. It is a small working group focused specifically on precision time synchronization with much more limited resources than either IEEE 802 or the IETF. This was a cooperative effort between the IEEE 1588 working group and the IETF TICTOC working group to leverage IETF expertise in YANG to provide a missing capability to IEEE 1588. The original solution in IEEE 1588 was a custom management protocol, and the TICTOC working group in collaboration with the IEEE 1588 working group developed a MIB module and now a YANG module as a way to help provide a more secure and standardized management solution to IEEE 1588. As the IEEE 1588 community gathers additional resources and expertise, it is expected that this work will transition to them. Additionally the IEEE liaison to the IETF has been closely following and assisting this activity (and the predecessor MIB effort). 

In this case, while the language could perhaps have been a bit more precise, the point of the statement in the document is that this is a Yang module that specifically represents the IEEE 1588 v2 specification. Therefore terminology and objects being represented therein are already defined elsewhere so one should not expect to redefine them in this specification. I believe this is in line with any MIB or YANG module - they represent what they model. Working group members were provided with copies of the specification if they did not already have other means to get it. In fact, anyone who wanted access in order to do a review could have requested a copy, and we could have made arrangements for that (perhaps I should have made this more clear up front). 

While I know this doesn’t really solve the broader issue of open access to standards, I hope it better explains the context for this specific document. 

Regards,
Karen

> On Oct 10, 2018, at 4:43 PM, Ben Campbell <[email-masked]> wrote:
>