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

[Doug Arnold <[e-mail]>]

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 <[e-mail]>
Sent: Wednesday, May 15, 2024 11:48 AM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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?