Commit 399b088a authored by Richard Laager's avatar Richard Laager Committed by Eric S. Raymond

Reference RFCs consistently

Use RFC xxxx, not RFC-xxxx or RFCxxxx.
parent a7657586
......@@ -5,8 +5,8 @@
This software should build on any operating system conformant to
POSIX.1-2001 and ISO/IEC 9899:1999 (C99). In addition, the operating
system must have an ntp_adjtime(2) call or the older BSD adjtime(2)
call. Also, it must support the IPv6 API defined in RFC2493 and
RFC2553. Finally, it must support iterating over active UDP interfaces
call. Also, it must support the IPv6 API defined in RFC 2493 and
RFC 2553. Finally, it must support iterating over active UDP interfaces
via getifaddrs(3) or some equivalent facility.
There are some prerequisites. Libraries need the binary installed
......@@ -213,7 +213,7 @@ Here's what it presently does:
* Reverts the default baudrate of the NMEA driver to 4800 (from 9600).
* Restores the old (non-RFC3339) format of logfile timestamps.
* Restores the old (non-RFC 3339) format of logfile timestamps.
Other behaviors may be added in future releases.
......
......@@ -56,7 +56,7 @@ Here are the non-standardized APIs that may be used:
* Either ntp_adjtime() or the older BSD adjtime(2).
* Berkeley sockets and the IPv6 API defined in RFC2493 and RFC2553.
* Berkeley sockets and the IPv6 API defined in RFC 2493 and RFC 2553.
* getifaddrs(3) or an equivalent local API for iterating over the
system's active UDP interfaces. However, the local details should be
......@@ -225,7 +225,7 @@ goal to aim at, given our choice of scripting languages, is
is to make writing script wrappers in Python easy.
There is more than one way to arrange this. If you can design a
simple tabular output format, or something resembling an RFC2822 header
simple tabular output format, or something resembling an RFC 2822 header
that's easy for both human eyes and programs to parse, do that.
Besides being simple, formats like these are easily handled by either
Python or shellscripts.
......@@ -246,7 +246,7 @@ You can read about JSON at http://www.json.org/
Be aware that if you present a tool design with a messy output format
and no JSON option it is quite likely to be rejected.
Our preferred format for dates is RFC3339 (a version of ISO8601 for
Our preferred format for dates is RFC 3339 (a version of ISO8601 for
UTC with some options frozen; full year required, medial T required,
explicit Zulu timezone). Local times should be expressed in ISO8601,
always with full 4-digit year.
......
......@@ -216,7 +216,7 @@ access to all but correctly authenticated clients..
[[formats]]
== Data Formats ==
The NTPv4 specification (RFC-5905) allows any one of possibly 65,534
The NTPv4 specification (RFC 5905) allows any one of possibly 65,534
message digest keys (excluding zero), each distinguished by a 32-bit key
ID, to authenticate an association. The servers and clients involved
must agree on the key ID, key type and key to authenticate NTP packets.
......
......@@ -39,7 +39,7 @@ or IPv6). For multicast addresses the IANA has assigned the multicast
group address IPv4 224.0.1.1 and IPv6 ff05::101 (site local)
exclusively to NTP, but other nonconflicting addresses can be used.
If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is
If the Basic Socket Interface Extensions for IPv6 (RFC 2553) is
detected, support for the IPv6 address family is generated in addition
to the default IPv4 address family. IPv6 addresses can be identified by
the presence of colons ":" in the address field. IPv6 addresses can be
......
......@@ -110,7 +110,7 @@ as authors of this work.
<duwe@immd4.informatik.uni-erlangen.de>] Linux port
* mailto:dennis@mrbill.canet.ca[Dennis Ferguson
<dennis@mrbill.canet.ca>] foundation code for NTP Version 2 as specified
in RFC-1119
in RFC 1119
* mailto:jhay@icomtek.csir.co.za[John Hay
<jhay@icomtek.csir.co.za>] IPv6 support and testing
* mailto:davehart@davehart.com[Dave Hart <davehart@davehart.com>]
......@@ -138,7 +138,7 @@ as authors of this work.
* mailto:louie@ni.umd.edu[Louis A. Mamakos <louie@ni.umd.edu>]
MD5-based authentication
* mailto:thorinn@diku.dk[Lars H. Mathiesen <thorinn@diku.dk>]
adaptation of foundation code for Version 3 as specified in RFC-1305
adaptation of foundation code for Version 3 as specified in RFC 1305
* mailto:mayer@ntp.org[Danny Mayer <mayer@ntp.org>]Network I/O,
Windows Port, Code Maintenance
* mailto:mills@udel.edu[David L. Mills <mills@udel.edu>] Version 4
......
......@@ -21,7 +21,7 @@ This page discusses +ntpd+ program monitoring and debugging techniques
using the link:ntpq.html[+ntpq+ - standard NTP query program], either
on the local server or from a remote machine. The +ntpq+ program
implements the management functions specified in the NTP specification
https://tools.ietf.org/html/rfc5905[RFC-5905]. In addition, the
https://tools.ietf.org/html/rfc5905[RFC 5905]. In addition, the
program can be used to send remote configuration commands to the
server.
......
......@@ -121,8 +121,8 @@ multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to
NTP, but these addresses should be used only where the multicast span
can be reliably constrained to protect neighbor networks. In general,
administratively scoped IPv4 group addresses should be used, as
described in RFC-2365, or GLOP group addresses, as described in
RFC-2770.
described in RFC 2365, or GLOP group addresses, as described in
RFC 2770.
A multicast server is configured using the +broadcast+ command, but
specifying a multicast address instead of a broadcast address. Note
......@@ -156,7 +156,7 @@ some number of the "best" of the nearby manycast servers, yet
automatically reconfigures to sustain this number of servers should
one or another fail.
The manycast paradigm is not the anycast paradigm described in RFC-1546,
The manycast paradigm is not the anycast paradigm described in RFC 1546,
which is designed to find a single server from a clique of servers
providing the same service. The manycast paradigm is designed to find a
plurality of redundant servers satisfying defined optimality criteria.
......
......@@ -162,7 +162,7 @@ decidedly beyond the scope of this page.
+./ntpd/ntp_control.c+::
The +clocktypes+ array is used for certain control message displays
functions. It should be initialized with the reference clock class
assigned to the driver, as per the NTP specification RFC-1305. See the
assigned to the driver, as per the NTP specification RFC 1305. See the
+./include/ntp_control.h+ header file for the assigned classes.
+./ntpd/refclock_conf.c+::
This file contains a list of external structure definitions which are
......
......@@ -173,7 +173,7 @@ link:refclock.html[Reference Clock Drivers]
1. Mogul, J., D. Mills, J. Brittenson, J. Stone and U. Windl.
Pulse-per-second API for Unix-like operating systems, version 1. Request
for Comments RFC-2783, Internet Engineering Task Force, March 2000, 31
for Comments RFC 2783, Internet Engineering Task Force, March 2000, 31
pp.
== Author ==
......
......@@ -4,7 +4,7 @@
+controlkey+ _key_::
Specifies the key identifier to use with the
{ntpqman} utility, which uses the standard protocol defined in
RFC-5905. The _key_ argument is the key identifier for a trusted key,
RFC 5905. The _key_ argument is the key identifier for a trusted key,
where the value can be in the range 1 to 65,534, inclusive.
+crypto+ [+cert+ _file_] [+leap+ _file_] [+randfile+ _file_] [+host+ _file_] [+sign+ _file_] [+gq+ _file_] [+gqpar+ _file_] [+iffpar+ _file_] [+mvpar+ _file_] [+pw+ _password_]::
......
......@@ -18,9 +18,9 @@ ntpd
The +ntpd+ utility is an operating system daemon which sets and
maintains the system time of day in synchronism with Internet standard
time servers. It is a complete implementation of the Network Time
Protocol (NTP) version 4, as defined by RFC-5905, but also retains
compatibility with version 3, as defined by RFC-1305, and versions 1 and
2, as defined by RFC-1059 and RFC-1119, respectively.
Protocol (NTP) version 4, as defined by RFC 5905, but also retains
compatibility with version 3, as defined by RFC 1305, and versions 1 and
2, as defined by RFC 1059 and RFC 1119, respectively.
The +ntpd+ utility does most computations in 64-bit floating point
arithmetic and does relatively clumsy 64-bit fixed point operations only
......@@ -579,25 +579,25 @@ equivalent of -Z) in older versions.
== STANDARDS ==
RFC1059::
David L. Mills, _Network Time Protocol (Version 1)_, RFC1059
RFC 1059::
David L. Mills, _Network Time Protocol (Version 1)_, RFC 1059
RFC1119::
David L. Mills, _Network Time Protocol (Version 2)_, RFC1119
RFC 1119::
David L. Mills, _Network Time Protocol (Version 2)_, RFC 1119
RFC1305::
David L. Mills, _Network Time Protocol (Version 3)_, RFC1305
RFC 1305::
David L. Mills, _Network Time Protocol (Version 3)_, RFC 1305
RFC5905::
RFC 5905::
David L. Mills and J. Martin, Ed. and J. Burbank and W. Kasch, _Network
Time Protocol Version 4: Protocol and Algorithms Specification_, RFC5905
Time Protocol Version 4: Protocol and Algorithms Specification_, RFC 5905
RFC5907::
RFC 5907::
H&#x2e; Gerstung and C. Elliott and B. Haberman, Ed., _Definitions of Managed
Objects for Network Time Protocol Version 4: (NTPv4)_, RFC5907
Objects for Network Time Protocol Version 4: (NTPv4)_, RFC 5907
RFC5908::
RFC 5908::
R&#x2e; Gayraud and B. Lourdelet, _Network Time Protocol (NTP) Server Option
for DHCPv6_, RFC5908
for DHCPv6_, RFC 5908
//end
......@@ -11,7 +11,7 @@
The +ntpq+ utility program is used to monitor NTP daemon +ntpd+
operations and determine performance. It uses the standard NTP mode 6
control message formats defined in Appendix B of the NTPv3 specification
RFC1305. The same formats are used in NTPv4, although some of the
RFC 1305. The same formats are used in NTPv4, although some of the
variable names have changed and new ones added. The description on this
page is for the NTPv4 variables.
......
......@@ -40,7 +40,7 @@ measured by +ntptrace+; this is why it is not always zero for
servers) the reference clock ID. All times are given in seconds. Note
that the stratum is the server hop count to the primary source, while
the synchronization distance is the estimated error relative to the
primary source. These terms are precisely defined in RFC-1305.
primary source. These terms are precisely defined in RFC 1305.
== OPTIONS ==
......
......@@ -33,7 +33,7 @@ The Network Time Protocol software contained in this
distribution is available without charge under the conditions set
forth in the link:copyright.html[Copyright Notice].
This distribution is an implementation of RFC-5905 "Network Time
This distribution is an implementation of RFC 5905 "Network Time
Protocol Version 4: Protocol and Algorithms Specification". NTP is
widely used to synchronize a computer to Internet time servers or
other sources, such as a radio or satellite receiver or telephone
......@@ -70,7 +70,7 @@ two!), easier to understand, and easier to maintain.
We retain, however, almost full compatibility and interoperation with
NTP Classic. The qualification "almost" is required mainly because we
do not support the Autokey (RFC5906) public-key encryption scheme. It
do not support the Autokey (RFC 5906) public-key encryption scheme. It
had interoperability and exploitable vulnerability issues too severe
to be patched. We are participating in an IETF effort to develop
better security features.
......@@ -155,7 +155,7 @@ few will be user-visible.
ypur current directory.
* It is now possible to set the peer maximum dispersion with "tos
maxdisp". See RFC5905 for discussion of this synchronization
maxdisp". See RFC 5905 for discussion of this synchronization
parameter.
* For the generic (parse) driver only: Using the new refclock syntax,
......
......@@ -64,7 +64,7 @@ Body:
|
{millshome}database/reports/kern/kernb.pdf[PDF]
3. Mills, D.L. A kernel model for precision timekeeping. Network
Working Group Report RFC-1589, University of Delaware, March 1994. 31
Working Group Report RFC 1589, University of Delaware, March 1994. 31
pp. {millshome}database/rfc/rfc1589.txt[ASCII]
'''''
......
......@@ -15,7 +15,7 @@ include::includes/misc.txt[]
== Introduction ==
RFC-2783 describes the PPSAPI application programming interface for
RFC 2783 describes the PPSAPI application programming interface for
external precision time signals, such as the pulse-per-second (PPS)
signal generated by some radio clocks and cesium oscillators. The PPSAPI
provides a generic capability in the ubiquitous Unix kernel which can be
......@@ -27,7 +27,7 @@ a level converter/pulse generator such as described on the
link:pps.html[Pulse-per-second (PPS) Signal Interfacing] page. In some
systems a parallel port can be used for the same purpose.
The PPSAPI interface defined in RFC-2783 is the only PPS interface
The PPSAPI interface defined in RFC 2783 is the only PPS interface
supported in NTP Version 4. The PPSAPI is supported in stock FreeBSD
and, with the addition of the +PPSkit+ kernel module, in Linux.
......
......@@ -65,7 +65,7 @@ include::includes/misc-options.txt[]
+maxdisp+ 'maxdispersion';;
Specify the maximum dispersion used by the clock synchronization
algorithm. The default is 16s. This is also the dispersion
assigned to missing data. See RFC5905 for discussion.
assigned to missing data. See RFC 5905 for discussion.
+minclock+ 'minclock';;
Specify the number of servers used by the clustering algorithm as
the minimum to include on the candidate list. The default is 3. This
......
......@@ -119,7 +119,7 @@ instruction to set a string-valued variable to the empty string.
Textual responses may end with padding NULs; clients should ignore
these.
In RFC5234 ABNF:
In RFC 5234 ABNF:
-----------------------------------------------------------
varlist = item [itemtail] LF *%x00
......
......@@ -182,7 +182,7 @@
the same RS-232 connector (see <<in-band time>>).
The advantage of a PPS signal is improved accuracy. Most OSes have
provisions to grab a timestamp at interrupt time. The API is described
in RFC-2783.
in RFC 2783.
[[PTP]] PTP::
https://en.wikipedia.org/wiki/Precision_Time_Protocol[Precision Time
......@@ -198,7 +198,7 @@
out service addresses at random from the pool.
[[proventic]] proventic:: <<Mills-speak>> for "the transitive completion of the
authentication relationship", defined in RFC5906. Time is proventic
authentication relationship", defined in RFC 5906. Time is proventic
if it is provided by a chain of time servers between which packets
are authenticated and the chain reaches back to Stratum 1.
......
......@@ -54,7 +54,7 @@ preferred choice.
This page presents an overview of the NTP implementation included in
this software distribution. We refer to this implementation as the
_reference implementation_ only because it was used to test and validate
the NTPv4 specification RFC-5905. It is best read in conjunction with
the NTPv4 specification RFC 5905. It is best read in conjunction with
the briefings and white papers on the
{millshome}ntp.html[Network Time Synchronization
Research Project] page. An executive summary suitable for management and
......@@ -100,7 +100,7 @@ Figure 1. NTP Timestamp format
Figure 1 shows the timestamp format used in packet headers exchanged
between clients and servers. Ordinarily, this timestamp format is not
seen by application programs, which converts it to native formats such
as ISO8601 or RFC822-style Gregorian-calendar dates.
as ISO8601 or RFC 822-style Gregorian-calendar dates.
The timestamp format spans 136 years, called an _era_. Conceptually,
it is helpful to think of an absolute dates as being a tuple of one of
......
......@@ -43,7 +43,7 @@
*
* Standards:
*\li BSD Socket API
*\li RFC2553
*\li RFC 2553
*/
/***
......
......@@ -66,7 +66,7 @@ Note that only those options applicable to each command are listed
below. Use of options not listed may not be caught as an error, but
may result in some weird and even destructive behavior.
If the Basic Socket Interface Extensions for IPv6 (RFC-2553) is
If the Basic Socket Interface Extensions for IPv6 (RFC 2553) is
detected, support for the IPv6 address family is generated in addition
to the default support of the IPv4 address family. In a few cases,
including the reslist billboard generated by ntpq, IPv6 addresses are
......@@ -270,7 +270,7 @@ One of the following exit values will be returned:
In addition to the manual pages provided, comprehensive documentation is
available on the world wide web at {project-website}. A snapshot of
this documentation is available in HTML format in `/usr/share/doc/ntp`.
David L. Mills, _Network Time Protocol (Version 4)_, RFC5905
David L. Mills, _Network Time Protocol (Version 4)_, RFC 5905
== BUGS ==
......
......@@ -61,7 +61,7 @@ extern int listen_to_virtual_ips;
#ifndef IPTOS_DSCP_EF
#define IPTOS_DSCP_EF 0xb8
#endif
int qos = IPTOS_DSCP_EF; /* QoS RFC3246 */
int qos = IPTOS_DSCP_EF; /* QoS RFC 3246 */
#ifdef ENABLE_LEAP_SMEAR
/* TODO burnicki: This should be moved to ntp_timer.c, but if we do so
......
......@@ -2,7 +2,7 @@
* generic reference clock driver for several DCF/GPS/MSF/... receivers
*
* PPS notes:
* On systems that support PPSAPI (RFC2783) PPSAPI is the
* On systems that support PPSAPI (RFC 2783) PPSAPI is the
* preferred interface.
*
* Copyright (c) 1989-2015 by Frank Kardel <kardel@ntp.org>
......
......@@ -35,7 +35,7 @@
* port. These methods are architecture dependent.
*
* This driver requires the Pulse-per-Second API for Unix-like Operating
* Systems, Version 1.0, RFC-2783 (PPSAPI). Implementations are
* Systems, Version 1.0, RFC 2783 (PPSAPI). Implementations are
* available for FreeBSD, Linux, SunOS, Solaris and Tru64. However, at
* present only the Tru64 implementation provides the full generality of
* the API with multiple PPS drivers and multiple handles per driver. If
......
......@@ -1690,7 +1690,7 @@ ntpviz</a>, part of the <a href="https://www.ntpsec.org/">NTPsec project</a>
for sta in stat:
index_buffer += str( sta.table )
csvs.append(sta.csv)
# RFC4180 specifies the mime-type of a csv
# RFC 4180 specifies the mime-type of a csv
# your webserver should be programmed the same
index_buffer += """\
</table>
......
......@@ -127,7 +127,7 @@ If you assume that both clocks are accurate which is reasonable if you have
GPS at both ends, then you can easily solve for the transit times in each
direction.
The RFC5905 diagram is slightly out of date in that the digest header assumes
The RFC 5905 diagram is slightly out of date in that the digest header assumes
a 128-bit (16-octet) MD5 hash, but it is also possible for the field to be a
160-bit (20-octet) SHA-1 hash.
......@@ -1460,7 +1460,7 @@ class Authenticator:
@staticmethod
def have_mac(packet):
"Does this packet have a MAC?"
# According to RFC5909 7.5 the MAC is always present when an extension
# According to RFC 5909 7.5 the MAC is always present when an extension
# field is present. Note: this crude test will fail on Mode 6 packets.
# On those you have to go in and look at the count.
return len(packet) > ntp.ntp_magic.LEN_PKT_NOMAC
......
......@@ -21,7 +21,7 @@ def stdversion():
ntp.version.VCS_BASENAME, ntp.version.VCS_DATE)
def rfc3339(t):
"RFC3339 string from Unix time, including fractional second."
"RFC 3339 string from Unix time, including fractional second."
subsec = t - int(t)
t -= subsec
rep = time.strftime("%Y-%m-%dT%H:%M:%S", time.gmtime(t))
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment