Great comments John... thanks. I'll offer some opinion below.
As an introduction of sorts, although this YANG is limited to the published IEEE Std 1588-2008, some of the concepts from the ongoing 1588 revision are having a subtle effect. The reason is simple: When a YANG module is created for the 1588 revision (likely 1588-2018), ideally it can be done as a revision of this 1588-2008 YANG module, such that the YANG revision complies fully with RFC 7950 section 11. There's no guarantee that this will be possible, but so far it seems feasible by keeping the fundamental hierarchy consistent with 1588-rev, while continuing to limit its nodes to 1588-2008. > There are configurable attributes beyond those listed. For example: > attributes for the optional features of 1588-2008 clauses 16 and 17; the > sample period for variance estimation (clause 7.6.3.2) etc. These should > be included. 1588-2008 didn't have a clear definition of "configurable by management" beyond the 1588-based messages of 1588-2008 clause 15. There are plans to clarify that topic in 1588-rev by recommending that the 1588 data sets serve as an information model for management. That already has precedent for 1588-2008 (e.g. RFC8173 and this YANG I-D), so it seems like a safe recommendation as we move forward. That being said, you're correct that 1588-2008 specifies data sets for the optional features in clause 16 and 17. Nevertheless, in 1588-2008 those data sets are somewhat "disconnected" relative to the other data sets (i.e. overall management hierarchy). We're clarifying that topic in 1588-rev, so my slight preference would be to defer management of these features to the creation of a 1588-rev YANG revision. Nevertheless, one of the goals of this 1588-2008 YANG is to serve shorter-term needs, so if you have a specific optional feature that you need to manage in current 1588-2008 products, maybe we should add that to this I-D. As for the period for variance estimation in 7.6.3.2, that has no data set member in 1588-2008. I seem to recall discussion in the 1588 working group of making that period manageable (i.e. a data set member), but that was rejected, and thus far the draft of 7.6.3.2 hasn't changed from 1588-2008. If you feel strongly that this period should be manageable, I'd recommend that you submit a comment for the 1588 revision. If you are an IEEE-SA member, you can do that during sponsor ballot (probably 1Q2018). If not, feel free to write something up and I'd be happy to submit it for you. > I find it confusing that the hierarchy shown in section 2 has every node > as "rw" even though many are not configurable. Later, in section 2.2, > there is some explanation of this but I think a further note is needed > before the hierarchy diagram. Sounds good. > Section 2.1 says that "1588-2008 transparent clocks are domain > independent" but I don't think that is correct; transparent clocks have a > "primary syntonization domain". Correct. For the next draft, we can remove the "domain independent" language. That came from the NOTE in 1588-2008 subclause 8.3.1, and the concept isn't needed in this context. > instance-number description makes it sound like there is one PTP dataset > for each domain but I think the intention is one set of PTP datasets, the > set comprising default-ds, current-ds, parent-ds etc. However, I don't > see any reason to tie instances to domains. Instances seem to be > equivalent to clocks (one clock per instance). A device can contain > mulitple clocks and there is no requirement that all clocks in a device > are in different domains. Correct. 1588-2008 implied this "instance" concept, and 1588-rev makes it explicit. The intention is exactly as you describe. It is simply an instance of the PTP standard's specifications. Two instances might use different domainNumber, or the same domainNumber (e.g. two disjoint physical networks). I'll work with my co-authors to clarify this in the text. > I think it would help to have a definition of PTP Instance. A draft of > 1588-rev said: "A PTP Instance is one of the following: an Ordinary Clock, > a Boundary Clock, or a Transparent Clock". The yang model here seems to > be assuming that a Transparent Clock is not an instance. It would be > confusing to use a different definition of Instance than the one in 1588- > rev. An alternative would be to stick with the terminology of 1588-2008. Correct. I'll work with my co-authors to clarify this in the text. You found the issue that makes this tricky... transparent clock. As the 1588 group worked through the 1588 revision, the group decided to clarify that each "PTP Instance" (i.e. the explicit instance concept) operates on one-and-only-one domain. That's fine for ordinary clock and boundary clock, but it was controversial for transparent clock due to the preceding "domain independent" concept. Some transparent clock implementations operate on all domains, in that the timestamp in the message is changed regardless of what the domainNumber field contains. Some other transparent clock implementations operate like a "PTP Instance", in that they only change the message when the domainNumber field matches the domainNumber in the transparent clock's data sets. The intent of 1588-2008 was the "instance" way, but it wasn't clear, and now there are products in the field today that implement it both ways. If you take a look at the latest 1588-rev draft, you'll see the current consensus, which is to a) keep the original transparent clock data sets outside of the instance, to allow for domain-independent, but recommend against that implementation in the future, b) add more explicit specs for a transparent clock to be implemented using the instance data sets. I agree that the current hierarchy can be confusing (i.e. transparent clock outside of instance). Nevertheless, it seems to me that 1588-2008 itself is the source of that confusion, in that its transparent clock specs have been interpreted in contradictory ways. Since this YANG is for 1588-2008 only, I'd prefer to leave it somewhat open to interpretation according to 1588-2008 text, rather than bring up the changes coming in 1588-rev. I'd appreciate your thoughts on it. > number-ports description says "number of PTP ports on the device". We > probably need a definition of "device" here. You might think that because > default-ds is part of an instance, the members refer to the instance (e.g. > as clock-identity does). However, in the case of number-ports, it refers > to the device, where a device is the root scope for this model and can > contain more than one instance. Perhaps a root level node for nunber- > ports with default-ds/number-ports being a link to that would help. The 1588-rev draft currently specifies numberPorts as: "The attribute, numberPorts, shall indicate the number of PTP Ports on the PTP Instance." and PTP Port is currently defined as: "A logical access point of a PTP Instance for PTP Communications to the communications network." In other words, 1588's port is a logical entity that serves as the reference point for the 1588 instance. The 1588 standard tries to keep abstracted from "physical" ports (interfaces) as much as possible. In the YANG context, 1588 assumes that ietf-interface provides the list of physical ports (interfaces) in the product. The "underlying-interface" reference is intended to mean "Here's a reference to the physical interface used by this logical PTP port." I'd recommend that we change the number-ports description to "number of PTP ports on the instance". > Should there be a separate list of port-ds for each instance (as shown) or > should there be one list for the device? Given that port-identity > includes clock-identity, it would seem the intention is one list per > device. See above. The device's list is ietf-interfaces. > Regards, > John Fletcher Thanks again John. _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
