Martin, Thank a lot for your instantly reply. Please see my further comments inline.
Cheers, Yuanlong -----Original Message----- From: Martin Bjorklund [mailto:[email protected]] Sent: Thursday, September 28, 2017 9:23 PM To: Jiangyuanlong Cc: [email protected]; [email protected]; [email protected] Subject: Re: [netmod] draft-ietf-tictoc-1588v2-yang-05 - Concern over port identifier Jiangyuanlong <[email protected]> wrote: > Sean, > > My personal opinion is that it can work, but I would like to ask for > more opinions from our netmod experts;) > > Hi netmod experts, > Considering the following sample module, my-list is a list, and it > needs to use a leaf member "port-number" in my-port-container as a > key. > We now have 3 options: > 1. > list my-list { > key "port-number"; > leaf port-number { > type uint16; > } > > container my-port-container { > leaf port-number { > type uint16; > } > leaf other-leaf { > ... > } > } > } > But this does not work for there is compiling error. Why wouldn't this work? [JY] The original intention of the 1588 info model is to use my-port-container.port-number as the key. The code actually parses, but we need to synchronize my-list.port-number and my-list.my-port-container.port-number all the while. I suspect you meant: list my-list { key "port-number"; container my-port-container { leaf port-number { type uint16; } leaf other-leaf { ... } } } > 2. > list my-list { > key "port-number"; > leaf port-number { > type uint16; > } > container my-port-container { > leaf port-number { > type leafref{ > path "../../port-number"; > } > } > leaf other-leaf { > ... > } > } > } > Option 2 can parse, though leafref in a sub-module seems not very > natural. > > 3. > list my-list { > key "port-number"; > leaf port-number { > type leafref{ > path "../my-port-container/port-number"; > } > } > container my-port-container { > leaf port-number { > type uint16; > } > leaf other-leaf { > ... > } > } > } > > Option 3 can also parse, though leafref seems not a very natural key. > What is your favorite option? Or do you have any better schemes? Having a leafref like in option 2 or 3 is just redundant and a hassle for the client. In order to create a a list entry, the client would have to first provide the port-number value once for the key, and then again the exact same value in the container: <my-list> <port-number>25</port-number> <my-port-container> <port-number>25</port-number> <other-leaf>...</other-leaf> </my-port-container> </my-list> Note that both "port-number" MUST be given the exact same value by the client. In YANG, key leafs cannot be nested under containers. I would simply have the key on the top of the list, and not in the container. (It seems this is what others have proposed as well in this thread.) [JY] Yes, I agree that this model is not very elegant, but the info model was published in IEEE 1588 already, people have been used to this info model for a long time and we would like to stick to it as far as we can. As an alternative, option 2 can be enhanced: list my-list { key "port-number"; leaf port-number { type uint16; } container my-port-container { leaf port-number { type leafref{ path "../../port-number"; } config false; } leaf other-leaf { ... } } } In this way, the "config false" makes the leafref read-only, so that configuration doesn't need to write twice. How do you think about this scheme? Thanks again, Yuanlong /martin > Your opinions are very important for our revision of this draft. > > Thanks, > Yuanlong > > > From: Sean Condon [mailto:[email protected]] > Sent: Wednesday, September 27, 2017 7:11 PM > To: Jiangyuanlong > Cc: [email protected]; Rodney Cummings > Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port > identifier > > Thanks guys for your responses. > > I accept your points to keep the structure as aligned to the IEEE 1588 > standard as possible. > > One alternate suggestion that I would make, is that the port-number > currently defined as leafref should be made the real attribute (i.e. > uint16) and that the port-number inside port-identity container should > be made in to the leaf ref (and set to mandatory true). > > The reason I say this is that > > 1. XML models are usually navigated and constructed root-to-leaf, and > the way it's portrayed at the moment is that port-number leafref > points to something that may not exist at the time it is being > defined. This makes it difficult to implement. > 2. Also port-identity/port-number is not "mandatory true" meaning > that it could be left out altogether. It's not valid for it to have a > default value either since every item in the list will need a > different identifier. > > With this suggestion the structure you require with port-identity > still exists, but now the implementation is more straightforward, and > the change will be transparent to an end user. > > > Best regards, Sean > ======================= > Sean Condon > System & Software Architect > Frequency & Timing Division > Microsemi Inc. > [email protected]<mailto:[email protected]> > > ________________________________ > From: Jiangyuanlong [[email protected]] > Sent: 27 September 2017 08:05 > To: Sean Condon > Cc: [email protected]<mailto:[email protected]>; Rodney Cummings > Subject: RE: draft-ietf-tictoc-1588v2-yang-05 - Concern over port > identifier EXTERNAL EMAIL > > Dear Sean, > > > > Thank you a lot for diving into the technical details of this module. > Just as Rodney said, it is a challenge of 1588 info model to YANG, and > we use the leafref of YANG to work around it. > > I would like to provide a little more backgrounds on the tradeoff: > > > > 1. It says in Sec. 7.5.2.1 in IEEE 1588-2008: portIdentity is a member > of the portDS data set. A portIdentity consists of two attributes, as > > follows: > > ⎯ portIdentity.clockIdentity > > ⎯ portIdentity.portNumber > > Furthermore, the "portDS.portIdentity" attribute is mentioned quite a > few times in 1588-2008, especially in Table 17 and under Table 61, > with a hint that assignment and comparison can be done on this member > directly, thus it seems to me portIdentity is an important and well > understood construct in the 1588 specification. > > > > 2. If we change portDS.portIdentity from a container to a grouping, > then there is no portIdentity for portDS and transparentclockPortDS in > the resulting tree diagram: > > > > module: ietf-ptp-dataset > > +--rw instance-list* [instance-number] > > | +--rw instance-number uint16 > > | +--rw default-ds > > | | +--rw two-step-flag? boolean > > | | +--rw clock-identity? clock-identity-type > > | | +--rw number-ports? uint16 > > | | +--rw clock-quality > > | | | +--rw clock-class? uint8 > > | | | +--rw clock-accuracy? uint8 > > | | | +--rw offset-scaled-log-variance? uint16 > > | | +--rw priority1? uint8 > > | | +--rw priority2? uint8 > > | | +--rw domain-number? uint8 > > | | +--rw slave-only? boolean > > | +--rw current-ds > > | | +--rw steps-removed? uint16 > > | | +--rw offset-from-master? time-interval-type > > | | +--rw mean-path-delay? time-interval-type > > | +--rw parent-ds > > | | +--rw parent-port-identity > > | | | +--rw clock-identity? clock-identity-type > > | | | +--rw port-number? uint16 > > | | +--rw parent-stats? boolean > > | | +--rw observed-parent-offset-scaled-log-variance? uint16 > > | | +--rw observed-parent-clock-phase-change-rate? int32 > > | | +--rw grandmaster-identity? binary > > | | +--rw grandmaster-clock-quality > > | | | +--rw clock-class? uint8 > > | | | +--rw clock-accuracy? uint8 > > | | | +--rw offset-scaled-log-variance? uint16 > > | | +--rw grandmaster-priority1? uint8 > > | | +--rw grandmaster-priority2? uint8 > > | +--rw time-properties-ds > > | | +--rw current-utc-offset-valid? boolean > > | | +--rw current-utc-offset? int16 > > | | +--rw leap59? boolean > > | | +--rw leap61? boolean > > | | +--rw time-traceable? boolean > > | | +--rw frequency-traceable? boolean > > | | +--rw ptp-timescale? boolean > > | | +--rw time-source? uint8 > > | +--rw port-ds-list* [port-number] > > | +--rw clock-identity? clock-identity-type > > | +--rw port-number uint16 > > | +--rw port-state? port-state-enumeration > > | +--rw underlying-interface? if:interface-ref > > | +--rw log-min-delay-req-interval? int8 > > | +--rw peer-mean-path-delay? time-interval-type > > | +--rw log-announce-interval? int8 > > | +--rw announce-receipt-timeout? uint8 > > | +--rw log-sync-interval? int8 > > | +--rw delay-mechanism? delay-mechanism-enumeration > > | +--rw log-min-pdelay-req-interval? int8 > > | +--rw version-number? uint8 > > +--rw transparent-clock-default-ds > > | +--rw clock-identity? clock-identity-type > > | +--rw number-ports? uint16 > > | +--rw delay-mechanism? delay-mechanism-enumeration > > | +--rw primary-domain? uint8 > > +--rw transparent-clock-port-ds-list* [port-number] > > +--rw clock-identity? clock-identity-type > > +--rw port-number uint16 > > +--rw log-min-pdelay-req-interval? int8 > > +--rw faulty-flag? boolean > > +--rw peer-mean-path-delay? time-interval-type > > > > In contrast to the original 1588 YANG tree diagram: > > module: ietf-ptp-dataset > > +--rw instance-list* [instance-number] > > | +--rw instance-number uint16 > > | +--rw default-ds > > | | +--rw two-step-flag? boolean > > | | +--rw clock-identity? clock-identity-type > > | | +--rw number-ports? uint16 > > | | +--rw clock-quality > > | | | +--rw clock-class? uint8 > > | | | +--rw clock-accuracy? uint8 > > | | | +--rw offset-scaled-log-variance? uint16 > > | | +--rw priority1? uint8 > > | | +--rw priority2? uint8 > > | | +--rw domain-number? uint8 > > | | +--rw slave-only? boolean > > | +--rw current-ds > > | | +--rw steps-removed? uint16 > > | | +--rw offset-from-master? time-interval-type > > | | +--rw mean-path-delay? time-interval-type > > | +--rw parent-ds > > | | +--rw parent-port-identity > > | | | +--rw clock-identity? clock-identity-type > > | | | +--rw port-number? uint16 > > | | +--rw parent-stats? boolean > > | | +--rw observed-parent-offset-scaled-log-variance? uint16 > > | | +--rw observed-parent-clock-phase-change-rate? int32 > > | | +--rw grandmaster-identity? binary > > | | +--rw grandmaster-clock-quality > > | | | +--rw clock-class? uint8 > > | | | +--rw clock-accuracy? uint8 > > | | | +--rw offset-scaled-log-variance? uint16 > > | | +--rw grandmaster-priority1? uint8 > > | | +--rw grandmaster-priority2? uint8 > > | +--rw time-properties-ds > > | | +--rw current-utc-offset-valid? boolean > > | | +--rw current-utc-offset? int16 > > | | +--rw leap59? boolean > > | | +--rw leap61? boolean > > | | +--rw time-traceable? boolean > > | | +--rw frequency-traceable? boolean > > | | +--rw ptp-timescale? boolean > > | | +--rw time-source? uint8 > > | +--rw port-ds-list* [port-number] > > | +--rw port-number -> ../port-identity/port-number > > | +--rw port-identity > > | | +--rw clock-identity? clock-identity-type > > | | +--rw port-number? uint16 > > | +--rw port-state? port-state-enumeration > > | +--rw underlying-interface? if:interface-ref > > | +--rw log-min-delay-req-interval? int8 > > | +--rw peer-mean-path-delay? time-interval-type > > | +--rw log-announce-interval? int8 > > | +--rw announce-receipt-timeout? uint8 > > | +--rw log-sync-interval? int8 > > | +--rw delay-mechanism? delay-mechanism-enumeration > > | +--rw log-min-pdelay-req-interval? int8 > > | +--rw version-number? uint8 > > +--rw transparent-clock-default-ds > > | +--rw clock-identity? clock-identity-type > > | +--rw number-ports? uint16 > > | +--rw delay-mechanism? delay-mechanism-enumeration > > | +--rw primary-domain? uint8 > > +--rw transparent-clock-port-ds-list* [port-number] > > +--rw port-number -> ../port-identity/port-number > > +--rw port-identity > > | +--rw clock-identity? clock-identity-type > > | +--rw port-number? uint16 > > +--rw log-min-pdelay-req-interval? int8 > > +--rw faulty-flag? boolean > > +--rw peer-mean-path-delay? time-interval-type > > > > I agree, assignment and comparison can still be done on clock-identity > and port-number directly (without a portIdentity construct) . But > people who are familiar with 1588-2008 may question where portIdentity > is gone. > > > > 3. I think leafref is a very general semantics thing in YANG language, > if any tools have problem with this feature, maybe we need to contact > with the tool’s developer to support it. > > > > Finally, more inputs from the WG are welcome. > > > > Thanks again, > > Yuanlong > > > > > > -----Original Message----- > From: TICTOC [mailto:[email protected]] On Behalf Of Rodney > Cummings > Sent: Wednesday, September 27, 2017 1:24 AM > To: [email protected]<mailto:[email protected]> > Subject: Re: [TICTOC] draft-ietf-tictoc-1588v2-yang-05 - Concern over > port identifier > > > > Thanks Sean, > > > > Regarding your other comment on TLD... I agree. > > > > Regarding the comment below on port-identity, I agree that we need to > do it for practical reasons. > > > > In 1588-2008, there is a distinct dataset member for > portDS.portIdentity, which 5.3.5 specifies as using type PortIdentity: > > struct PortIdentity { > > ClockIdentity clockIdentity; > > UInteger portNumber; > > } > > > > If we interpret the 1588-2008 datasets as an information model, and > apply that as directly as possible to a YANG data model, > portDS.portIdentity is a container, which is what we have so far. That > introduces a challenge, because we want to use > portDS.portIdentity.portNumber as the key to the list of portDS's. We > solved that challenge with a leafref, but I'd agree that is ugly. > > > > Your proposal changes portDS.portIdentity from a container to a > grouping, so that it portDS.portIdentity.portNumber can be used as the > key without a leafref. > > > > The downside is that if/when a YANG management client tries to "get" > portDS.portIdentity, it doesn't work... there is no portIdentity to > get. > > > > Personally, I think that downside is worth it. One can argue that your > proposal still conforms to the 1588-2008 information model for > management, in that portDS.portIdentity still "exists" in a manner > that makes sense for YANG. > > > > Rodney > > > > > > > > From: TICTOC [mailto:[email protected]] On Behalf Of Sean Condon > > Sent: Tuesday, September 26, 2017 10:38 AM > > To: [email protected]<mailto:[email protected]> > > Subject: [TICTOC] draft-ietf-tictoc-1588v2-yang-05 - Concern over port > identifier > > > > With reference to "YANG Data Model for IEEE 1588v2" > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_ht > ml_draft-2Dietf-2Dtictoc-2D1588v2-2Dyang-2D05&d=DwMFAw&c=I_0YwoKy7z5LM > TVdyO6YCiE2uzI1jjZZuIPelcSjixA&r=WA71sf2o7Dw7CbYhFt24DPjt3lJuupswWYdnb > oKbZ8k&m=jKHczVNLN-KuV2HRZkbEZY1SzlCD_AztkaWSccrqBI8&s=msh7A7_OgHZ1l65 > Dn6_LhiDIXkXpFeiLGmKbKxsqXWw&e= > > > > I have a concern about the structure of the YANG, and how the lists > port-ds-list and transparent-clock-port-ds-list are indexed with a > leaf which is a leafref. > > > > The structure seems unnecessarily complex - port-number is represented > as a leaf directly beneath the list (to be used as key) and again > under the port-identity container. It is structured in a way that I > believe would make it difficult to work with some YANG tools in the > market. > > > > The purpose of port-identity container is not clear from the document > - it would achieve the same purpose if it was left out of > port-ds-entry and transparent-clock-port-ds-entry and instead the > grouping port-identity-grouping included directly. > > > > See the attached files as original, a modified version and as a patch > file. > > > > Sean Condon > > ======================= > > Sean Condon > > System & Software Architect > > Frequency & Timing Division > > Microsemi Inc. > > mailto:[email protected] > > > > _______________________________________________ > > TICTOC mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/tictoc _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
