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

[Ulrich Windl <[e-mail]>]

>>> "Eric Vyncke (evyncke)" <evyncke=[e-mail]> schrieb am
24.08.2020 um 15:27 in Nachricht
<[e-mail]>:
> Any order is important because the text says "Read ordered list (11):",
hence 
> my expectation that the list is ordered

While thinking on it: Actually any list is ordered (as opposed to a set):
There is a first element, and a next element until you reached the last one.
However inside the list the items could be "sorted" to some criteria. This is
what we are talking about, right? ;-)

> 
> -é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 
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp