g several "default profiles" that are described in Annexes A and J of the standard. These annexes contain a (small) number of parameter values to help implement a "default" PTP solution. Most parameters are given a value that should be the default (for example, the default domain number should be 0) and minimum supported range (for example, the log of Announce message rate should be in the range between 0 to 4). Vendors can support wider ranges if desired. There are two choices of default profile: Annex J.3 Delay Request-Response Default PTP profile Annex J.4 Peer-to-Peer Default PTP profile Obviously, J.3 uses the E2E delay request-response mechanism by default, whereas the Annex J.4 profile uses the P2P mechanism by default. Even though these two mechanisms are quite different, the standard allows links performing either mechanism in both profiles. Beyond that basic choice of mechanism and a few values and message rates, nothing else is stipulated. Note that Annexes J.3 and J.4 have moved to I.3 and I.4 in the 2019 edition of IEEE 1588. So, as far the specification of transport and encapsulation, L2 or L3, Ethernet, IPv4 or IPv6, multic- last or unicast, or some combination-nothing is proposed. Obviously, there needs to be significant further agreement to ensure two clocks, both supposedly supporting the default profile, could ever interoperate. Note that sometimes you may run across the profile in some equipment known as Telecom 2008. This is a pre-standardized version of the Telecom profiles based loosely on the default profile that very closely resembles G.8265.1 (or G.8275.2). The authors frequently encounter it in mobile oper- ators that are doing mostly frequency synchronization over packet, although it can work in the phase scenarios. Details are in Annex A of IEEE 1588-2008. Also be aware that default profiles give very little guarantee as to the accuracy of the time re- covered by the slave or the performance of the clocks (network elements) carrying time. A good way to think of default profile perform