Re: [TICTOC] Comments on draft-jlx-tictoc-1588v2-yang

[Jiangyuanlong <[e-mail]>]

Hi Rodney,

Thank a lot for your expert review and detailed comments!
We also welcome you and others who have interest to join this work.
Please see further comments inline.

Best regards,
Yuanlong (on behalf of coauthors)


From: TICTOC [mailto:[e-mail]] On Behalf Of Rodney Cummings
Sent: Wednesday, September 23, 2015 1:35 AM
To: [e-mail]
Subject: [TICTOC] Comments on draft-jlx-tictoc-1588v2-yang

Hello,

I'm new to the TICTOC working group, but I would like to make some comments on the recent I-D for a YANG data model for IEEE 1588:
        https://datatracker.ietf.org/doc/draft-jlx-tictoc-1588v2-yang/

I would like to thank the authors for submitting this I-D. For many of us, the task of creating and editing YANG modules is new, so I really appreciate that the authors offered to start off YANG work for time synchronization.

JY: We are also new faces to TICTOC;) Thanks to the WG  for the platform and the openness.

As many of us know, there is currently no standard MIB for IEEE 1588. There are multiple MIBs created by various profile organizations, such as the IETF TICTOC MIB, and the IEEE 802.1AS MIB. Those MIBs were created at a time when the IEEE 1588 working group was not meeting regularly. As a result, there was relatively little coordination to ensure consistency among the MIBs. There is ongoing work in the IEEE 1588 Management subcommittee to specify a structure for IEEE 1588 MIBs. In my personal opinion, that IEEE 1588 work may not result in product success, because we already have the problem that many products exist in the field with the profile-specific MIBs. It is too late to turn back time to create a true IEEE 1588 MIB.

With YANG, we all have the opportunity to correct this fragmentation, and design modules for inheritance, so that IEEE 1588 features are represented, profile-specific features are represented, and product-specific features are represented. YANG is very well designed for this sort of structure.
JY: Totally agree.
With that goal in mind, I would suggest that the authors of the I-D separate their proposal into two separate I-Ds:
- 1588 I-D: This I-D represents the datasets specified in IEEE 1588-2008 (aka "v2"), and nothing more.
- Augment I-D: This I-D represents the features that the authors want beyond what is specified in the 1588-2008 standard.

The goal for the 1588 I-D is that it can serve as a starting point for the official IEEE 1588 YANG module. In my opinion, this 1588 YANG module will eventually be owned and controlled entirely by the IEEE 1588 working group (not IETF). Nevertheless, IETF TICTOC could possibly serve as a great place to start the work. The formalities among standards organizations can be handled at a later date. The important thing for now is to start the work and discussion.

The goal for the Augment I-D is to provide a place for some of the ideas that the authors entered into the v00 I-D. The goal is to specify a YANG augment in this I-D, using the 1588 I-D's YANG module as the foundation. I am not certain if the additional features make sense in the TICTOC context (e.g. maybe for the Enterprise profile), or if they are best done as product-specific features. By separating those features into a separate Augment I-D, we can consider those features as a distinct topic that is formally unrelated to IEEE 1588 data sets.
JY: Very good suggestions. The original I-D was targeted at routers. If we design the model in a wider scope, definitely a 1588 I-D is needed, and separate augment I-Ds for bridges and routers can then be ensued. I also agree that we should keep the ball rolling while the responsible SDO can be determined later.

The following lists some specific suggestions for section 5 of the v00 I-D to transform into a 1588 I-D:

1. Change the name of "query" to "dataset" or similar.
2. Move all RPC statements to the Augment I-D. YANG allows the leafs to be writable, so there is no need for RPC. 1588 does not specify RPC.
3. Change names of containers and leafs to more closely match the names in clause 8 of IEEE-2008 ("PTP data sets").
4. Remove leafs that are not in 1588-2008 from the 1588 I-D (and possibly move into the Augment I-D). This includes:
        - clock-default-DS: Remove quality-class, quality-accuracy,  quality-offset
        - clock-parent-DS-entry: Remove quality-class, quality-accuracy,  quality-offset
        - clock-running-entry: Remove this grouping and container
        - clock-port-entry: Remove this grouping and container
        - clock-port-running-entry: Remove this grouping and container
        - clock-port-associate-entry: Remove this grouping and container
        - clock-port-DS-entry: Remove min-delay-req-interval, peer-delay-req-interval, peer-mean-path-delay, grant-duration
5. Add leafs that are specified in clause 8 of IEEE-2008, but not the v00 I-D:
        - clock-default-DS: Add numberPorts, clockQuality
        - clock-parent-DS-entry: Add grandmasterClockQuality
        - clock-port-DS-entry: Add log-min-pdelay-req-interval

JY: These proposals look fine, and we will incoporate them into a new I-D for generic 1588 YANG model.

Thanks,

----------------------------
Rodney Cummings
National Instruments
Email: [e-mail]<mailto:[e-mail]>