Skip to main content

Last Call Review of draft-ietf-tictoc-ptp-enterprise-profile-24

Request Review of draft-ietf-tictoc-ptp-enterprise-profile
Requested revision No specific revision (document currently at 26)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2024-03-05
Requested 2024-02-20
Authors Douglas Arnold , Heiko Gerstung
I-D last updated 2024-03-07
Completed reviews Intdir Telechat review of -26 by Tommy Pauly
Secdir Last Call review of -24 by Tero Kivinen (diff)
Genart Last Call review of -24 by Susan Hares (diff)
Opsdir Last Call review of -24 by Tim Chown (diff)
Assignment Reviewer Tim Chown
State Completed
Request Last Call review on draft-ietf-tictoc-ptp-enterprise-profile by Ops Directorate Assigned
Posted at
Reviewed revision 24 (document currently at 26)
Result Has nits
Completed 2024-03-07

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

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

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

Section 6

Maybe cite
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,