Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.

The document describes a PTP Profile for use in enterprise networks, be they IPv4 or IPv6.

Overall, the document is well written. I would currently say it is Ready with Nits.

General comments

I’m not familiar enough with PTP to know what a Profile is, or looks like. Section 5 begins with “This PTP Profile SHALL operate only in…” but it’s not obvious to me what part(s) of the document constitute the Profile, and in the extensive glossary of technical terms, ‘Profile’ is not included.  Perhaps this could be clearer.

The document includes several negative comments about multicast, without citing any RFCs or other references as to why multicast is problematic.  This would be helpful.  I am familiar for example with RFC 9119 on multicast in wireless networks, and am a co-author of RFC 8115 on deprecation of inter-domain ASM, but the issues hinted at here don’t fall under either of those documents.  The third paragraph seems to suggest PTP nodes “throw away 99% of multicast”, but usually one would assume multicast is used because the information sent is of interest to multiple nodes concurrently.

The document uses SHALL quite extensively rather than MUST. This is unusual, but in line with RFC 2119. I suspect readers will be more used to seeing MUST.

Other comments:

Technical terms

The section doesn’t clearly differentiate e2e delay measurement mechanism and p2p delay measurement - I assume the timeTransmitter and timeReceiver may not be directly connected, and relay via a Boundary clock?  If so, is the Boundary clock not a transmitter and receiver also, or at least the definition implies that?

Problem statement

I believe you can use hardware timestamping for general NTP, and we are doing so in our own network with a notable improvement in stability. So perhaps here be clearer about why hardware timestamping with PTP is advantageous.

Section 5 

The text appears a little inconsistent over IPv4 and IPv6 use. It says if both are present, they MUST be treated as separate paths (implying duplication over a path between dual-stack devices), but then a PTP domain MUST use IPv4 or IPv6 but not both.  Perhaps be clearer, and also mention how the IP version is selected when communicating devices are dual-stack.

It’s also not clear to me why the source address changes at a Transparent clock.  I’m sure there’s a good reason, given in another RFC, but it would be useful to have a pointer to that reason included here.  Does the address also need to have at least the scope of the e2e communication (more relevant for IPv6)?

Section 6

Maybe cite https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml for the multicast reserved address, and likewise IPv4.  I note 182-184 are reserved also for PTP alternates.

Section 11

What’s a ‘servo loop’?

Best wishes,
Tim