Re: [Ntp] Leap second draft

Kurt Roeckx <kurt@roeckx.be> Sat, 30 March 2019 15:23 UTC

Return-Path: <kurt@roeckx.be>
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 CD72A1201EF for <ntp@ietfa.amsl.com>; Sat, 30 Mar 2019 08:23:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 2hIT15rZHwaZ for <ntp@ietfa.amsl.com>; Sat, 30 Mar 2019 08:23:57 -0700 (PDT)
Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a05:7300:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 511021201B5 for <ntp@ietf.org>; Sat, 30 Mar 2019 08:23:57 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id F0962A8A00AF; Sat, 30 Mar 2019 15:23:55 +0000 (UTC)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id ABF321FE0B41; Sat, 30 Mar 2019 16:23:55 +0100 (CET)
Date: Sat, 30 Mar 2019 16:23:54 +0100
From: Kurt Roeckx <kurt@roeckx.be>
To: Daniel Franke <dfoxfranke@gmail.com>
Cc: ntp@ietf.org
Message-ID: <20190330152353.GH7706@roeckx.be>
References: <CAJm83bD5Ozkpg5TpkogOW6xeeNQL3ZziLO9URM7haqN8Wrp=Wg@mail.gmail.com> <CAJm83bCbVzO3NNCbjTy+O_16T7DBeA7O6018WWGu_-GyuN-8UA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAJm83bCbVzO3NNCbjTy+O_16T7DBeA7O6018WWGu_-GyuN-8UA@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/zKlcE0-1DcXrKSDSH9wHvlVZdxI>
Subject: Re: [Ntp] Leap second draft
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: Sat, 30 Mar 2019 15:23:59 -0000

On Fri, Mar 29, 2019 at 08:57:42PM +0100, Daniel Franke wrote:
>    When a deleted leap second or any portion of an inserted leap second
>    intervenes between when the Receive Timestamp is captured and when
>    the Transmit Timestamp is captured, the result is likely to be
>    misinterpreted by any receiver which does not implement the Leap Data
>    and Era Number extension field.

I'm not really sure what you mean here exactly. But I think that
for an insert, either the receive or transmit happening during
the leap second can cause problems if this extension is not used.

As far as I understand, during a remove the bits would not be set,
because it's clear what the time of the fields is. In theory we
could assume that client should know about the leap second
happening, and so it should perfectly understand both timestamps
without this extension. But I guess in practice we can't assume
this, and I think not sending a reply does make sense.

I would recommend adding examples for all possible cases.


Kurt