Re: [Ntp] Objections to the current language in draft-ietf-data-minimization

Hi everyone,
(sorry for top-posting, Outlook is crap when it comes to quoting correctly)

I believe that the leap smearing approach has been invented in order to avoid that clients (or their OS) which do not implement leap seconds properly, survive a leap second event without time steps. The leap smearing as it has been implemented in most cases does NOT prevent clients which should not use leap smearing for various reasons (e.g. legal requirements) to sync to an leap-smearing NTP server. IMHO we should find a way to avoid that a client expecting correct time is not served with smeared time. This includes the gazillion clients out in the field not knowing about special refids or extension fields. They send an RFC compliant request (well, most of them do) to a server and expect the response to be correct time.

I therefore would want to see that an NTP server per default is only sending smeared time to clients which specifically ask for it. As far as I can see this could only be done using an extension field in the request, as all wiggling with the header fields of an incoming NTP request is always based on an assumption what exactly the NTP clients knows and wants. And this may be true for most clients, but not for all. I have seen a lot of embedded crude NTP implementations in the field and although I am all for some educational punishment in case some software engineer did not read the entire standard before implementing a client which is not compliant or behaves crazy in our opinion (100ms polling interval anyone?), I would like to avoid messing things up with all these implementations out there. 

I can agree to Harlans approach that the configuration should allow corner cases and overriding the standard behavior, but I would like to avoid to break things for all that stuff already deployed. 

Having said that, in case someone chooses to let his NTP server send smeared time but uses standard NTP packets for that (i.e. responses will be accepted by any standards compliant NTP v2, v3 or v4 client), we should definitely clearly mark the fact that this response packet is carrying smeared time using the refid. This way, you can at least see it when you try to debug why your client is slowly drifting away or flipping because someone unintentionally set it up to use two servers providing smeared time and two servers providing correct time. 

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 heiko.gerstung@meinberg.de 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

On 26.03.19, 12:27 "ntp im Auftrag von Harlan Stenn" <ntp-bounces@ietf.org im Auftrag von stenn@nwtime.org> wrote:

    Dieter,

    I probably should have answered your points with a longer and better
    comment.

    I am in no way suggesting that people should use leap smearing.

    I am saying that regardless of what sort of time folks want to
    distribute, we should give them the tools and configuration options (the
    "mechanism") that will allow them to make the choices that support their
    goals (the "local policy").

    Since the NTP Project has folks who have specifically asked us to
    provide a way to offer leap smearing to their client populations, we
    want to be sure to let them serve their client populations to their
    satisfaction.

    ntp-4.4.0 will behave, out of the box, pretty much the way ntp-4.2.8
    does.  Each administrator will simply have the *ability* to better
    customize how they will answer.

    Their choices will likely include:

    - only send correct time (to everybody)
    - only send leap-smearing time, to all client requests
    - send correct time to clients sending LI=1, and smeared
      time to clients sending LI=0

    This will all be configurable on a per-IP or per-network basis.

    Do you see any problems with this approach?

    H

    On 3/26/2019 3:09 AM, Harlan Stenn wrote:
    > Dieter,
    > 
    > On 3/26/2019 3:05 AM, Dieter Sibold wrote:
    >>
    >> ...
    >>
    >> From my point of view these are arguments against leap-smearing and not
    >> against the data minimization draft which from my point of view is
    >> mandatory since it meet modern regulation requirements such as the eu gdpr.
    >>
    >> - Dieter
    > 
    > You are expected to run your systems the way you want, to your
    > specifications.
    > 
    > A GROWING number of public time servers offer leap-smeared time.
    > 
    > This affects a growing number of clients.
    > 
    > I am opposed to using "creative destruction" as a means to force people
    > to do things the way I think they should be done.  I am a big fan of
    > providing people with robust mechanisms to provide the tools implement
    > their local policy choices.
    > 

    -- 
    Harlan Stenn, Network Time Foundation
    http://nwtime.org - be a Member!

    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp