Ballot for draft-ietf-ntp-over-ptp
Yes
No Objection
No Record
Summary: Needs 6 more YES or NO OBJECTION positions to pass.
Hi Miroslav, Thank you for the effort put into this well-written spec. Thanks to Tony Li for the OPSDIR review. I have one comment about this part: CURRENT: In the context of NTP over PTP version 2.1, this means that the NTP servers, clients, and peers MUST verify that received PTP messages use the domainNumber and sdoId configured for use by NTP over PTP. The domainNumber SHOULD be 123, and sdoId SHOULD be 0. This domainNumber 123 is not commonly used by PTP profiles, and so is less likely to interfere with any other PTP operation that might be running in the network. Given that we have SHOULD there for domainNumber/sdoId, can we have an explicit statement that these can be configured to clients/servers? Also, remind that any incontinency in the configuration would mean that the extension won't be used. Thank you. Cheers, Med
Thank you for preapring this document, and thanks to the review by Colin. I do not see any new transport-related concerns. The Security Considerations notes that “The PTP transport prevents NTP clients from randomizing their source port”. I wanted to understand why, but then found this text earlier: "If the UDP transport is used for PTP, the UDP source and destination port numbers SHOULD be the PTP event port (319). If the client implemented port randomization [RFC9109], requests and/or responses would not get a hardware receive timestamp due to the hardware filter matching only the PTP event port." Please could you include this explanation in the Security Considerations, I found the present text too short to explain why port randomisation is not recommended.
Thanks for the work done in this document. Thanks also to Karen, the shepherd, for noting that coordination took place with IEEE. Just two comments: 1) as a non-PTP expert, I wonder whether there is a registry for ? Like Med, I wonder about the collision or code-point squatting in `The domainNumber SHOULD be 123, and sdoId SHOULD be 0. This domainNumber 123 is not commonly used by PTP profiles` (some text should also be added about when the "SHOULD" can be bypassed) 2) suggest adding a URI reference to the IANA `NTP Extension Field Types Registry` Please also consider s/man-in-middle attack/on-path attacker/