Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Tal,

Thank you for your answers. They are all perfect for me.

I will let the security AD verify the one about the nonce though.

Regards

-éric

-----Original Message-----
From: Tal Mizrahi <[e-mail]>
Date: Tuesday, 3 March 2020 at 06:53
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Karen O'Donoghue <[e-mail]>, Suresh Krishnan <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)

    Hi Eric,
    
    Many thanks for the comments.
    
    Please see the responses below.
    
    
    On Mon, Mar 2, 2020 at 11:55 AM Éric Vyncke via Datatracker
    <[e-mail]> wrote:
    >
    > -- Section 1.1 --
    > When writing "security protocols a timestamp is often used as a value that is
    > unlikely to repeat (nonce)", I sincerely believes that this is probably
    > misleading as nonce should probably have entropy and be non-predictable. A
    > timestamp does not have those properties. Again, I am trusting my SEC AD peers
    > on their final words.
    >
    
    I suggest the following update:
    OLD:
    a timestamp is often used as a value that is unlikely to repeat (nonce)
    NEW:
    a timestamp is often used as part of a value that is unlikely to repeat (nonce)
    
    
    
    > -- Section 2.1 --
    > Is BCP 14 boilerplate required for an informational document ? I have found
    > only one "MUST" in the security section but again this is weird for an
    > informational document.
    >
    
    Right. The draft only uses two instances of (uppercase) normative
    requirement language words, one in Section 3 (which defines the
    timestamp template) and the other in Section 9 (Security
    Considerations). This is intentional, since these are exactly the
    requirements that the reader is expected to comply to when defining a
    timestamp.
    
    > -- Section 3 --
    > Should the syntax also include the bit ordering ? I.e., little endian of big
    > endian ? Of course the default if network order but what if it is not ?
    >
    >
    >
    
    I propose the following update:
    OLD:
    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.
    NEW:
    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. Network order (big endian) is assumed by
    default; if this is not the case then this section explicitly
    specifies the endianity.