Thank you very much for those changes. They read better and clearer. I appreciate the work that took.
Deb Cooley On Wed, May 15, 2024 at 5:00 PM Doug Arnold <[email protected]> wrote: > 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 <[email protected]> on behalf of Deb Cooley via > Datatracker <[email protected]> > *Sent:* Sunday, May 5, 2024 3:21 PM > *To:* The IESG <[email protected]> > *Cc:* [email protected] <[email protected]>; [email protected] < > [email protected]>; [email protected] < > [email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc >
_______________________________________________ TICTOC mailing list -- [email protected] To unsubscribe send an email to [email protected]
