What is the utility of this draft RFC?
1) The interface is not well defined. Free form ASCII is a poor choice for
interoperability.
Example: I filed a bug report with the reference ntpd, Bug 3484, for a
specific ntpq - ntpd interop problem and learned that
the draft RFC didn't specify how to encode a null.
2) Some widespread NTP implementations, e.g., chrony, do not support mode 6.
3) Many public NTP servers block mode 6 commands. A few years ago a large
number of public servers under 20% responded to mode 6. See also section 6
of this draft
4) Cleaning up the draft may take substantial effort. Is a new
implementation based on this document likely?
5) Appendix B of RFC1305 seems adequate as a historical note.
Steven Sommars
On Wed, Jun 13, 2018 at 4:46 AM, Karen O'Donoghue <[email protected]>
wrote:
> Folks,
>
> Please respond to this WGLC. The deadline is Friday!
>
> Karen
>
> > On May 31, 2018, at 5:26 AM, Karen O'Donoghue <[email protected]>
> wrote:
> >
> > Folks,
> >
> > This begins a 2 week working group last call for the following document:
> >
> > Control Messages Protocol for Use with Network Time Protocol Version 4
> > https://datatracker.ietf.org/doc/draft-ietf-ntp-mode-6-cmds/
> >
> > Please review the referenced document and send any comments to the
> mailing list including your assessment of whether this document is mature
> enough to proceed to the IESG. Please note that these messages of support
> for progression to the mailing list will be used to determine WG consensus
> to proceed.
> >
> > Please send all comments in by Friday 15 June 2018.
> >
> > Thank you!
> > Karen and Dieter
> >
> >
>
> _______________________________________________
> ntp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ntp
>
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc