O either TCs must have a copy of the shared key to regenerate the ICV or else the correctionField must be excluded from the hash calculation (which could defeat the whole point of the exercise). For the delayed verification case, the key used to generate the ICV can be disclosed for later integ- rity checking, but this does not help a TC that needs the key to recalculate the ICV after updating the correctionField However, to allow this, there is a mechanism in the standard to exclude the cor- rectionField from the ICV hash calculation. Annex P of 1588-2019 is a good source of information on the details of the key-distribution prob- lem and multipronged approaches to securing the PTP data transport. Note that there are additional projects approved by the IEEE (see the upcoming section "Next Steps for IEEE 1588") to further define some of these aspects following the publication of IEEE 1588-2019. Looking beyond the security of PTP itself, diversity in clock sources and correlation and cross- checking between them is the best way to make an application based on precise time synchroniza- tion more robust. This is true for power automation (substation security), and it is also commonly used in the financial services industry. Chapter 9 provides more information on the practical secur- ity aspects for real-world deployments. 7.7 IEEE 1588-2019 (PTPv2.1) As mentioned in preceding sections, IEEE 1588-2008 (PTPv2) has been updated with a new revi- sion, formally approved by the IEEE as 1588-2019, but known colloquially as PTPv2.1. The idea behind choosing this version number is to indicate that a major goal of v2.1 was to remain as close to backward compatible with PTPv2 as possible. In short, the two versions are compatible with each other, SO long as No option or feature present in only one of the versions is used. Features common to both versions are used and similarly configured. From the preceding section, you might understand that an example of an option that might have compatibility issues between editions is the o