ptp-transparent-clock-default-dataset: Wrong data type

[michbin]

Revision 2023-06-20 of the synchronization-1-0 Yang module defines that ptp-transparent-clock-default-dataset is a leaf of type ptp-transparent-clock-default-dataset which in turn is int64.

The data element (hopefully) represents the transparentClockDefaultDS data set defined in IEEE 1588 (section 8.3.2) which consists of 4 members describing properties of a transparent clock.

Therefore the data element should be a container which consists of leaves for those members we want to appear in the Yang model.

[PrathibaJee]

The datatype ptpTransparentClockDefaultDataset has a single attribute ,

As per the UML2YANG mapping guideline , dataTypes that contains one attribute will be translated into typedef.

So, the datatype “PtpTransparentClockDefaultDataset” is translated to a typedef and not a grouping.

typedef ptp-transparent-clock-default-dataset {
    type int64;
    description
      "none";
  }

This makes the attribute PtpSync_Pac/ptpTransparentClockDefaultDataset to a leaf of type PtpTransparentClockDefaultDataset and not a container.

leaf ptp-transparent-clock-default-dataset {
      type ptp-transparent-clock-default-dataset;
      mandatory true;
      description
        "The PTP status dataset of internal transparent clock of the NE.";
    }

[michbin]

Even if we go with a simplified structure, the name of the attribute should be related to its purpose and thus be primary-domain.

However, I'd like to propose to keep the container because it makes it easier to add more attributes later without changing the structure completely.

[openBackhaul]

Decision during the 5G-xhaul call on 12th of July 2023:

The ptp-transparent-clock-default-dataset datatype shall be completed according the IEEE 1588-2019.

The attributes and datatypes marked in green shall be added to the Synchronization modelling.

Read/write access is assigned according to the referenced specification.

Filling the ptp-transparent-clock-default-dataset datatype with the additional attributes is expected to lead to a grouping as a result of the UML2YANG translation.

[demx8as6]

Review comment: Based on the discussion in #52: the attribute clockIdentity should be removed from the proposal above.

[openBackhaul]

Martin's comment will be discussed in #55.