On Thu, Sep 25, 2025 at 08:25:48AM -0500, Robert Sparks wrote: > On 9/25/25 5:34 AM, Miroslav Lichvar wrote: > > Responses larger than requests are normally expected only with the NTP > > control (6) and private (7) modes. They are the ones which were used > > for the widely known traffic amplification DDoS attacks. > > > > This draft only covers the client-server and symmetric timing modes, > I see the first sentence of the abstract. The document would be better if > this was made explicit in section 2, and that when you do so, you include > the word "only".
The section 2 says at the beginning: A new TLV is defined for PTP to contain NTP messages in the NTP client (3), server (4), and symmetric modes (1 and 2). Using other NTP modes in the TLV is not specified. Do you suggest it says "A new TLV is defined for PTP to contain NTP messages only in the NTP client ..." ? To me that looks a bit odd. > But you're pointing out that the real problem is with the MUST in the > sentence. The paragraph reduces to "PTP implementations are supposed to > follow the PTP specifications", and I suggest you simply remove it from this > document - it's not needed here. What would an implementer do wrong if it > were removed? That is a text that was suggested by the IEEE people to make it clear that their specification must be followed. Without that MUST someone might possibly think that if it's used for NTP, it doesn't really matter what the other fields in the PTP message contain. > > > Nits/editorial comments: > > > > > > Please reference BCP14 rather that RFC2119. > > That is RFC8174 should be referenced in addition to RFC2119? > A bit more than that. Look at the xml for recently published RFCs for what > the BCP14 description and reference looks like. Hm, I looked at some recent RFCs, but I didn't see any other difference. BCP 14 is constistently mentioned once in the "Requirements Language" section and then in the two references to RFC2119 and RFC8174. -- Miroslav Lichvar _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
