[ntp:hackers] Daughter of RFC-2030

David L. Mills mills at udel.edu
Sun Aug 17 09:11:54 PDT 2003


Jim, folks,

I did an extensive review and markup of the proposed RFC-2030 update,
mainly to crispy-fry the prose and suppress ambiguity. See the PDF at
www.eecis.udel.edu/~mills/reports.html or the NTP project page related
publications section.

>From the text:

This memo is organized as follows. Section 2 describes how the protocol
works, the various modes and how IP addresses and UDP ports are used.
Section 3 describes the NTP timestamp format and Section 4 the NTP
message format. Section 5 summarizes SNTP client operations and Section
6 summarizes SNTP server operations. Section 7 summarizes operation and
management issues. Section 8 describes the kiss-o’-death message newly
minted with functions similar to the ICMP Source Quench and ICMP
Destination Unreachable messages. Section 9 summarizes design issues
important for good network citizenry and presents an example algorithm
designed to give good reliability while minimizing network and server
resource demands.

My primary concern is with Sections 5 and 9, which butchers the meat of
the bull. I want to be sure you guys really believe the design
objectives and algorithms and, if not, talk to me.

And now for other news. The RFC editors have refused to accept the PDF
and insist on Postel ASCII. As my handyman tools to do that no longer
work in modern operating systems and I can find no straightforward way
in FrameMaker or Acrobat to convert PDF to Postel ASCII, I told them
this exercise would not be done by me. I was also told the document must
go through the ID process again, which I find completely without merit,
since it is informational, not standards track.

>From all I can fathom, if this document is to find daylight, an
appropriate task force would have to be mobilized in an appropriate area
and the usual round of Postel ASCII drafts would have to be circulated
and prosecuted in IETF meetings. This is a wonderful idea and should be
prosecuted; however, I have no time or funding or staff or travel to do
that. Accordingly, unless some other organization steps up and is
willing to do the paperwork, travel and politics, I fear the proto-RFC
will stay anchored forever to the NTP project page. Be advised if
somebody else steps to the plate, I would be happy to review and markup
drafts, as long as somebody else suffers the IETF and Postel ASCII
issues.

Frankly, I find the IETF publishing process disgusting, but my opinions
have been strongly expressed to the RFC editors and ignored since
RFC-1305 over ten years ago.

The RFC on Autokey is in the same state of readiness, but the STIME task
force handling the original Postel ASCII they formated has dropped the
ball. A final draft was to be submitted by that task force a year ago,
but that never happened. An updated draft in PDF is also on the NTP
project page, but I fear will stay there indefinitely. Finally, there is
interest in the US Navy to produce a NTPv4 specification, but I have no
stomach for that if the RFC is to end up only on the NTP project page.

Dave



Dave



More information about the hackers mailing list