Hello Murray, What is the best way to state that this is an applicability statement? Do I just add to the intro a sentence like: "This recommendation describes the applicability of IEEE 1588 to time transfer in an enterprise IT network with hundreds of nodes or greater."
regarding the source address, I see your point. If there is a chance that the received IP address is not the correct one to respond to, the then the normative statement needs to be a MUST. In the structure of "if x, then MUST y." I could make that change. Regards, Doug ________________________________ From: Murray S. Kucherawy <[email protected]> Sent: Wednesday, May 15, 2024 11:38 PM To: Doug Arnold <[email protected]> Cc: The IESG <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: Murray Kucherawy's No Objection on draft-ietf-tictoc-ptp-enterprise-profile-26: (with COMMENT) On Wed, May 15, 2024 at 8:09 PM Doug Arnold <[email protected]<mailto:[email protected]>> wrote: 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. It's not so much to clarify for readers; it's more that it bolsters the justification for this being a Standards Track document. 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.” Let me put it this way: If I'm writing an implementation that might operate in a network that contains Transparent Clocks, why might I legitimately decide to identify a clock by its IP or Layer 2 address? I suggest that one of the following should be true: (a) There is such a legitimate decision path, in which case the SHOULD is fine, but you should lay out some guidance for me so I know how to make that decision; OR (b) There isn't such a legitimate decision path, and this needs to be a MUST. Absent those, the SHOULD is telling me I have a choice, and you'd really rather I do one thing than the other thing, but not why. I can choose to do the other thing with only arbitrary justification and be fully compliant; are you okay with that? 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.” Yes, that's better. 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. Works for me. -MSK
_______________________________________________ TICTOC mailing list -- [email protected] To unsubscribe send an email to [email protected]
