Some containers have restrictive names
Closed this issue · 2 comments
Three of the new container-level objects defined for this RP imply they can only be used for monitoring:
- gnss-monitoring-ds
- st-2059-2-monitoring-ds
- grand-master-monitoring-ds
I understand that the scope of the RP is to "specify only state of the data set for monitoring purposes and do not include specifications for notifications or configuration". However, I think the intent is to allow implementations to re-use the same containers for those purposes if they wish. Vendors are free to not limit objects to read-only status (i.e. "config: false" in the YANG model). If that is the case, then I recommend that "monitoring" not be included in the container name. (I.e. change to "gnss-ds", "st-2059-2-ds" and "grandmaster-ds" respectively).
For example, there is no object in the /ptp tree for configuration of the communication model, but st-2059-2-monitoring-ds includes a smpte-communication-model leaf node. If a vendor requires a writable management object to set the communication model to one of multicast, smpte-mixed, etc. then the two options would be to allow read/write access to this "monitoring" object. or create a new vendor-specific container and object.
The fourth new container (rfc-8173-ds) would not need to be renamed.
The agreed proposed solution is to change the container names in both the Data Model and the RP to:
gnss-ds
st-2059-2-ds
grandmaster-ds
Resolved in PCD2, container names changed in the Data Model and RP