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

[Ulrich Windl <[e-mail]>]

>>> Brian Haberman <[e-mail]> schrieb am 24.08.2020 um 17:25
in
Nachricht <[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.

Hi!

Well, actually there is one: Many mode-6 commands provide "output ready"
responses. That means you don't need (or maybe even worse: you cannot easily)
to reformat (here: sort) the results for output. ("rl" output would be one
example)
Actually I think it was a poor design decision to return "output ready" data
as response, because if you want to analyze the data (filtering, sorting,
line-wrapping, etc.) it's more difficult.  Also some responses are still binary
format, needing post-processing before output. It's not very consistent...

Regards,
Ulrich

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