Reviewer: Tero Kivinen
Review result: Has Nits
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
