Subject: Re: [Ntp] NTPV5 requirements vs draft RFC

From: James <[email-masked]>
Date: Wed, 2 Mar 2022 09:11:51 +0100

Doug,

Regarding the choices of wording - most of those were somewhat deliberate on my behalf, knowing that normative ("SHOULD") would be held to tighter expectations over "should". Some could indeed change, but the rope needs to have a little bit of slack for the specification.

As for deployment issues, much of it remains splattered across mailing list folklore, and the likes. I've made an issue to put some sources in.

https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/8

- J

> On 28 Feb 2022, at 20:03, Doug Arnold <[email-masked]> wrote:
> 
> James,
>  
> I agree with your overall assessment. 
>  
> I have a couple of questions about the requirements draft:
> There are some statements in the requirements draft that look like recommendations but use “should” rather than “SHOULD”.  Is there a criteria to decide which to use?
>  
> Is there a reference on deployment issues with previous new versions of ntp, that you can site, or can you add a brief summary to the requirements?
>  
> Doug
>  
> From: James <[email-masked]>
> Date: Monday, February 28, 2022 at 11:24 AM
> To: Doug Arnold <[email-masked]>
> Cc: NTP WG <[email-masked]>
> Subject: Re: [Ntp] NTPV5 requirements vs draft RFC
> 
> Doug,
> Thank you for doing this analysis. I haven't yet read through Miroslav's latest version so can't comment on the specifics just yet, but for my own ease I have copied your data into a spreadsheet [1] with some minor editorialisation. At first glance it only appears a few things are not met and a few that are differences in normative language.
> 
> - J
> 
> 1: https://docs.google.com/spreadsheets/d/1Mutawk0XYy_0ab8Ih0yjUCGBim6T2qmsU1nCa4n0rZY/edit
> 
> > On 26 Feb 2022, at 00:32, Doug Arnold <doug.arnold=[email-masked]> wrote:
> > 
> > I looked at the compatibility between the current ntpv5 draft requirements and draft rfc.  My comments are collected in the attached pdf.
> >  
> > --- Doug
> > <NTPv5 req vs draft rfc.pdf>_______________________________________________
> > ntp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 2 Mar 2022 11:15:06 +0100

> I looked at the compatibility between the current ntpv5 draft requirements and draft rfc.  My comments are collected in the attached pdf.

Thanks for the analysis. I have few comments and questions on some of
the requirements.

Minimize NTP abuse (MUST)
- I'm not sure what is meant by the fullest extent
- Generally, there is no way to prevent a client from sending a
  request to a server. Broken implementations flooding servers exist.
- KoD in NTPv4 was a failure. Few implementations follow it and it's
  those that don't which are causing most troubles.
- In my draft the poll field in the server indicates the minimum request
  interval

Capability for servers to notify clients that the service is unavailable (MUST)
- Same as above
- Should this something different from responding with the
  unsynchronized leap status?

Connection reestablishment interval (SHOULD)
- Is this about periodical resolving of the server hostname to the IP
  address? Even if the server is responding?
- Do we need to specify an exponential backoff for the polling interval
  of the client when it's not getting an expected response?

NAT support (SHOULD)
- There is nothing in the protocol based on the IP address, except the
  refid provided to NTPv4 clients, which is needed for compatibility

Avoid incorrect v4 server response to v5 requests to cause issues (MUST)
- I think this is addressed by switching the origin timestamp to
  the client cookie, which causes the bad NTPv5 response to have a
  zero client cookie (copied from the transmit or receive timestamp),
  which will be ignored by the client

-- 
Miroslav Lichvar