Furthermore, many of the profiles based off the 1588-2008 standard do not make use of the mech- anism either. For reasons of interoperability and operational simplicity, it is not widely adopted. Despite that, it is undeniable that security is an aspect of PTP that needs further development. It is not surprising, then, that although Annex K has been dropped from the new version of PTP, security is getting much greater attention in 1588-2019 with its Annex P, "Security." This new integrated security mechanism from 1588-2019 provides source authentication, message integrity, and replay attack protection for PTP messages. Like the now defunct Annex K from 1588- 2008, the mechanism relies upon standard cryptographic techniques, shared keys, and HMAC integ- rity checks, but it is a different implementation. See 1588-2019 section 16.14, "PTP integrated se- curity mechanism," and the informative Annex P. These sections define two basic methods: An AUTHENTICATION TLV, which allows source authentication and message integrity. This TLV will contain various fields, including the calculated Integrity Check Value (ICV) of the PTP message used to ensure it has not been altered by an unauthorized party. A key-exchange mechanism to enable (secure) distribution of security parameters (such as the algorithm type and shared key) needed to construct and verify the AUTHENTICATION TLV. The standard does not specify the method for this key-distribution process. The ICV is calculated by a hashing algorithm, and HMAC-SHA256-128 is suggested as one that should be supported by an implementation. The mechanism envisages two basic integrity check methods, one where the message is immediately verified before additional processing, and another where verification can take place after processing. There are different considerations for each case. One involves the use of TCs. Because TCs need to update the correctionField of the Sync message during transmission from mas- ter to slave port, this obviously invalidates the existing integrity check, S