Subject: [Last-Call] Opsdir last call review of draft-ietf-ntp-mode-6-cmds-08

From: Linda Dunbar via Datatracker <[email-masked]>
Date: Mon, 08 Jun 2020 15:52:23 -0700

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?

Thank you.
Linda Dunbar

---

From: Brian Haberman <[email-masked]>
Date: Fri, 12 Jun 2020 13:11:11 -0400

Hi Linda,

> control messages for distributing time from Stratum 0 to Stratum 1?  or between

As Ulrich pointed out, these messages are for controlling/monitoring an
running NTP server. These messages are not meant for server-to-server
exchanges, rather for "management station" to server exchanges.

As for the "who uses it" question, I thought section 1.2 captured a good
representation of that (e.g., ntpdc) for mode 7. Section 1.1 describes
the basic framework for the use of mode 6, but doesn't provide a
concrete example.

I can craft some text for section 1.1 that explicitly talks about
managing NTP servers.

Regards,
Brian

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 12 Jun 2020 17:18:54 +0000

Brian, 

Thank you very much for the explanation. It would be great if you can add this explanation to the draft to make the "Historic" draft more self-explanatory. 

Linda Dunbar

-----Original Message-----
From: Brian Haberman <[email-masked]> 
Sent: Friday, June 12, 2020 12:11 PM
To: Linda Dunbar <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Opsdir last call review of draft-ietf-ntp-mode-6-cmds-08

Hi Linda,

On 6/8/20 6:52 PM, Linda Dunbar via Datatracker wrote:
> 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?

As Ulrich pointed out, these messages are for controlling/monitoring an running NTP server. These messages are not meant for server-to-server exchanges, rather for "management station" to server exchanges.

As for the "who uses it" question, I thought section 1.2 captured a good representation of that (e.g., ntpdc) for mode 7. Section 1.1 describes the basic framework for the use of mode 6, but doesn't provide a concrete example.

I can craft some text for section 1.1 that explicitly talks about managing NTP servers.

Regards,
Brian

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 12 Jun 2020 16:35:46 -0700

> the basic framework for the use of mode 6, but doesn't provide a

The Reference Implementation augmented its mode 6 list to incorporate
functionality that was previously only available via mode 7 packets
about 10 years' ago.

As I wrote in another thread, the format specifications of mode 6 and 7
packets, and the base set of mode 6 packet types deserves full Standards
track status.  In no way are these things informational, let alone
historical.

That some do not implement these is a policy choice.

This document should specify mechanism, not policy.

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

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

---

From: Watson Ladd <[email-masked]>
Date: Fri, 12 Jun 2020 22:31:39 -0400

> functionality that was previously only available via mode 7 packets

One implementation does not define the standard. The so-called
"reference implementation" is being surpassed in functionality by
others, and the NTP WG and IETF consensus is the way the standard is
developed. You've continuously attempted to frustrate this process,
insisting that the historic Network Time Foundation implementation be
given precedence over the concerns raised by others and future plans
of that implementation be maintained rather than the deployed,
demonstrated, systems other people have developed. Part of this has
been a reluctance to abandon failed experiments: no one else has
decided to implement these modes because of limitations in the format.

> track status.  In no way are these things informational, let alone

I don't think an unauthenticated management protocol is appropriate
for standardisation in any place but Historic. This draft has gone
through WG last call with intended status Historic because of these
concerns: I know that several members at the time expressed that they
would be opposed to anything but Informational or Historic. If we
wouldn't standardize rsh or telnet today, we shouldn't standardize
this in a way that encourages usage.

Sincerely,
Watson Ladd

---

From: Brian Haberman <[email-masked]>
Date: Sat, 13 Jun 2020 10:42:40 -0400

Hi Watson & Harlan,

> decided to implement these modes because of limitations in the format.

I agree that a single implementation does not get to drive the NTP
standard. The NTP working group discussed this multiple times over the
past 10+ years and the consensus has been that these commands are not to
the level of a standards-track document. Additionally, I think there are
two statements in RFC 1305 that makes this quite clear...

1. Introduction - "...suggested auxiliary NTP Control Message, which may
be used
when comprehensive network-monitoring facilities are not available..."

2. Appendix B - "Support for these messages is not required in order to
conform to this specification."

> this in a way that encourages usage.

As I mentioned in an earlier message, I am fine with either Historic or
Informational. That is also the sense that I have taken away from the
discussions within the WG.

Regards,
Brian