[TICTOC]Re: Deb Cooley's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT)

[Doug Arnold <[e-mail]>]

Hello Deb,

Thanks for pointing out the unaddressed comments by Tero Kivinen.

I agree that section 12 and section 18 have to be consistent, and that the use of SHOULD NOT is best.


In section 12, Change:

“PTP management messages MAY be used.”

To:

“PTP management messages SHOULD NOT be used.”


Regarding the preference MUST over MUST NOT: I believe it can be clear either way, but I don't mind changing:  Below are the proposed changes to address this.


In section 7, change:

“The Announce message rate MUST NOT be changed from the default value.”

To:

“The Announce message rate MUST be the default value.”



In section 8 change:

“A PTP Port of a clock MUST NOT be in the timeTransmitter state unless the clock has a current value for the number of UTC leap seconds.”

To:

“A PTP Port of a clock MUST have a current value for the number of UTC leap seconds before transitioning to the timeTransmitter state.”



In section 9, change:

“If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver MUST NOT synchronize to it.”

To:

“A timeReceiver MUST only synchronize to an Acceptable timeTransmitter.”



In section 10, change:

“Transparent Clocks MUST NOT change the transmission mode of an Enterprise Profile PTP message. For example, a Transparent Clock MUST NOT change a unicast message to a multicast message.”

To:

“Transparent Clocks MUST maintain the transmission mode of an Enterprise Profile PTP message. For example, a Transparent Clock that receives a unicast message MUST retransmit the message as unicast.”



In section 11, change:

“Boundary Clocks MUST NOT combine timing information from different domains.”

To:

“Boundary Clocks MUST process information from different domains independently.”



The entire section 13,

“Clocks operating in the Enterprise Profile MUST NOT use Peer-to-Peer timing for delay measurement. Grandmaster Clusters are NOT ALLOWED. The Alternate TimeTransmitter option is also NOT ALLOWED. Clocks operating in the Enterprise Profile MUST NOT use Alternate Timescales. Unicast discovery and unicast negotiation MUST NOT be used. Clocks operating in the Enterprise Profile MUST NOT use any optional feature that requires Announce messages to be altered by Transparent Clocks, as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes from discovering the protocol address of the timeTransmitter.”



Is changes to:

“The following PTP options are NOT ALLOWED:

  *   Peer-to-Peer timing for delay measurement
  *   Grandmaster Clusters
  *   Alternate TimeTransmitters
  *   Alternate Timescales
  *   Unicast discovery
  *   Unicast negotiation
  *   Any optional feature that requires Announce messages to be altered by Transparent Clocks, as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes from discovering the protocol address of the timeTransmitter.”



In section 14, Change:

“These rules MUST NOT be changed to achieve interoperability with other PTP Profiles.”

To:

“Clocks operating in the Enterprise Profile MUST conform to the requirements of the profile even if it prevents interoperability with other PTP Profiles.”


Regards,

Doug









________________________________
From: TICTOC <[e-mail]> on behalf of Deb Cooley via Datatracker <[e-mail]>
Sent: Sunday, May 5, 2024 3:21 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: [TICTOC] Deb Cooley's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT)

Deb Cooley has entered the following ballot position for
draft-ietf-tictoc-ptp-enterprise-profile-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you to Tero Kivinen for his careful review of draft 24.  While some of
his of his points were addressed, there are still some that remain in draft 26.
 I will only highlight a few of these:
  - The use of MUST NOT in cases where a positive requirement could be used,
  where a direct requirement of MUST can be used.  Often MUST is clearer to
  understand. - For PTP Management messages, the discrepency of 'MAY' in
  Section 12 and SHOULD NOT in Section 18 need to be reconciled.  (My
  recommendation would be to change Section 12 to 'SHOULD NOT')



_______________________________________________
TICTOC mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tictoc