Re: [Ntp] ntpv5 requirements

[James <[e-mail]>]

Doug,

Thanks for the review, responses inline. I've committed a few changes as a result, they're in the Editor's Version in Github.

- J

> On 9 Feb 2023, at 18:18, Doug Arnold <doug.arnold=[e-mail]> wrote:
> 
> Here are some suggestions for draft-ietf-ntp-ntpv5-requirements-01
>  Section 2
> The current standard for PTP is IEEE 1588-2019.
>  Some financial institutions and data centers use ntp rather than ptp not because they don’t need accuracy or can’t deploy ptp, but because they prefer it.  The reasons that they prefer it are familiarity, and a dislike of the BMCA in ptp.  I have heard of non-default algorithm ntpv4 implementations that achieve 50 ns time transfer accuracy in specialized financial networks.

JG: Thanks, could you please confirm doi:10.1109/IEEESTD.2020.9120376 is the correct identifier, I don't have access to IEEE documents to check and am guessing off the title and abstract. Thanks for the insight on data centres, I've added a bit more context based on what you've put here.

>  Section 3.5
>  Consider adding something like this sentence: “If a server implements leap second smearing, then it MUST indicate that smearing is active in the response message whenever it is active, and include all necessary information for the determination of TAI and UTC.”

JG: My position until now has been largely to avoid support for smearing. We've had a few rounds of discussion over the lifetime of this document and permitting it will only add another dimension of possible combinations of timestamps received and processed by clients, making things more complex particularly in circumstances where a client receives responses from multiple servers with/without smear. Furthermore if servers are transmitting smeared time, the client would also have to know what scale the smearing is running at or we have to define requirements of what smearing scale must be used in the protocol, further affecting implementation complexity having to try and "reverse engineer" the necessary calculations to derive TAI for example.

I think there's a WG consensus call to be made here before support for it should be included in the document.

>  Section 3.8
>  Consider adding something like this sentence: “The protocol SHOULD allow for different mechanism for authentication and confidentiality to support different use cases.”
>  For example: Judah Levine at NIST recently told me that he cannot implement NTS with his current server resources and the number of clients NIST supports.  However, when I told him about TESLA he thought a scheme based on that would be doable, as long as the keys didn’t have to change too often.

JG: I agree with supporting different forms of authentication and confidentiality (and it's why I specifically abstain from mentioning NTS). I've added a version of this sentence, but I think it could use some refinement to better fit into the surrounding text, and also important to make a distinction that at least one form of authentication is required, so deployments are not compelled to use NTS where it's not suitable like you describe. As a side note, I'm not sure TELSA is suitable in non-broadcast use cases, but there may be ways to make it work or for newer ideas to come about in the future.

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