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

From: Rodney Cummings <[email-masked]>
Date: Tue, 22 Sep 2015 12:34:44 -0500

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.

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.

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.

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

Thanks,

----------------------------
Rodney Cummings
National Instruments
Email: [email-masked]

---

From: Peter Meyer <[email-masked]>
Date: Thu, 24 Sep 2015 14:21:41 +0000

I would strongly support the proposal to split the proposed draft into two separate documents, as stated by Rodney below, between those datasets specified in IEEE1588-2008 and any proprietary or extension features.

Regards,
Peter

From: TICTOC [mailto:[email-masked]] On Behalf Of Rodney Cummings
Sent: Tuesday, September 22, 2015 1:35 PM
To: [email-masked]
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.

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.

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.

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

Thanks,

----------------------------
Rodney Cummings
National Instruments
Email: [email-masked]<mailto:[email-masked]>

---

From: Jiangyuanlong <[email-masked]>
Date: Fri, 25 Sep 2015 01:24:09 +0000

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:[email-masked]] On Behalf Of Rodney Cummings
Sent: Wednesday, September 23, 2015 1:35 AM
To: [email-masked]
Subject: [TICTOC] Comments on draft-jlx-tictoc-1588v2-yang

Hello,

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

JY: Totally agree.

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.

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

Thanks,