Hi Watson & Harlan, On 6/12/20 10:31 PM, Watson Ladd wrote: > 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. > 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." >> 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. 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
