Re: [Ntp] Genart last call review of draft-ietf-ntp-packet-timestamps-07

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Sun, 16 February 2020 14:21 UTC

Return-Path: <tal.mizrahi.phd@gmail.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 64A18120048; Sun, 16 Feb 2020 06:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QbPX0VG7CBa8; Sun, 16 Feb 2020 06:21:12 -0800 (PST)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 EAFDC12001E; Sun, 16 Feb 2020 06:21:08 -0800 (PST)
Received: by mail-wr1-x432.google.com with SMTP id y11so16506218wrt.6; Sun, 16 Feb 2020 06:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V7IFCm/AHlTFw00NXyS3lIXcMsG3NjaIfacCqM29hxE=; b=pP0Hzebf03dJSZ1oXXjorLqD2QDW//lPopK1qEtOgVVj5gznn9sy3oJs+QF1ZN7Mp6 SqKx+B7+XY14Y+tbmna8tjLsItbyfm8XncpieZwbkFXV+yioWY3mNlCq06NwYPIEUh1O Fosy9Bjk6o4MLIROcvHAl8xbm/JJDdj8+J2jhH026TOK1ZxPxytzF7OqYCO4eawz7p7u ly7D0bZRc2VOz3UK6jPvlJ83g4a9LwsZPV2OfKqaMmbstMTjquSz+d0hBjf7qUmfx/7u dbBtoGbAJDeHLB+hQxj6TyD6HzG8bZ9tNgsc5Z4oJEgRmkon54e7IcDe/1zvY43PHb0G NhDw==
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=V7IFCm/AHlTFw00NXyS3lIXcMsG3NjaIfacCqM29hxE=; b=Gng6XK3CsGfs2H6644lHofZMrmBJ5bTex2SWzYyU2PNQxQREPItDe7v08lgNd6MxFV gWLKrkz94yl+g8FWJMVnSmRrmy4TDAAB2zYLljBSCWrmif9AoXBomoc0HWQZhO4uuLaT DAHb+mHsoaJnIou8bMrpQfol3xcftBYsI4Naqg/uG7zbZOsKJYptHD0alFdVL9vcCve0 Ic4L8ZP4n7VDmYxi4XSCE2YhFbPsKujoGHrZXEt86WA1pcN+P/bxr/VuE3FU/l5sVPE9 tKKXgAWKPSWDGJ9wcRJLyoEmpGSX0b5irK+7puVZTulGCT+Bgc/+XHVXKvT7lVl8uGZe Y6jg==
X-Gm-Message-State: APjAAAXruwpePeZro+Rx3ixwvuqz6Vt3lPmFqumEWd76sS21QJ7d0RP6 QtbbEuUonjQPK3x7duEzZmAllOvDfVI41SGMwYyv/i7CpwQ=
X-Google-Smtp-Source: APXvYqzd/KlqXTBnZg47N4W7GvMz81xhdoCUWVEkx948WGmUKkQZtz38ozLN4bx20FZkNdK10+G5jjfwBMzEo/ROPQo=
X-Received: by 2002:a5d:4ed0:: with SMTP id s16mr16416634wrv.144.1581862867326; Sun, 16 Feb 2020 06:21:07 -0800 (PST)
MIME-Version: 1.0
References: <158110455747.11678.12613654963980490395@ietfa.amsl.com>
In-Reply-To: <158110455747.11678.12613654963980490395@ietfa.amsl.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Sun, 16 Feb 2020 16:20:56 +0200
Message-ID: <CABUE3XmtYXd3-ADaE3_P21MiAgrS-_b8Xey29J1XjBC_6+2x-Q@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: gen-art@ietf.org, last-call@ietf.org, ntp@ietf.org, draft-ietf-ntp-packet-timestamps.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/hy_ZmxF4i-2NGlG3j6aYMZ0gAWE>
Subject: Re: [Ntp] Genart last call review of draft-ietf-ntp-packet-timestamps-07
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: Sun, 16 Feb 2020 14:21:15 -0000

Hi Russ,

Many thanks for the thorough review.

Please see the proposed changes below and let us know if they make
sense. If there are no further comments we will implement these
changes along with other changes following IETF last call.

Cheers,
Tal.


On Fri, Feb 7, 2020 at 9:42 PM Russ Housley via Datatracker
<noreply@ietf.org> wrote:
>
> Reviewer: Russ Housley
> Review result: Almost Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-ntp-packet-timestamps-07
> Reviewer: Russ Housley
> Review Date: 2020-02-07
> IETF LC End Date: 2020-02-20
> IESG Telechat date: Unknown
>
>
> Summary: Almost Ready
>
> Major Concerns: None
>
>
> Minor Concerns:
>
> Abstract: It is too long.  In my opinion, the second paragraph should
> be moved to the Introduction.

[TM] Agreed.

>
>
> Section 2.1: Please use:
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
>    "OPTIONAL" in this document are to be interpreted as described in
>    BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
>    capitals, as shown here.
>

[TM] Agreed.

>
> Section 2.3, paragraph 1: I think it would be better to define timestamp
> error without using the phrase "device under test".  If you disagree,
> please add a definition for "device under test".
>

[TM] We propose the following text update:
OLD:
Timestamp error: The difference between the timestamp value at the
device under test and the value of a reference clock at the same time
instant.
NEW:
Timestamp: A value that represents a point in time, corresponding to
an event that occurred or is scheduled to occur.
Timestamp error: The difference between the timestamp value and the
value of a reference clock at the time of the event that the timestamp
was intended to indicate.


>
> Section 3, Synchronization aspects: The paragraph should also say that
> there might not be any synchronization considerations.  For example, an
> epoch since the device was powered up does not have any.
>


[TM] We propose the following text update:
OLD:
Synchronization aspects:

The specification of a network protocol that makes use of a packet
timestamp is expected to include the synchronization aspects of using
the timestamp. While the synchronization aspects are not strictly part
of the timestamp format specification, these aspects provide the
necessary context for using the timestamp within the scope of the
protocol. Further details about synchronization aspects are discussed
in Section 5.

NEW:
Synchronization aspects:

The specification of a network protocol that makes use of a packet
timestamp is expected to include the synchronization aspects of using
the timestamp. While the synchronization aspects are not strictly part
of the timestamp format specification, these aspects provide the
necessary context for using the timestamp within the scope of the
protocol. In some cases timestamps are used without synchronization,
e.g., a timestamp that indicates the number of seconds since power up.
In such cases the Synchronization Aspects section will specify that
the timestamp does not correspond to a synchronized time reference,
and may discuss how this affects the usage of the timestamp. Further
details about synchronization aspects are discussed in Section 5.


>
> Section 9:  Please say "such as Message Authentication Codes (MAC)".
> HMAC is one instance of a MAC, and you are not trying to name a specific
> algorithm here.
>

[TM] Agreed.

>
> Section 11.2:  RFC 1323 has been obsoleted by RFC 7323.  Is there a
> reason that it is better ot reference the older document here?
>

[TM] Agreed.

>
> Nits:
>
> General: Some places this Internet-Draft refers to itself as "this memo"
> and other places if refers to itself as "this document".  Please pick.
>

[TM] Agreed.

>
> Section 1, paragraph 1: Nonces often have a timestamp embedded in them.
> For example, TLS 1.2 [RFC5246] defined the nonce as:
>
>          struct {
>              uint32 gmt_unix_time;
>              opaque random_bytes[28];
>          } Random;
>
> So, I think the paragraph should include something about using time to
> create an unlikely to repeat value.
>

[TM] We propose the following text update:
OLD:
Timestamps are widely used in network protocols for various purposes,
including delay measurement, clock synchronization, and logging or
reporting the time of an event.
NEW:
Timestamps are widely used in network protocols for various purposes:
timestamps are used for logging or reporting the time of an event,
delay measurement and clock synchronization protocols both make use of
timestamped messages, and in security protocols a timestamp is often
used as a value that is unlikely to repeat (nonce).


>
> Section 3: I do not find the "+" improves readability.

[TM] Agreed. We will use a different bullet symbol.


>
> Section 3 says:
>
>       The structure of the timestamp field consists of:
>
>       + Size: The number of bits (or octets) used to represent the
>       packet timestamp field.  If the timestamp is comprised of more
>       than one field, the size of each field is specified.
>
> Since there is only one item, I suggest:
>
>       Size: The structure of the timestamp field consists of the number
>       of bits (or octets) used to represent the packet timestamp field.
>       If the timestamp is comprised of more than one field, the size of
>       each field is specified.

[TM] Agreed.


> Questions:
>
> Should RFC 6019 be included in the table in Section 6?

[TM] Agreed.