Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)

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

Hello Brian,

Thank you for your reply, I fully agree to all your proposed changes (and of course, with your explanation, my comment on section 2 is no more relevant)

Regards

-éric

-----Original Message-----
From: Brian Haberman <[e-mail]>
Date: Monday, 24 August 2020 at 14:32
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, Karen O'Donoghue <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)

    Hi Éric,
         Thanks for the review! Responses to your questions/comments below.

    Regards,
    Brian

    On 8/21/20 10:32 AM, Éric Vyncke via Datatracker wrote:
    > Éric Vyncke has entered the following ballot position for
    > draft-ietf-ntp-mode-6-cmds-09: No Objection
    > 
    > When responding, please keep the subject line intact and reply to all
    > email addresses included in the To and CC lines. (Feel free to cut this
    > introductory paragraph, however.)
    > 
    > 
    > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    > for more information about IESG DISCUSS and COMMENT positions.
    > 
    > 
    > The document, along with other ballot positions, can be found here:
    > https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/
    > 
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document.
    > 
    > First, I must admit that this is the first time I see an IETF stream
    > informational document for the specification of a control protocol used by an
    > obsoleted RFC 1305. This document is much easier to read than the appendix B of
    > RFC 1305 and the author takes care to write that this spec is not mandatory to
    > implement but I really wonder why this document exists ?
    > 
    > Moreover the abstract says "The goal of this document is to provide a current,
    > but historic, " so why not publishing this document as 'historic' rather than
    > 'informal' (datatracker seems to allow this modification).
    > 

    The document was intended to be published as Historic, but it was
    changed to Informational during IETF Last Call. I fixed the Intended
    Status, but failed to update the Intro/Abstract to point out that this
    specification is intended to document mode-6 so that it is compatible
    with any RFC 5905 implementations that want to use it.

    Would it help if I made the following changes?

    Abstract
    --------

    OLD:
    The goal of this document is to provide a current, but historic,
    description of the control messages as described in RFC 1305 and any
    additional commands implemented in NTP.

    NEW:
    The goal of this document is to provide an updated description of the
    control messages described in RFC 1305 in order to conform with the
    updated Network Time Protocol specification documented in RFC 5905.

    Introduction
    ------------

    OLD:
    The control messages are described here as a historical record given
    their use within NTPv4.

    NEW:
    The control messages are described here as a current reference for use
    with an RFC 5905 implementation.

    > Please find below a couple of non-blocking COMMENTs (and I would appreciate a
    > reply to each of my COMMENTs) and some NITs.
    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == COMMENTS ==
    > 
    > -- Section 1.1 --
    > Suggest to replace 'IP' by 'IPv4' in 'IP hosts are not required to reassemble
    > datagrams larger than 576' + add some text that this document applies the same
    > limitation to IPv6.

    OLD:
    IP hosts are not required to reassemble datagrams larger than 576 octets
    [RFC0791];

    NEW:
    IP hosts are not required to reassemble datagrams over a certain size
    (576 octets for IPv4 [RFC0791] and 1280 octets for IPv6 [RFC2460]);

    > 
    > -- Section 2 --
    > Possibly linked to my lack of understanding of the purpose of this document,
    > but, if applicable only to NTPv3, then should the Version number clearly
    > specified to be 3 ?

    As noted above, this spec is not limited to NTPv3 support, so I don't
    see a need to make a change.

    > 
    > -- Section 3.2 --
    > Suggest to add 'bit' after 'Peer Status' in the table headings to make it clear.

    Will do.

    > 
    > -- Section 4 --
    > It will probably be useful to expand 'MRU' at first use.
    > 

    Will do.

    > In the "Read ordered list (11):" it is not clear how the entries are ordered in
    > the case of "ifstats" is it per local address ? Are IPv4 addresses before IPv6
    > addresses ?
    > 

    I will clarify that it is lexigraphical ordering with IPv4 information
    presented followed by IPv6 information.

    > -- Appendix A --
    > Is there a reason why the mode 7 is in the appendix and not in the main body ?
    > 

    The mode 7 approach is more implementation specific and there was not
    any interest within the WG to standardize anything beyond the frame format.

    > == NITS ==
    > 

    Will fix these.

    > -- Section 2 --
    > s/Conains/Contains/
    > 
    > -- Section 4 --
    > Should there be a comma in 'seven characters "ifstats" the associated' before
    > 'the associated' ?
    > 
    > 
    >