Tom, Please see my comments inline with [YJ].
Thanks again, Yuanlong -----Original Message----- From: t.petch [mailto:[email protected]] Sent: Tuesday, July 03, 2018 5:11 PM To: Jiangyuanlong <[email protected]>; [email protected] Cc: [email protected]; Dave Thaler <[email protected]>; ZHAO, WILLIAM <[email protected]> Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt Here are some more thoughts from looking at the body of YANG module (some may reflect the fact that I have not accessed IEEE Std 1588-2008:-) I see now that you say in s.3 you import the YANG 1.1 version of ietf-interfaces, RFC8343, which means that this module must be yang-version 1.1; In which case, I think that your references to RFC6020 in the body of the document should be to RFC7950 [YJ] We will consider changing several references to RFC7950. Both references are included already, and I must say most materials used in this document are accommodated by both RFC 6020 and 7950. You have lots of references - good - but do not use the YANG reference statement - I think this ok, if not the usual practice. [YJ] This module only imports ietf-interfaces, and we will add a reference sentence for it in the next version You have no examples, which sometimes get asked for by such as the IESG, YANG doctor and such like - they are nice to see if tedious and error prone to create. [YJ] there is an example on how to augment this module in an ONF PoC project: https://github.com/OpenNetworkingFoundation/CENTENNIAL/tree/master/models/yang/onf-ptp-dataset.yang, Of course, we can add one or two appendix into the document if requested. leaf grandmaster-identity { type binary { length "8"; why binary and not type clock-identity-type? In passing I am curious about the choice of binary length 8 as opposed to uint8; not wrong, just something that strikes me. [YJ] binary length 8 is actually Octet[8] in IEEE 1588, not uint8. Yes, it is also of type clock-identity-type, will change it. leaf current-utc-offset { what are the units? [YJ] in seconds. should there be a default or should there be something to indicate an invalid value i.e. can leaf current-utc-offset-valid { get set to true before there is a valid value in the offset in which case a value of e.g. infinity would alert the user to this condition. [YJ] not in the original IEEE 1588-2008, according to 1588-2008, its initialization is complicated and dependent on primary reference or the time when the node is designed: "The initialization value shall be selected as follows: a) If the timePropertiesDS.ptpTimescale (see 8.2.4.8) is TRUE, the value is the value obtained from a primary reference if the value is known at the time of initialization, else. b) The value shall be the current number of leap seconds (7.2.3) when the node is designed." Thus, if leaf current-utc-offset-valid is set to TRUE, then leaf current-utc-offset must be set accordingly by PTP protocols or manually. .. leaf time-source { type uint8; description "The source of time used by the grandmaster clock."; How does a uint8 tell me the source? What namespace is this uint8 in? [YJ] the value represents a category of time source enumeration, such ATOMIC_CLOCK, GPS and etc. See Table 7 of IEEE1588 for details. I see that there are no notifications; might events such as ...occurrence of the event ANNOUNCE_RECEIPT_TIMEOUT_ EXPIRES."; ever generate notifications? [YJ] interestingly, service providers have shown little interest in event notifications during the development of this draft (perhaps because events are mostly transient). BTW, some of the events are implementation specific, or dependent on the BMCA used. Thus, event notification is out of our radar. primary syntonization domain I cannot find 'syntonization'in my dictionary [YJ] syntonization is defined in Section 12.1. My understanding is, a TC may have multiple frequency sources (clocks), and it needs to syntonize to the primary clock (i.e., the grandmaster). Section 10.1 of IEEE1588: "For clocks implementing syntonization, the term "primary syntonization domain" is defined to be domainNumber 0, or if the default is configured to a new domain, the configured default domain." I wonder about 'when set' which appears in many places; I infer this is when set to true, which I would spell out (although others take this for granted). [YJ] OK. Tom Petch ----- Original Message ----- From: "Jiangyuanlong" <[email protected]> To: "t.petch" <[email protected]>; <[email protected]> Cc: <[email protected]>; "Dave Thaler" <[email protected]>; "ZHAO, WILLIAM" <[email protected]> Sent: Tuesday, July 03, 2018 7:50 AM Dear Tom, Many thanks to your thorough review and thoughtful comments. We will update the draft accordingly. Cheers, Yuanlong -----Original Message----- From: t.petch [mailto:[email protected]] Sent: Monday, July 02, 2018 11:40 PM To: Jiangyuanlong <[email protected]>; [email protected] Cc: [email protected]; Dave Thaler <[email protected]>; ZHAO, WILLIAM <[email protected]> Subject: Re: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt It's been a while and YANG moves on:-( I think that you need some changes to the YANG module for which draft-ietf-netmod-rfc6087bis is your friend while other issues have surfaced as IESG comments at IESG Review Abstract needs to say if the module is NMDA compliant You have lower case 'may' and there is now revised boiler plate to cater for this in RFC8174 YANG Tree diagrams is now RFC8340 and the expectation is that you have an Informative Reference to that and include no further explanation in the I-D The RFC Editor would appreciate a Note asking them to update the two dates in the YANG module to date of publication import ietf-interfaces lacks a reference to the RFC. If this is 8343, which is YANG 1.1, then this module must specify YANG 1.1 as version number. The YANG module needs a Copyright which will include a reference to XXXX, the number assigned to the I-D on publication. The RFC Editor would appreciate a Note asking them to replace all occurrences of XXXX with the published number (the RFC Editor told me that they like this Note at the start of the ID as opposed to tucked away on each occurrence). The revision should say 'Initial Revision' contact should be editor and author not WG Chair Security Considerations needs to identify which objects are sensitive or say that none are. The RFC listed in Security Considerations need to be Normative; there is a wiki section this. IANA Considerations lacks detail, such as the RFC XXXX, Registrant Contact etc Tom Petch ----- Original Message ----- From: "Jiangyuanlong" <[email protected]> Sent: Monday, July 02, 2018 4:50 AM Hi experts, As there have been quite a few comments raised during the Last Call process and in the Intdir early review stage, we have produced this new version with all the suggestions and resolutions incorporated. A summary of the changes introduced in this document: 1. According to IEEE 1588 and per the discussions in the mailing list, we changed two attribute members to "config false" in the YANG module (default-ds. clock-identity and transparent-clock-default-ds. clock-identity), i.e., they are changed to read-only. It seems YANG has a requirement that if a leaf key is config false, then its container list must also be config false. Otherwise, the parser will not pass. Therefore, key "port-number" in both list port-ds-list and list transparent-clock-port-ds-list remain writable. 2. As noted in the mailing list, leaf member "clock-identity" is removed from transparent-clock-port-ds-list (since portIdentity.clockIdentity is already provided as the clock-identity leaf in transparent-clock-default-ds). 3.The last paragraph of Section 2.2 is updated to: "Under certain circumstances, the classification of an IEEE 1588 data set member may change for a YANG implementation, for example, a configurable member needs to be changed to read-only. In such a case, an implementation MAY choose to return a warning upon writing to a read-only member, or use the deviation mechanism to develop a new deviation model as described in Section 7.20.3 of [RFC7950]." We hope the new texts make it clear how an implementer may change the behavior of YANG attributes in practice. 4. we added references to [IEEE1588] for terms BC, OC and TC as commented by Dave. 5. RFC7950 is added as a normative reference; since two RFC references are obsoleted, we updated them with their newest version (i.e., RFC 8341 and RFC 8343). 6. we add editorial improvements as our reviewers proposed, and use RFC2119 key words in several sentences in Section 1 and Section 2.2. In fact, the main technical changes were already presented in the last IETF meeting, the new changes are mostly editorial. Thanks a lot to our reviewers! Further reviews and opinions will be appreciated. Thanks, Yuanlong on behalf of all co-authors -----Original Message----- From: TICTOC [mailto:[email protected]] On Behalf Of [email protected] Sent: Monday, July 02, 2018 10:52 AM To: [email protected] Cc: [email protected] Subject: [TICTOC] I-D Action: draft-ietf-tictoc-1588v2-yang-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Timing over IP Connection and Transfer of Clock WG of the IETF. Title : YANG Data Model for IEEE 1588-2008 Authors : Yuanlong Jiang Xian Liu Jinchun Xu Rodney Cummings Filename : draft-ietf-tictoc-1588v2-yang-08.txt Pages : 30 Date : 2018-07-01 Abstract: This document defines a YANG data model for the configuration of IEEE 1588-2008 devices and clocks, and also retrieval of the configuration information, data set and running states of IEEE 1588-2008 clocks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588v2-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tictoc-1588v2-yang-08 https://datatracker.ietf.org/doc/html/draft-ietf-tictoc-1588v2-yang-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tictoc-1588v2-yang-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
