Subject: [Ntp] Mirja Kühlewind's No Objection on draft-ietf-ntp-using-nts-for-ntp-27: (with COMMENT)

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Tue, 24 Mar 2020 11:17:24 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-ntp-using-nts-for-ntp-27: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

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

Thanks for addressing my discuss points about retries recommendations!

------
Old comments for the record as only partially addressed yet:
-----

In addition to Ben's discuss point on ports which I would also like to see the
answer to, one more question: My understanding is that the TCP port (123) for
NTP is not used and will likely never be used in future. Why are you not using
that port for NTS-KE, as NTS-KE is using TCP?

A couple more small questions:
1) Sec 4.1.3:
"The Critical Bit MUST be set."
If you set the Critical Bit for error records, that would only mean that a
receiver could send another error in response to that error which again has the
critical bit set which then could cause another error, and it would go on
forever. Yes, this case should never happen as all its-ke implementations must
support error records but maybe it's safer to just not set the critical bit?

2) Sec 4.1.4: I don't really understand the idea of the Warning record. There
are no code points defined and there is no explanation given what this could be
used for. Especially what should a client do that received a warning? Why is
the error record not sufficient?

3) Sec 4.1.5: "   If the NTS Next Protocol Negotiation record offers Protocol
ID 0 (for
   NTPv4), then this record MUST be included exactly once. "
In this case, I guess the critical bit should/MUST be also set to 1?

4) Sec 5.7:
"1280 octets is
   the minimum prescribed MTU for IPv6 and is in practice also safe for
   avoiding IPv4 fragmentation.  Nonetheless, senders SHOULD include
   fewer cookies and placeholders than otherwise indicated if doing so
   is necessary to prevent fragmentation."
RFC8085 says "For IPv4, EMTU_S is the smaller of 576 bytes and the
   first-hop MTU [RFC1122]."
Maybe it would be appropriate to note that.