I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes the PTP profile for Enterprise, and seems to be in quite good shape. There are several nits like format of IEEE standards and using both SHALL and MUST, but nothing major. == In introduction there is text saying: The third edition of the standard (IEEE 1588-2019) defines PTPv2.1 and includes the possibility to use unicast communication between the PTP nodes in order to overcome the limitation of using multicast messages for the bi-directional information exchange between PTP nodes. The unicast approach avoided that. In PTP domains with a lot of nodes, devices had to throw away more than 99% of the received multicast messages because they carried information for some other node. It is not clear what the "that" refers in the sentence of the "The unicast approach avoided that." Perhaps that sentence is supposed to be after the last sentence in the paragraph, and "that" would refer what is described in last sentence of the paragraph? -- Section 3: * PTP Port: An interface of a PTP clock with the network. Note that there may be multiple PTP Ports running on one physical interface, for example, mulitple unicast timeReceivers which talk to several Grandmaster Clocks in different PTP Domains. typo /mulitple/multiple/ -- Section 4: This PTP Profile does not specify timing performance requirements, but such requirements explain why the needs cannot always be met by NTP, as commonly implemented. Such accuracy cannot usually be achieved with a traditional time transfer such as NTP, without adding non-standard customizations such as hardware time stamping, and on path support. These two sentences seem to be bit of repeating same thing, perhaps rewording them. Also what other "traditional time transfers" this text is refering, perhaps the second sentence should simply /a traditional time transfer such as NTP/NTP/? -- Use of SHALL and MUST. This document uses both SHALL and MUST, but while RFC2119 do have same meaning for them, IETF documents use MUST more often than SHALL, while in the IEEE documents MUST is deprecated, and SHALL needs to be used. I think it would be better to pick one and use that, as it will make it easier for implementors to search for mandatory to implement things, by just search one term (implementors commonly search for MUST and verify they have actually implemented all them, and even some customers have been known to require list of MUSTs that have been implemented). It seems sections 5, 7, 8, 10, and 13 use SHALLs, and 9, 11, 12, and 14, uses MUSTs. Section 6 uses both SHALLs and MUSTs. -- Use of IEEE standard references. The proper way of refering to the IEEE standards is "IEEE Std 1588" when undated reference is used, or "IEEE Std 1588-2019" when dated reference is needed. Dated reference should be used when you are referencing specific clause or annex numbers inside the standards, as those can change from revision to revision. Undated references refer to the latest revision of the standard, and all approved amendments to the standards (i.e., undated IEEE Std 1588 includes IEEE Std 1588g-2022 also). It would be better to used proper format of the IEEE standard throughout the document, i.e., use "IEEE Std 1588" instead of just "IEEE 1588". In the introduction I do not think the following reference needs to be dated: Network communication was based solely on multicast messages, which unlike NTP did not require that a receiving node in IEEE 1588-2019 [IEEE1588] need to know the identity of the time sources in the network. I think undated reference would be best there, i.e., just "IEEE Std 1588". The other places in introduction do seem to require dated reference, as they are referencing specific clause numbers etc, or specific version of IEEE Std 1588. In section 3, I think the: * Clock Identity: In IEEE 1588-2019 this is a 64-bit number assigned to each PTP clock which must be globally unique. Often it is derived from the Ethernet MAC address. should be undated reference. In section 5 the following reference: This PTP Profile SHALL operate only in networks characterized by UDP RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200 [RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588] respectively. should be use dated reference, as you are referring specific annexes, and those annex numbers might change in the next revision of the IEEE Std 1588. So change "IEEE 1588" to "IEEE Std 1588-2019". Similar change section 6, where you refer to Annex D of IEEE Std 1588-2019. In section 9, I think the dated and undated references should be other way around, i.e., in text: Note that IEEE 1588-2019 requires timeReceiver Clocks to support both two-step or one-step timeTransmitter Clocks. See IEEE 1588 [IEEE1588], subClause 11.2. change first reference to be undated, and change last to be dated. In section 14 the reference needs to be dated as referencing Annex I.3. -- Use of SHALL/MUST NOT Use of SHALL NOT / MUST NOT is hard to verify, so it is usually better to express requirements in a way that devices MUST do not, what they MUST NOT do. For example in section 7, there is text which says "The ... Announce, ... default message rates SHALL each be once per second", and then there is another sentence which says "The Announce message rate SHALL NOT be changed from the default value.". How is that last SHALL NOT be verified? I think it would be better to just say that "The Announce message rate SHALL be once per second.", i.e., clearly say what the value is instead of what is the default, and that it cannot be changed. Similarly in section 10: Transparent Clocks SHALL NOT change the transmission mode of an Enterprise Profile PTP message. For example, a Transparent Clock SHALL NOT change a unicast message to a multicast message. It would be better say that "Transparent Clocks SHALL keep the transmission mode of the Enterprice Profile PTP message.", and the second sentence is example, so there is no point of using SHALL NOT there, instead just say "For example it will not change unicast message to a multicast message.". -- In section 12 the document says that "PTP Management messages MAY be used.", but in the security considerations section there is text saying "PTP native management messages SHOULD NOT be used, due to the lack of a security mechanism for this option.". I think the section 12 should be updated to match what is described in the section 18. -- In section 12 there is text saying "is not set to All 1s", perhaps /All/all/? -- In section 13 there is term "NOT ALLOWED", which is not defined in section 2. It would be better to use section 2 terms instead, or at least define it in section 2. -- In section 18 the sentence: The use of multiple simultaneous timeTransmitters, using multiple PTP domains can mitigate problems from rogue timeTransmitters and on-path attacks. is perhaps missing "and" between the two proposed mitigation solutions, i.e., "The use of multiple simultaneous timeTransmitters, and using multiple PTP domains can ...". Also I am not really sure how the Note after that sentence relates to the stuff before: Note that Transparent Clocks alter PTP content on-path, but in a manner specified in IEEE 1588-2019 [IEEE1588] that helps with time transfer accuracy. See sections 9 and 10. Perhaps that Note should be separate paragraph instead? In the 2nd paragraph there is text: for example NETCONF NETCONF [RFC6241]. I think the it should be just "for example NETCONF [RFC6241]". In the last paragraph there is reference to RFC7384, it would be nice to have descripion of of the rfc in the text (this draft seemed to have those in most of the other places where RFC was referenced, like in the NETCONF above, or the UDP / IPv4 / IPv6 etc). I.e., perhaps rewrite it to: See the security requirements of time protocols RFC 7384 [RFC7384] for more generic security considerations. -- In the section 19 there is incorrect format of the IEEE Standards using "IEEE std. 1588-2019" instead of the IEEE Std 1588-2019" (note, capital letter in Std, and no period). Same for IEEE1588g.