On Fri, Jun 12, 2020 at 7:35 PM Harlan Stenn <stenn@xxxxxxxxxx> wrote: > > > > On 6/12/2020 10:11 AM, Brian Haberman wrote: > > 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. > > The Reference Implementation augmented its mode 6 list to incorporate > functionality that was previously only available via mode 7 packets > about 10 years' ago. 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. > 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. 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
