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

[Brian Haberman <[e-mail]>]

Hi Ulrich,

On 8/24/20 9:59 AM, Ulrich Windl wrote:
>>>> "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? ;-)
> 

I have interpreted Éric's query as to what key is used to order the
list. I have spent the past few hours thinking about this and I am
wondering if there is a need for the list to be ordered at all. As long
as the requisite information is indexed by the interface identifier
(i.e., IP address), I can't discern a reason to order the list.

Regards,
Brian

>>
>> -é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 
> 
> 
>