Subject: [Ntp] Antw: [EXT] Opsdir last call review of draft-ietf-ntp-mode-6-cmds-08

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 09 Jun 2020 08:32:12 +0200

>>> Linda Dunbar via Datatracker <[email-masked]> schrieb am 09.06.2020 um 00:52
in Nachricht
<14380_1591656804_5EDEC163_14380_220_1_159165674337.26758.11645384633524120985@i
tfa.amsl.com>:
> Reviewer: Linda Dunbar
> Review result: Has Nits
> 
> I have reviewed this document as part of the Ops area directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the Ops area directors.
> Document editors and WG chairs should treat these comments just like any 
> other
> last call comments.
> 
> This document describes the structure of the control messages that were
> historically used with the Network Time Protocol. Being historical document, 
> I
> would expect the document to give a description on what the Control Message 
> are
> for, who is the sender, and who is the receiver, is the Control Message
> broadcast to every node in the network? or only between some nodes? The
> document describes the bits in detail for Mode =6 and Mode =7. The RFC1305 
> has
> a lot of information, but can't pinpoint the Control message's purpose. Are 
> the
> control messages for distributing time from Stratum 0 to Stratum 1?  or 
> between
> network nodes?

Hi!

I think these question (if not answered in the document) are very valid ones.
In my view of things the control protocol (both mode 6 and 7) was designed and used to "control" (surprise!) a running NTP daemon, where "controlling" means "see what it is doing" and "change (some) settings". You can also get the current time, but not for adjusting purposes, but for monitoring purposes (more or less at a one-second resolution).
Servers never echange control messages; only admin type of users (processes) initiate requests, and servers answer them (hopefully).

That was my little view of things.

Regards,
Ulrich

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

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 9 Jun 2020 13:07:02 -0700

As I have repeatedly previously stated...

Mode 6 commands (and the basic mode 7 base packet structure) are core
components of the protocol layer of NTP, and deserve a Standards track
document.

The omission of the mode 6/7 specification from 5905 was an oversight.

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

---

From: Hal Murray <[email-masked]>
Date: Tue, 09 Jun 2020 19:12:25 -0700

> components of the protocol layer of NTP, and deserve a Standards track

"Core" is an interesting word.  Mode 6 is certainly handy for monitoring ntpd 
but chronyd seems to work just fine without it.

I think the key idea is that we expect many implementations of NTP to exchange 
mode 3/4 packets (aka time) but there isn't any need for me to be able to 
monitor the details of your servers.  As long the software package I use for 
NTP provides tools to monitor my systems servers, the protocol it uses doesn't 
need an RFC.

For security and privacy reasons monitoring by outside users is likely to be 
administratively prohibited even if it would otherwise work.

I think there are 2 possible documents related to mode 6.  One is historical, 
documenting what the code did when RFC 5905 was published, perhaps updated to 
track changes since then.

The other, probably informational, would describe the outlines of a protocol 
and how to update or extend things as features are added/dropped or 
implementation details are changed.  Perhaps an Appendix would include details 
for specific implementations.

The obvious example of a new feature is NTS.

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 10 Jun 2020 01:44:03 -0700

Hal,

I believe you are talking about "policy" and I am talking about "mechanism".