Roughtime
draft-ietf-ntp-roughtime-19

Thanks for addressing my DISCUSS items.

Thanks for the work done in this document. Some non-blocking comments though:

# Section 1

Justification would be welcome when claiming `Unfortunately, widely deployed protocols ... lack mechanisms to observe that the servers behave correctly.`

s/*,which* ideally remain unchanged throughout a server's lifetime/*that ideally remain unchanged throughout a server's lifetime/ ? 

Moreover, should it rather be client's lifetime ? or the min() or max() of client/server lifetimes ?

# Section 3.1

I most probably lack knowledge about 'time', but what is 'radius' in `The response includes a timestamp and a radius` ? An informative reference or explanation would be welcome.

# Section 5.2

A lot of SHOULD in this section without the mandatory guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Same issues for many SHOULD in other sections.

## Thanks to the Reviewers

Thanks to Colin Perkins for the TSVART review, and the text proposed to address that review.

### S5 - Comment
"A Roughtime packet may exceed the maximum deliverable length of a UDP
   packet."
- NiT, I think this could be betteer, perhaps something like:
"The size of a Roughtime packet could exceed the maximum deliverable length of a UDP
   packet."

### S5 - Comment
  "MTU issues
   may lead to persistent nonresponse due to network devices between
   client and server."
- This seems like an odd term: /MTU issues/. Do you perhaps mean the "Path MTU may be insufficient
to carry a datagram of the required size"? - Or do you mean that "PMTUD may be unable to
determine an effective PMTU", or both? or something else, please consider a small change.

## S5.2 - Comment
"   The size of the request message SHOULD be at least 1024 bytes when
   the UDP transport mode is used."
- What happens if the interface MTU is too small to allow datagrams with this size, or the path is unable to deliver datagrams with this size. Is it OK for the request to fail? - If so, please state this - or please specify what ought to happen.

## S5.2 - Comment
- As above, but for the return path, we should not assume the two paths have a symmetric PMTU. Again, please specify what ought to happen. It could be helpful to also note how a server handles persistent lack of a response.

Gorry Fairhurst

Thank you for the updates to address my previous ballot.

==NIT==

In Section 8.3, you have a repeated word:

> Appendix "Appendix A.  Example Server List" contains	
> an example server list in the format described here.

Hi Watson and Marcus, 

Thank you for the changes made in [1]. These addresses the comments in my previous ballot [2].

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-ntp-roughtime-18

[2] https://mailarchive.ietf.org/arch/msg/ntp/yF_LXYlLVFPEllgGMDspYa8_FwQ/

Thank you to Christer Holmberg for the GENART review.

Thank you for addressing my DISCUSS feedback.

** 9.6.  Maintaining Lists of Servers
   The infrastructure and procedures for maintaining a list of trusted
   servers and adjudicating violations of the rules by servers is not
   discussed in this document and is essential for security.

It isn’t clear what an implementor is supposed to do with this text.  It doesn't seem actionable.