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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 21 Aug 2020 07:32:53 -0700

É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).

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.

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

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

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

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 ?

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

== NITS ==

-- Section 2 --
s/Conains/Contains/

-- Section 4 --
Should there be a comma in 'seven characters "ifstats" the associated' before
'the associated' ?

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 24 Aug 2020 07:52:26 +0200

>>> Éric Vyncke via Datatracker <[email-masked]> schrieb am 21.08.2020 um
16:32
in Nachricht <[email-masked]>:
> 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

I don't know what qualifies as "historic", but the protocol is implemented in
the _current_ NTPv4 implementation, while the specification was left ot from
the NTP v4 RFC. I also think NTP would be quite useless without that mode-6
protocol or a well-established substitute for that (which does not exist yet
AFAIK).

> 
> Please find below a couple of non-blocking COMMENTs (and I would appreciate

> a

...or specify what the version number really is intended to express.

> In the "Read ordered list (11):" it is not clear how the entries are ordered

> in

Is this ordering really important?

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

> ?

Because it's a different (and really obsolete) protocol. At least per
specification, maybe not by implementation.

> _______________________________________________
> ntp mailing list
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Aug 2020 01:52:45 -0700

On 8/23/2020 10:52 PM, Ulrich Windl wrote:
>...

No, it is not obsolete.  Mode 7 is for vendor-specific operations.

It is there to carve a space for implementation/vendor-specific stuff.

-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 24 Aug 2020 09:50:44 +0000

Hello Ulrich

Thank you for your reply. Please see in-line for EVY>

NB: all the COMMENT points are non-blocking and their intent is only to improve the document.

Regards

-éric

-----Original Message-----
From: Ulrich Windl <[email-masked]>
Date: Monday, 24 August 2020 at 07:52
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Antw: [EXT] [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)

    16:32

EV> Thank you, I know understand the purpose of this document. May I suggest to rewrite the abstract and introduction to make this clear ?

    > I hope that this helps to improve the document,

...%<.........%<........

EV> my question about ordering is only because this is a "Read ordered list" so the reader/implementer will assume that the list is ordered, hence my question about ordering IPv4 vs. IPv6 __

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 24 Aug 2020 12:34:47 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 24.08.2020 um 10:52 in
Nachricht
> No, it is not obsolete.  Mode 7 is for vendor-specific operations.

You mean mode 7 has been "reassigned"? Otherwise you contradict to what you
were postulating many times before.
It seems I don't quite understand: If leaving mode-7 to solely
vendor-implementation, there will be a true protocol mess.
At least some framework to implement vendor-specific operations is needed
IMHO.
So a server would hopefully recognize at least that it does not understand the
command being received and return an error message that the client can
decode...

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Aug 2020 04:41:48 -0700

> command being received and return an error message that the client can

Sorry, Ulrich - I don't know what you're talking about.

Mode 6 has always been "control mode", and has been expected to have
standard/common assignments.  I believe the document could/should cover
more than it does, just like I expect a lot more from the NTP Yang Data
Model document.  I continue to believe that there needs to be a
standardized way to exchange minimally-expected "control mode" data with
an NTP server via mode 6, and there needs to be a good way for
implementations to augment the minimal set of mode 6 subcommands.

Mode 7 has always been "private mode", and is expected to be
vendor/implementation specific.

This is all described in RFC-1305, Appendix D, section 2.

The document we're talking about here is the WG's attempt to fix at
least the oversight of 5905 not talking about mode 6.

Folks should be able to infer the NTP Project's position of this
document by my vote on the document.

With regard to mode 7, I'm not aware of any attempts by the WG to
document anything beyond what RFC5905 contains in 7.3 Packet Header
Variables beyond that in Figure 10, Association Modes, and given that
mode 7 is "reserved for private use", I'm not sure what anybody might
want for that.  Mode 7 has and continues to be a control message for
vendor/implementation specific use.

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 24 Aug 2020 13:59:32 +0200

>>> Harlan Stenn <[email-masked]> schrieb am 24.08.2020 um 13:41 in
Nachricht
<[email-masked]>:

>> So a server would hopefully recognize at least that it does not understand

> the

Hi!

it's about "Mode 7 is for vendor-specific operations.". I read it that
different implementation may use mode-7 to implement arbitrary protocols with
that, while currently there's (AFAIK) exactly one "vendor" that had an
implementation. So not to make matters worse, I'd make this obsolete now,
allowing to redefince that in a useful way later for NTP version 6 or so.

Regards,
Ulrich

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Aug 2020 05:19:11 -0700

> allowing to redefince that in a useful way later for NTP version 6 or so.

You mean the reference implementation, and by far the dominant installed
instance?

For many years' time, there were command/control options that were only
available via mode 7.   About 10 years' ago we made sure that most
anything one could only accomplish with mode 7 directives could also be
implemented with mode 6 directives.  While it's still possible to do
these things with mode 7, we're trying to shift them to mode 6.  This
also goes to my point in other messages about how we need to have a
basic set of standardized mode 6 directives, and a basic/minimal set of
data entities that are accessible thru this mechanism.  IMO, there also
needs to be:

- a relatively easy way to augment the minimal element list
- a standard way to learn about the range, format, and description
  of the available elements

I'm not currently in favor of deprecating mode 7 because it might be
useful for something else somewhere down the road.

For example, mode 7 could well be a good way to develop and test
experimental directives that could become mode 6 directives.  There
could well be other uses for mode 7 directives.

---

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Aug 2020 08:32:33 -0400

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

Regards,
Brian

> https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/

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.

> datagrams larger than 576' + add some text that this document applies the same

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]);

> but, if applicable only to NTPv3, then should the Version number clearly

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

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

Will do.

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

Will do.

> the case of "ifstats" is it per local address ? Are IPv4 addresses before IPv6

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

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

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Aug 2020 05:52:15 -0700

Thanks, Brian!

For whatever it's worth, I agree.

Having said that, I haven't looked at how the reference implementation
handles the lexicographic ordering of IPv4 and IPv6 addresses in the
ifstats response.

H

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 24 Aug 2020 13:12:38 +0000

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 <[email-masked]>
Date: Monday, 24 August 2020 at 14:32
To: Eric Vyncke <[email-masked]>, The IESG <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, Karen O'Donoghue <[email-masked]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)

    Hi Éric,

    Regards,
    Brian

    Abstract
    --------

    OLD:

    NEW:

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

    OLD:

    NEW:

    OLD:

    NEW:

    Will do.

    Will do.

    Will fix these.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Aug 2020 06:18:24 -0700

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=[email-masked]> wrote:
> 
> Hello Brian,
>

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 24 Aug 2020 13:27:00 +0000

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

-éric

---

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Aug 2020 09:27:34 -0400

Hi Harlan,

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

The text Éric is referring to is this: "Read ordered list (11):
Retrieves an ordered list" and I interpreted his question to be "how are
they ordered".

My recollection is that lexicographic ordering is used. If that is not
the case, or that ordering is unimportant, please let me know.

Regards,
Brian

---

From: "Ulrich Windl" <[email-masked]>
Date: Mon, 24 Aug 2020 15:59:32 +0200

>>> "Eric Vyncke (evyncke)" <evyncke=[email-masked]> schrieb am
24.08.2020 um 15:27 in Nachricht
<[email-masked]>:
> 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? ;-)

> Cc: Brian Haberman <[email-masked]>, The IESG <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>,

> "[email-masked]" <[email-masked]>,

> Karen O'Donoghue <[email-masked]>
> Subject: Re: [Ntp]  Éric Vyncke's No Objection on 
> draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)
> 
>     > On Aug 24, 2020, at 6:12 AM, Eric Vyncke (evyncke) 
> <evyncke=[email-masked]> 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
>     > 
>     > Cc: <[email-masked]>, <[email-masked]>, 
> <[email-masked]>, Karen O'Donoghue <[email-masked]>
>     > Subject: Re: Éric Vyncke's No Objection on 
> draft-ietf-ntp-mode-6-cmds-09: (with COMMENT)
>     > 
>     >    Hi Éric,
>     >> Please refer to 
> https://www.ietf.org/iesg/statement/discuss-criteria.html 
>     >> informational document for the specification of a control protocol
used 
> by an
>     >> Moreover the abstract says "The goal of this document is to provide a

> current,
>     >    The control messages are described here as a current reference for

> use
>     >> datagrams larger than 576' + add some text that this document applies

> the same
>     >> Suggest to add 'bit' after 'Peer Status' in the table headings to
make 
> it clear.
>     >> In the "Read ordered list (11):" it is not clear how the entries are

> ordered in
>     >> Is there a reason why the mode 7 is in the appendix and not in the
main 
> body ?
>     >    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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 24 Aug 2020 11:25:01 -0400

Hi Ulrich,

> 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

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 25 Aug 2020 07:51:35 +0200

>>> Brian Haberman <[email-masked]> schrieb am 24.08.2020 um 17:25
in
Nachricht <[email-masked]>:
>> However inside the list the items could be "sorted" to some criteria. This

> is

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

>>>     >         Thanks for the review! Responses to your questions/comments

>>> below.
>>>     >    Status, but failed to update the Intro/Abstract to point out that

>>> this
>>>     >    The goal of this document is to provide an updated description of

>>>     >> Suggest to replace 'IP' by 'IPv4' in 'IP hosts are not required to

>>> reassemble
>>>     >    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
>>>     >> Possibly linked to my lack of understanding of the purpose of this

>>> document,
>>>     >> the case of "ifstats" is it per local address ? Are IPv4 addresses

>>> before IPv6
>>>     >    The mode 7 approach is more implementation specific and there was

>>> not

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 25 Aug 2020 07:57:57 +0200

>>> Brian Haberman <[email-masked]> schrieb am 24.08.2020 um 17:25 in

Hi!

Actually what I wanted to say is: The phrase "ordered list" is a mis-nomer (as any list is ordered); it should be "sorted list" IMHO.

Regards,
Ulrich
[...]