re that is not the case. Comparing the scope to that of G.8265, you will notice they are basically the same, except G.8265 is for frequency and G.8275 is for time and phase. Many of the terms used in G.8275 build on the concepts introduced in G.8260 (and G.810). This recommendation includes the following main topics, annexes, and appendixes: General introduction and requirements for packet-based time/phase distribution Architecture of packet-based time/phase distribution (including redundancy) Security aspects Annex A, "Time/phase models based on ITU-T G.805" Annex B, "Inclusion of a virtual PTP port on a PTP clock" (which was moved to G.8275 from the G.8275.x profile documents as it was material applicable to both profiles; same approach was taken for Annex C, Annex D, and Appendix VIII) Annex C, "Options to establish the PTP topology with the alternate BMCA" Annex D, "Synchronization uncertain indication (optional)" Appendix I, "Architecture for time and phase distribution over a packet network providing PTS [partial timing support] at the protocol level" (meaning, nodes that do not process PTP) Appendix VIII, "Description of PTP clock modes and associated contents of Announce messages" Appendix VIII is very interesting reading because it describes the linkage between the state of the clock ports, the clock state as a whole, and the contents of the Announce message. G.8275 clause 7, "Architecture of packet-based time/phase distribution," covers the different cases for the design of the packet network and is especially interesting reading. The architecture describes two cases where Support for timing is provided by all nodes in the network (by being boundary clocks, for ex- ample) combined with physical layer frequency support (normally SyncE). Intermediate nodes do not provide timing support, but timing support is provided by GNSS at the network edge, with PTP acting as a backup. This is termed assisted partial timing support (APTS). See the earlier sections on G.8271.1 and G.8271.2 for detailed treatment of th