Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-18.txt

Watson Ladd <watson@cloudflare.com> Wed, 01 May 2019 00:02 UTC

Return-Path: <watson@cloudflare.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 BAEB51203ED for <ntp@ietfa.amsl.com>; Tue, 30 Apr 2019 17:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 arNUCZwDRyck for <ntp@ietfa.amsl.com>; Tue, 30 Apr 2019 17:02:50 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A605C120155 for <ntp@ietf.org>; Tue, 30 Apr 2019 17:02:50 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id g4so18461499qtq.10 for <ntp@ietf.org>; Tue, 30 Apr 2019 17:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WTuNWgdEskgPOYJyNkyfvAuCzNMseNbmuCbHRq9tpvk=; b=kq7AlNEYKr5K3IJXFKehG98Pm+MtAguJ9J+LOLaf1PRP++OYsbuSvLdQ9UxC668cRx tQr/xlATjB9SYTpvKxJZgF2wuTzgm/syvlWkxEp5UVdHJKUR/yymg9oPUY7cr/ixXIZ0 qNXQQqnKNfZpODgrKYklZtPSQLgDwSeL1ysVs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WTuNWgdEskgPOYJyNkyfvAuCzNMseNbmuCbHRq9tpvk=; b=IwkbJUPL8us2av461WgsQP82G4nniTIO/6x4dLX0oUS2XaBSoF+1GZCpcVCcR+u5Ao c1acOsDPLMa440/EESfwDJXb9TvP5kIV2B/YQrSdToV2J/dPi/Ow71dOdpnVrEu5WHsI yu1bEbKAYklMvghtc4j414pU6dKdjnl3vUznMlq8exWo34KDRz3MO4dob5ltIdJk/ooS dSv/T5rpvOt/es5lft78x8LpOuQEsruGPlkEEXXb4rWKKcBYaXOFCRqlJV1CUQV2LMMF R9iYcEyYi9Tbddku85WD26bbj8iVxj23wWqWvJtOv53sRqKPBxhR2DcmBoCGSaA4aJHX qwvw==
X-Gm-Message-State: APjAAAXfmE87b4+LsLwTHEXAqTYN3bHPwGbM+jzHMOOfrs3Z7YfwnGqf mzcHFTsXTeWZ0mNmUE4Vk6n0Rld+0ALpLa8Pr3Un0k8PudQ=
X-Google-Smtp-Source: APXvYqyk9t0AHPjf9yXdeON8fsVIN6ZKNBT/s76mldftAQ2/Ib90jfGdMjhAZMW0xhfZF8rEheIdKgrGS1bbpmutaFs=
X-Received: by 2002:a0c:afc8:: with SMTP id t8mr54123791qvc.123.1556668969722; Tue, 30 Apr 2019 17:02:49 -0700 (PDT)
MIME-Version: 1.0
References: <20190422080620.6323340605C@ip-64-139-1-69.sjc.megapath.net> <9ae82731-6c9c-6c66-6088-2e2a760e6fdd@dansarie.se>
In-Reply-To: <9ae82731-6c9c-6c66-6088-2e2a760e6fdd@dansarie.se>
From: Watson Ladd <watson@cloudflare.com>
Date: Tue, 30 Apr 2019 17:02:38 -0700
Message-ID: <CAN2QdAHAoM01-typ5m+EP03c3dx5O1AEbda1t-t3iY5bvMLrgQ@mail.gmail.com>
To: Marcus Dansarie <marcus@dansarie.se>
Cc: "ntp@ietf.org" <ntp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/IJtGW9Jc-eq6CjbO1cfKgWTqXD0>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-using-nts-for-ntp-18.txt
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, 01 May 2019 00:02:53 -0000

On Tue, Apr 23, 2019 at 12:32 PM Marcus Dansarie <marcus@dansarie.se> wrote:
>
>
> Thanks for your comments! See my comments inline.
>
> Kind regards,
> Marcus
>
>
> On 2019-04-22 10:06, Hal Murray wrote:
> >
> > Typo, page 20:
> >   Duplicate "Nonetheless, "
>
> Thanks! (I submitted a pull request for this last Wednesday.)
>
> >
> > Page 6, single round trip
> >   That's after the TLS setup.  Right?  How many round trips does that take?
>
> Correct, that's one round trip excluding the TLS setup. The setup is
> expected to take two or three round trips depending on version.
> (Theoretically, PSK could bring this down to one round trip, but I do
> not envisage it being used in this application.)
>
> > Page 13: cookies
> >   Do all cookies have to have the same length?
>
> It is not explicitly required by the draft. I can't see any "sane"
> reason for a server to send cookies of different length in the same reply.
>
> A practical reason for changing cookie length is if a server updates its
> (implementation dependent) cookie format. It could then start replying
> with cookies of different length than before. This could possibly create
> problems if the new cookies are longer than the old ones. To avoid
> sending replies that are longer than the requests, the server would have
> to send zero new cookies as reply to requests containing only one cookie
> placeholder in the hope that the client's next request contains two
> cookie placeholders, thus enabling it to send one cookie back.
> Hopefully, as the old cookies are depleted the client then starts
> sending larger cookie placeholder records.
>
I do not read 5.7 as encouraging using multiple cookie placeholder
fields to send a single cookie back. I actually misread the
specification and thought it required the cookie extension to be
longer then the cookie sent in response. Perhaps this should be
rewarded to encourage the server to send the minimum of {1+cookies
requested, 1+number of cookies that fit in total length of cookie
placeholder fields}.