etween PTPv2 and PTPv2.1: The 2008 version allowed for the concept of multi-domain PTP networks, but the specification focused on networks with a single PTP domain. As a result, there were some inconsistencies in some parts of the standard that could lead to confusion. Changes to the 2019 edition (especially to section 6.1 on the general requirements) address those concerns. A new informative Annex O gives examples of inter-domain interactions. The specification of TCs has changed in two areas. The 2008 specification of TC allowed an (optional) single copy of default and port datasets. The 2019 version deprecates the old trans- parentClockDefaultDS and transparentClockPortDS and instead allows attributes in the default and port datasets for each PTP instance. Previously, the specifications for TC (concerning the datasets) were independent of the domain, but since the new specification for datasets are per PTP Instance, they are domain specific. New rules have been added for assignment of the clockIdentity to reduce the possibility of as- signment of duplicate clockIdentity values to different clocks. This is because the rules for con- structing a EUI-64 value were changed by the IEEE Registration Authority after the publication of the 2008 edition. The common header of the PTP packet was modified to allow a reserved field to become a PTP minor version number, or minorVersionPTP For this new edition of the standard, the version- PTP attribute has the value 2, and the minorVersionPTP attribute has the value 1. This allows the protocol version of the new edition to be expressed as 2.1 rather than 3. Messages with equal or different values for this VersionPTP field, but equal values for the versionPTP field, are accepted by this version of PTP. The section on PTP datasets has been changed to enable the management of PTP datasets with external management tools beyond the PTP management mechanism in (optional) section 15. It suggests the specification of the datasets in section 8 can be mapped to other data modelling l