Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp

Miroslav Lichvar <mlichvar@redhat.com> Wed, 02 January 2019 12:35 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 F218412D4E9 for <ntp@ietfa.amsl.com>; Wed, 2 Jan 2019 04:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ygICL-5x1xO1 for <ntp@ietfa.amsl.com>; Wed, 2 Jan 2019 04:35:35 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B2A127AC2 for <ntp@ietf.org>; Wed, 2 Jan 2019 04:35:35 -0800 (PST)
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 mx1.redhat.com (Postfix) with ESMTPS id 2735081F13; Wed, 2 Jan 2019 12:35:35 +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 70D4A5C22C; Wed, 2 Jan 2019 12:35:34 +0000 (UTC)
Date: Wed, 02 Jan 2019 13:35:34 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Dieter Sibold <dsibold.ietf@gmail.com>
Cc: ntp@ietf.org
Message-ID: <20190102123534.GF30177@localhost>
References: <FF5E07A6-6F59-4D45-A186-7FC7C9B4A41C@isoc.org> <20181206121656.GI28938@localhost> <A3054870-621C-49CD-89EF-87DBC8A6B9A9@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <A3054870-621C-49CD-89EF-87DBC8A6B9A9@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 02 Jan 2019 12:35:35 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Pi77g2XD9z7XsH9ir2C3AMiq3qI>
Subject: Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-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: Wed, 02 Jan 2019 12:35:37 -0000

On Sat, Dec 15, 2018 at 06:32:29PM +0100, Dieter Sibold wrote:
> On 6 Dec 2018, at 13:16, Miroslav Lichvar wrote:
> > I still think it would be good to specify the maximum length of the
> > cookie. This would simplify the client implementation. From a previous
> > discussion, it looks like 256 octets should be enough.
> 
> The cookie contained in the Cookie EF is implementation specific.
> Therefore in my opinion the size should not be specified, although
> it might simplify implementation.

I'm ok if it stays unspecified. Just sharing some thoughts.

It seems for the example implementation in the draft 256 would be
enough. Are there any valid reasons why a server implementation would
need more?

We probably don't want an NTS implementation to turn into a
distributed storage system :). We probably also want to avoid IP
fragmentation. So, something like 1024 octets would seem to me like
the absolute maximum.

> > In 5.2 there is "Possibly, some additional extension fields which are
> > neither encrypted nor authenticated.  These are discarded by the
> > receiver." I'd suggest to change the last sentence to "These are
> > normally discarded by the receiver". This is explained later in the
> > document for both client and server sides.
> 
> I see. I would like to phrase it „In general, these are discarded by
> the receiver.“ in order to emphasize the normal behavior.

That works for me. Thanks.

-- 
Miroslav Lichvar