[Ntp] Paul Wouters' No Objection on draft-ietf-ntp-interleaved-modes-07: (with COMMENT)

[Paul Wouters via Datatracker <[e-mail]>]

Paul Wouters has entered the following ballot position for
draft-ietf-ntp-interleaved-modes-07: 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-ntp-interleaved-modes/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Roman's DISCUSS and Francesca's Comments. I understand Ben and
Warren's concern, but seeing how this is an "optional addon" that has proven
not to cause harm, I am fine with the document.

       The server MAY separate the timestamps by IP addresses, but it
        SHOULD NOT separate them by port numbers to support clients that
        change their port between requests, as recommended in RFC 9109
        [RFC9109].

Would this not interact badly if I fire up a cluster of machines behind
a NAT router and they more or less do NTP requests at the same time. For
example after a power failure ?

        If the conditions are not met (i.e. the request is not detected
        to conform to the interleaved mode), the server MUST NOT respond
        in the interleaved mode. The server MAY always respond in the
        basic mode. In any case, the server SHOULD save the new receive
        and transmit timestamps.

This reads like the server MAY also not respond, which is probably not
what you meant?