Re: [netmod] +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
Dear Tom, Good suggestion, we will adding this note of references at the beginning of Section 3. Cheers, Yuanlong -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Friday, November 10, 2017 1:48 AM To: Jiangyuanlong; Alex Campbell; tic...@ietf.org Cc: Xian Liu; Xujinchun; netmod@ietf.org Subject: Re: +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 - Original Message - From: "Jiangyuanlong" Sent: Thursday, November 09, 2017 1:58 AM Tom, Good to know all your viewpoints. We will add a sentence in Section 2 explaining the logic of YANG style names in this document, maybe put it as a note in the 2nd paragraph (as these names are used in the 3rd paragraph) . Yuanlong, Another belated thought. It is common practice, and I think a good one, to include a sentence just before the YANG module giving Normative references to other RFC andsuch like that are referenced, implicitly or explicitly, in the module itself (which, of course, cannot contain the references in the same way that the rest of the RFC can). The sentence does not become part of the YANG module but anyone harking back to the RFC will quickly find where to go for more information. draft-ietf-netmod-rfc7277bis-00 gives a good example of this. For this I-D, I would suggest references to IEEE Std 1588-2008 and the RFC from which ietf-interfaces is imported. Tom Petch Thanks, Yuanlong -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Wednesday, November 08, 2017 9:12 PM To: Jiangyuanlong; Alex Campbell; tic...@ietf.org Cc: Xian Liu; Xujinchun; netmod@ietf.org Subject: Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 Yuanglong I think that your Introduction is fine, and would not shorten it at all. (I think that the Introduction to most I-Ds that describe YANG modules is woefully weak). I think too that you are spot on with your terminology; where IEEE 1588-2008 has an accepted way of working, then that is the right way for this I-D. One fresh comment arising from that. You commented earlier that you had departed from IEEE 1588-2008 in changing camel case to the YANG style names, with hyphens, and I think that that is a logical choice. But I would go further and explain that choice so that those coming from IEEE 1588-2008 understand what has happened and why. Not sure where to put that; probably Section 2, perhaps immediately before the tree diagram, since that is when readers will be exposed to the issue. If you have done more than just change the style of name, then it would be worth having a concordance of IEEE 1588-2008 names and YANG names; this was common practice with MIB Modules. Tom Petch - Original Message - From: "Jiangyuanlong" To: "Alex Campbell" ; Cc: "Xian Liu" ; "Xujinchun" ; Sent: Tuesday, November 07, 2017 7:53 AM Subject: Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 > Hi Alex, > > Sorry for a late reply as I spent the last week for an urgent business trip. > Please see my comments in line with [YJ] > > Thanks, > Yuanlong > > -Original Message- > From: Alex Campbell [mailto:alex.campb...@aviatnet.com] > Sent: Monday, October 30, 2017 10:15 AM > To: Jiangyuanlong; tic...@ietf.org > Cc: Xian Liu; Xujinchun; netmod@ietf.org > Subject: Re: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 > > Hi, > I've reviewed this latest draft and have some more comments. > > 1. I find the introduction to be unnecessarily wordy; it feels like it was written with a view of not missing any information out, rather than trying to keep it concise. >For example, there is no need to elaborate on YANG data types here. It is also not here to sell YANG. > > [YJ] Yes, we are trying to give some introductory information for an outsider who may not be familiar with PTP or YANG, and explain why a YANG for PTP is needed. The juicy part of this document is its YANG module, and people can skip all the other texts if they are familiar with PTP and YANG. > Besides, these texts have been contributed by multiple sources and undergone several rounds of reviews, thus I will wait for a clear message from the TICTOC chairs to introduce any big changes at this last call stage. > > > OLD: > >As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely >supported in the carrier networks, industrial networks, automotive >networks, and many other applications. It can provide high >precision time synchronization as fine as nano-seconds. The >protocol depends on a Precision Time Protocol (PTP) engine to >decide its own state automatically, and a PTP transportation layer >to carry the PTP timing and various quality messages. The >configuration parameters and state data sets of IEEE 1588-2008 are >numerous. > >According to the concepts described in [RFC3444], IEEE 1
Re: [netmod] +AFs-netmod+AF0- WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06
- Original Message - From: "Jiangyuanlong" Sent: Thursday, November 09, 2017 1:58 AM Tom, Good to know all your viewpoints. We will add a sentence in Section 2 explaining the logic of YANG style names in this document, maybe put it as a note in the 2nd paragraph (as these names are used in the 3rd paragraph) . Yuanlong, Another belated thought. It is common practice, and I think a good one, to include a sentence just before the YANG module giving Normative references to other RFC andsuch like that are referenced, implicitly or explicitly, in the module itself (which, of course, cannot contain the references in the same way that the rest of the RFC can). The sentence does not become part of the YANG module but anyone harking back to the RFC will quickly find where to go for more information. draft-ietf-netmod-rfc7277bis-00 gives a good example of this. For this I-D, I would suggest references to IEEE Std 1588-2008 and the RFC from which ietf-interfaces is imported. Tom Petch Thanks, Yuanlong -Original Message- From: t.petch [mailto:ie...@btconnect.com] Sent: Wednesday, November 08, 2017 9:12 PM To: Jiangyuanlong; Alex Campbell; tic...@ietf.org Cc: Xian Liu; Xujinchun; netmod@ietf.org Subject: Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 Yuanglong I think that your Introduction is fine, and would not shorten it at all. (I think that the Introduction to most I-Ds that describe YANG modules is woefully weak). I think too that you are spot on with your terminology; where IEEE 1588-2008 has an accepted way of working, then that is the right way for this I-D. One fresh comment arising from that. You commented earlier that you had departed from IEEE 1588-2008 in changing camel case to the YANG style names, with hyphens, and I think that that is a logical choice. But I would go further and explain that choice so that those coming from IEEE 1588-2008 understand what has happened and why. Not sure where to put that; probably Section 2, perhaps immediately before the tree diagram, since that is when readers will be exposed to the issue. If you have done more than just change the style of name, then it would be worth having a concordance of IEEE 1588-2008 names and YANG names; this was common practice with MIB Modules. Tom Petch - Original Message - From: "Jiangyuanlong" To: "Alex Campbell" ; Cc: "Xian Liu" ; "Xujinchun" ; Sent: Tuesday, November 07, 2017 7:53 AM Subject: Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 > Hi Alex, > > Sorry for a late reply as I spent the last week for an urgent business trip. > Please see my comments in line with [YJ] > > Thanks, > Yuanlong > > -Original Message- > From: Alex Campbell [mailto:alex.campb...@aviatnet.com] > Sent: Monday, October 30, 2017 10:15 AM > To: Jiangyuanlong; tic...@ietf.org > Cc: Xian Liu; Xujinchun; netmod@ietf.org > Subject: Re: WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06 > > Hi, > I've reviewed this latest draft and have some more comments. > > 1. I find the introduction to be unnecessarily wordy; it feels like it was written with a view of not missing any information out, rather than trying to keep it concise. >For example, there is no need to elaborate on YANG data types here. It is also not here to sell YANG. > > [YJ] Yes, we are trying to give some introductory information for an outsider who may not be familiar with PTP or YANG, and explain why a YANG for PTP is needed. The juicy part of this document is its YANG module, and people can skip all the other texts if they are familiar with PTP and YANG. > Besides, these texts have been contributed by multiple sources and undergone several rounds of reviews, thus I will wait for a clear message from the TICTOC chairs to introduce any big changes at this last call stage. > > > OLD: > >As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely >supported in the carrier networks, industrial networks, automotive >networks, and many other applications. It can provide high >precision time synchronization as fine as nano-seconds. The >protocol depends on a Precision Time Protocol (PTP) engine to >decide its own state automatically, and a PTP transportation layer >to carry the PTP timing and various quality messages. The >configuration parameters and state data sets of IEEE 1588-2008 are >numerous. > >According to the concepts described in [RFC3444], IEEE 1588-2008 >itself provides an information model in its normative >specifications for the data sets (in IEEE 1588-2008 clause 8). Some >standardization organizations including the IETF have specified >data models in MIBs (Management Information Bases) for IEEE 1588- >2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are >typically focused on retrieval of state data using the Simple >Network Management Protocol
