Hello Murray,
Thanks for the review. You found some inconsistencies or unclear passages that I and others missed. I reply to the comments inline below This seems like what RFC 2026 defines as an Applicability Statement. Should it say so explicitly? This might be characterized as an applicability statement according to RFC 2026, but I’m not sure that stating this will clarify this draft to readers. I am open to detailed suggestions. NTP in the Abstract could use a reference to its RFC. I agree. I propose to add a reference to RFC 5905 The SHOULD in Section 5 is bare. When might an implementer legitimately decide to deviate from the advice given there? Or maybe MUST is better? Good point. I propose: In Section 5, change: “Note that clocks SHOULD always be identified by their Clock ID and not the IP or Layer 2 address.” To: “Note that clocks SHOULD always be identified by their Clock ID and not the IP or Layer 2 address in implementations that might operate in a network that contains Transparent Clocks.” The first SHOULD in Section 9 seems to me to be redundant to the MUST that precedes it. The MUST and SHOULD are as intended. However, if you are confused then I wasn’t clear. I propose: In section 9, change: “TimeReceiver Clocks MUST be able to operate properly in a network which contains multiple timeTransmitters in multiple domains. TimeReceivers SHOULD make use of information from all the timeTransmitters in their clock control subsystems.” To: “In a network which contains multiple timeTransmitters in multiple domains. TimeReceivers SHOULD make use of information from all the timeTransmitters in their clock control subsystems.” TimeReceiver Clocks MUST be able to function in such networks even if they use time from only one of the domains.” Is the SHOULD in Section 10 a restatement of the SHOULD in the last paragraph of Section 6? Yes it is. I propose removing the sentence with the SHOULD in section 10. ________________________________ From: Murray Kucherawy via Datatracker <[email protected]> Sent: Wednesday, May 15, 2024 11:48 AM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Murray Kucherawy's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT) Murray Kucherawy 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: ---------------------------------------------------------------------- This seems like what RFC 2026 defines as an Applicability Statement. Should it say so explicitly? NTP in the Abstract could use a reference to its RFC. The SHOULD in Section 5 is bare. When might an implementer legitimately decide to deviate from the advice given there? Or maybe MUST is better? The first SHOULD in Section 9 seems to me to be redundant to the MUST that precedes it. Is the SHOULD in Section 10 a restatement of the SHOULD in the last paragraph of Section 6?
_______________________________________________ TICTOC mailing list -- [email protected] To unsubscribe send an email to [email protected]
