Re: [Ntp] Modular NTP

Miroslav Lichvar <mlichvar@redhat.com> Mon, 27 April 2020 07:53 UTC

Return-Path: <mlichvar@redhat.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50963A119F for <ntp@ietfa.amsl.com>; Mon, 27 Apr 2020 00:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK5mW7stuX8s for <ntp@ietfa.amsl.com>; Mon, 27 Apr 2020 00:53:54 -0700 (PDT)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3D43A119D for <ntp@ietf.org>; Mon, 27 Apr 2020 00:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587974033; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XU/zXTSZkeiSXK/ftzI4FZIqq2r0TubxyRdRTlQdJ4s=; b=AhnLFhi7sK7xBTGoimCSUa7K3dqJAxjzkVpt63vF5zM5Qnl1LTKxymQm0tM/PzsYFL8yz8 AVwNvgwLucx5FJsFn8l+khJMlAPZaokG/r5XIfHpe1+YHsT0VmILQELttgWtRcE2X+dGXG N+NeQdchzNO9wVbSU5e5/qxF0l6aZRo=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-401-BEU6lgQINDqgFRBu4FWExQ-1; Mon, 27 Apr 2020 03:53:49 -0400
X-MC-Unique: BEU6lgQINDqgFRBu4FWExQ-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9F04E19057A9; Mon, 27 Apr 2020 07:53:47 +0000 (UTC)
Received: from localhost (holly.tpb.lab.eng.brq.redhat.com [10.43.134.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 0B19F5C1D4; Mon, 27 Apr 2020 07:53:45 +0000 (UTC)
Date: Mon, 27 Apr 2020 09:53:44 +0200
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: Doug Arnold <doug.arnold@meinberg-usa.com>, NTP WG <ntp@ietf.org>, Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Message-ID: <20200427075344.GO4396@localhost>
References: <729A897B-2825-4E41-A844-286BB9500C5D@akamai.com> <DB8PR02MB561107661708391F34D09768CFD00@DB8PR02MB5611.eurprd02.prod.outlook.com> <CABUE3XmEZrMqNsxBBcnRFOg65CDExnnU96boBf4i_WiPjQ5Pcg@mail.gmail.com> <DB8PR02MB56113C71A7B304F010F94592CFD10@DB8PR02MB5611.eurprd02.prod.outlook.com> <CAJm83bAP9uY6ujTBVsSroOaQFWboM-B9q9Y9B=j5uE7O0z_DYQ@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAJm83bAP9uY6ujTBVsSroOaQFWboM-B9q9Y9B=j5uE7O0z_DYQ@mail.gmail.com>
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/PmTFOloFZs5YmSt2hXRkHt2IBWE>
Subject: Re: [Ntp] Modular NTP
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 07:53:57 -0000

On Sat, Apr 25, 2020 at 09:34:09AM -0400, Daniel Franke wrote:
> This interface is very straightforward and I think its description belongs
> in the algorithm document. On the client side, the protocol engine feeds
> the clock control algorithm a stream of decrypted responses annotated with
> their origin and destination timestamps. On the server side, the clock
> control algorithm feeds the protocol engine the clock values that it should
> be responding with.

I presume an RFC 5905 implementation should be easily split in this
scheme. Where is the clock filter and source selection? Are they all
in the "clock control"? The clock filter needs to be compatible with
the control loop. Source selection is between them.

-- 
Miroslav Lichvar