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

[Karen O'Donoghue <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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?
> 
>