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

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

Any order is important because the text says "Read ordered list (11):", hence my expectation that the list is ordered

-éric

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

    One question before I fall asleep. 

    Why is the lexicographic order if the addresses returned by ifstats significant?

    Sent from my iPhone - please excuse brevity and typos

    > On Aug 24, 2020, at 6:12 AM, Eric Vyncke (evyncke) <evyncke=[e-mail]> wrote:
    > 
    > 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' ?
    >> 
    >> 
    >> 
    > 
    > 
    > _______________________________________________
    > ntp mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/ntp