ange of domain values for G.8275.2 is 44-63, then a com- mon value for domain number cannot be used across the end-to-end network. The engineer must configure these value translations on the device performing the interworking function, at least for domain number. Other translation values can be assumed automatically (such as values like priority 1 that are fixed in G.8275.1 and G.8275.2) or allowed to remain unchanged by default. This approach works fairly readily when interworking between these two profiles but may be much more complex for other profile pairs. The defaulting of many parameters does not work for other combinations of profile interworking, which might need different values of fields like clockClass, clockAccuracy, and offsetScaledLogVariance A good example is the difference in clockClass values between G.8275.1 and the G.8265.1 telecom profile for frequency. Sometimes a straight 1:1 translation in values is simply not possible. 11.3.1 Assisted Partial Timing Support with G.8275.2 If the G.8275.2 PTPoIP profile causes rapid accumulation of TE and PDV when running over an unaware network that lacks support from BC and TC clocks, what is its purpose? If you cannot rely upon the profile to avoid asymmetry and carry time accurately, then why have it as an option? It is already clear that one possibility is to deploy the profile only in a very narrow range of circum- stances, such as only over well-designed networks and using a very small number of intervening nodes between a remote edge GM and the slave. In fact, there is a note in the G.8275.2 recommend- ation that states just that. However, this profile is perfectly adequate as a timing solution for those cases where the phase alignment accuracy is more relaxed. One example is for timing the DOCSIS cable system using the remote PHY architecture. The use case that led to the development of the G.8275.2 profile was where the MSP did not own its own back-haul network and needed to rely on third-party SPs to provide circuits to interconnect the MSP's mob