diff -up ntp-4.2.2p1/html/ntpdc.html.htmldocfmt ntp-4.2.2p1/html/ntpdc.html
--- ntp-4.2.2p1/html/ntpdc.html.htmldocfmt	2006-06-06 22:16:06.000000000 +0200
+++ ntp-4.2.2p1/html/ntpdc.html	2008-01-17 18:22:31.000000000 +0100
@@ -21,7 +21,7 @@
 		<h4>Synopsis</h4>
 		<tt>ntpdc [ -ilnps ] [ -c <i>command</i> ] [ <i>host</i> ] [ ... ]</tt>
 		<h4>Description</h4>
-		<tt>ntpdc</tt> is used to query the <tt>ntpd</tt> daemon about its current state and to request changes in that state. The program may be run either in interactive mode or controlled using command line arguments. Extensive state and statistics information is available through the <tt>ntpdc</tt> interface. In addition, nearly all the configuration options which can be specified at startup using ntpd's configuration file may also be specified at run time using <tt>ntpdc</tt>.
+		<p><tt>ntpdc</tt> is used to query the <tt>ntpd</tt> daemon about its current state and to request changes in that state. The program may be run either in interactive mode or controlled using command line arguments. Extensive state and statistics information is available through the <tt>ntpdc</tt> interface. In addition, nearly all the configuration options which can be specified at startup using ntpd's configuration file may also be specified at run time using <tt>ntpdc</tt>.</p>
 		<p>If one or more request options are included on the command line when <tt>ntpdc</tt> is executed, each of the requests will be sent to the NTP servers running on each of the hosts given as command line arguments, or on localhost by default. If no request options are given, <tt>ntpdc</tt> will attempt to read commands from the standard input and execute these on the NTP server running on the first host given on the command line, again defaulting to localhost when no other host is specified. <tt>ntpdc</tt> will prompt for commands if the standard input is a terminal device.</p>
 		<p><tt>ntpdc</tt> uses NTP mode 7 packets to communicate with the NTP server, and hence can be used to query any compatible server on the network which permits it. Note that since NTP is a UDP protocol this communication will be somewhat unreliable, especially over large distances in terms of network topology. <tt>ntpdc</tt> makes no attempt to retransmit requests, and will time requests out if the remote host is not heard from within a suitable timeout time.</p>
 		<p>The operation of <tt>ntpdc</tt> are specific to the particular implementation of the <tt>ntpd</tt> daemon and can be expected to work only with this and maybe some previous versions of the daemon. Requests from a remote <tt>ntpdc</tt> program which affect the state of the local server must be authenticated, which requires both the remote program and local server share a common key and key identifier.</p>
@@ -130,11 +130,11 @@
 		<dt><tt>addpeer <i>peer_address</i> [
 		<i>keyid</i> ] [ <i>version</i> ] [
 		<tt>minpoll# | prefer | iburst  | burst | minpoll
-		<i>N</i> | <tt>maxpoll</tt> <i>N</i> [...] ]</tt>
+		<i>N</i> | <tt>maxpoll</tt> <i>N</i> [...]</tt> ]</tt>
 		<dt><tt>addpeer <i>peer_address</i> [
 		<tt>prefer | iburst | burst | minpoll
 		<i>N</i> | <tt>maxpoll</tt> <i>N</i> | <tt>keyid</tt>
-			<i>N</i> | <tt>version</tt> <i>N</i> [...] ]</tt>
+			<i>N</i> | <tt>version</tt> <i>N</i> [...] </tt> ]</tt>
 			<dd>Add a configured peer association at the
 			given address and operating in symmetric
 			active mode. Note that an existing association
@@ -162,11 +162,11 @@
 			<dt><tt>addserver <i>peer_address</i> [
 		<i>keyid</i> ] [ <i>version</i> ] [
 		<tt>minpoll# | prefer | iburst  | burst | minpoll
-		<i>N</i> | <tt>maxpoll</tt> <i>N</i> [...] ]</tt>
+		<i>N</i> | <tt>maxpoll</tt> <i>N</i> [...] </tt>]</tt>
 		<dt><tt>addserver <i>peer_address</i> [
 		<tt>prefer | iburst | burst | minpoll
 		<i>N</i> | <tt>maxpoll</tt> <i>N</i> | <tt>keyid</tt>
-			<i>N</i> | <tt>version</tt> <i>N</i> [...] ]</tt>
+			<i>N</i> | <tt>version</tt> <i>N</i> [...]</tt> ]</tt>
 
 			<dd>Identical to the addpeer command, except that the operating mode is client.
 			<dt><tt>broadcast <i>peer_address</i> [
@@ -196,9 +196,9 @@
 			<dd>Returns information concerning the authentication module, including known keys and counts of encryptions and decryptions which have been done.
 			<dt><tt>traps</tt>
 			<dd>Display the traps set in the server. See the source listing for further information.
-			<dt><tt>addtrap [ <i>address</i> [ <i>port</i> ] [ <i>interface</i> ]</tt>
+			<dt><tt>addtrap [ <i>address</i> ] [ <i>port</i> ] [ <i>interface</i> ]</tt>
 			<dd>Set a trap for asynchronous messages. See the source listing for further information.
-			<dt><tt>clrtrap [ <i>address</i> [ <i>port</i> ] [ <i>interface</i>]</tt>
+			<dt><tt>clrtrap [ <i>address</i> ] [ <i>port</i> ] [ <i>interface</i>]</tt>
 			<dd>Clear a trap for asynchronous messages. See the source listing for further information.
 			<dt><tt>reset</tt>
 			<dd>Clear the statistics counters in various modules of the server. See the source listing for further information.
diff -up ntp-4.2.2p1/html/confopt.html.htmldocfmt ntp-4.2.2p1/html/confopt.html
--- ntp-4.2.2p1/html/confopt.html.htmldocfmt	2006-06-06 22:15:56.000000000 +0200
+++ ntp-4.2.2p1/html/confopt.html	2008-01-17 18:22:31.000000000 +0100
@@ -32,8 +32,8 @@
 		<p>There are three types of associations: persistent, preemptable and ephemeral. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>prempt</tt> flag and are demobilized by timeout or error. Ephemeral associations are mobilized upon arrival of designated messages and demobilized by timeout or error.</p>
 		<dl>
 			<dt><tt>server <i>address</i> [options ...]</tt><br>
-				<tt>peer <i>address</i> [</tt><tt>options ...]<br>
-					broadcast <i>address</i> [options ...]</tt><br>
+				<tt>peer <i>address</i> [options ...]</tt><br>
+					<tt>broadcast <i>address</i> [options ...]</tt><br>
 				<tt>manycastclient <i>address</i> [options ...]</tt>
 			<dd>These four commands specify the time server name or address to be used and the mode in which to operate. The <i>address</i> can be either a DNS name or a IP address in dotted-quad notation. Additional information on association behavior can be found in the <a href="assoc.html">Association Management</a> page.
 				<dl>
diff -up ntp-4.2.2p1/html/monopt.html.htmldocfmt ntp-4.2.2p1/html/monopt.html
--- ntp-4.2.2p1/html/monopt.html.htmldocfmt	2006-06-06 22:16:02.000000000 +0200
+++ ntp-4.2.2p1/html/monopt.html	2008-01-17 18:22:31.000000000 +0100
@@ -78,9 +78,7 @@
 						<dl>
 							<dt><i><tt>name</tt></i>
 							<dd>This is the type of the statistics records, as shown in the <tt>statistics</tt> command.
-						</dl>
-					<dd><tt>file <i>filename</i></tt>
-						<dl>
+					<dt><tt>file <i>filename</i></tt>
 							<dd>This is the file name for the statistics records. Filenames of set members are built from three concatenated elements <i><tt>prefix</tt></i>, <i><tt>filename</tt></i> and <i><tt>suffix</tt></i>:
 								<dl>
 									<dt><i><tt>prefix</tt></i>
@@ -90,9 +88,7 @@
 									<dt><i><tt>suffix</tt></i>
 									<dd>This part is reflects individual elements of a file set. It is generated according to the type of a file set.
 								</dl>
-						</dl>
-					<dd><tt>type <i>typename</i></tt>
-						<dl>
+					<dt><tt>type <i>typename</i></tt>
 							<dd>A file generation set is characterized by its type. The following types are supported:
 								<dl>
 									<dt><tt>none</tt>
@@ -110,13 +106,9 @@
 									<dt><tt>age</tt>
 									<dd>This type of file generation sets changes to a new element of the file set every 24 hours of server operation. The filename suffix consists of a dot, the letter <tt>a</tt>, and an 8-digit number. This number is taken to be the number of seconds the server is running at the start of the corresponding 24-hour period. Information is only written to a file generation by specifying <tt>enable</tt>; output is prevented by specifying <tt>disable</tt>.
 								</dl>
-						</dl>
-					<dd><tt>link | nolink</tt>
-						<dl>
+					<dt><tt>link | nolink</tt>
 							<dd>It is convenient to be able to access the current element of a file generation set by a fixed name. This feature is enabled by specifying <tt>link</tt> and disabled using <tt>nolink</tt>. If <tt>link</tt> is specified, a hard link from the current file set element to a file without suffix is created. When there is already a file with this name and the number of links of this file is one, it is renamed appending a dot, the letter <tt>C</tt>, and the pid of the <tt>ntpd</tt> server process. When the number of links is greater than one, the file is unlinked. This allows the current file to be accessed by a constant name.
-						</dl>
-					<dd><tt>enable | disable</tt>
-						<dl>
+					<dt><tt>enable | disable</tt>
 							<dd>Enables or disables the recording function.
 						</dl>
 				</dl>
diff -up ntp-4.2.2p1/html/ntpdate.html.htmldocfmt ntp-4.2.2p1/html/ntpdate.html
--- ntp-4.2.2p1/html/ntpdate.html.htmldocfmt	2008-01-17 18:22:31.000000000 +0100
+++ ntp-4.2.2p1/html/ntpdate.html	2008-01-17 18:22:31.000000000 +0100
@@ -20,7 +20,7 @@
 		<h4>Synopsis</h4>
 		<tt>ntpdate [ -bBdoqsuv ] [ -a <i>key</i> ] [ -e <i>authdelay</i> ] [ -k <i>keyfile</i> ] [ -o <i>version</i> ] [ -p <i>samples</i> ] [ -t <i>timeout</i> ] [ -U <i>user_name</i> ] <i>server</i> [ ... ]</tt>
 		<h4>Description</h4>
-		<tt>ntpdate</tt> sets the local date and time by polling the Network Time Protocol (NTP) server(s) given as the <i>server</i> arguments to determine the correct time. It must be run as root on the local host. A number of samples are obtained from each of the servers specified and a subset of the NTP clock filter and selection algorithms are applied to select the best of these. Note that the accuracy and reliability of <tt>ntpdate</tt> depends on the number of servers, the number of polls each time it is run and the interval between runs.
+		<p><tt>ntpdate</tt> sets the local date and time by polling the Network Time Protocol (NTP) server(s) given as the <i>server</i> arguments to determine the correct time. It must be run as root on the local host. A number of samples are obtained from each of the servers specified and a subset of the NTP clock filter and selection algorithms are applied to select the best of these. Note that the accuracy and reliability of <tt>ntpdate</tt> depends on the number of servers, the number of polls each time it is run and the interval between runs.</p>
 		<p><tt>ntpdate</tt> can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon <tt>ntpd</tt>. It is also possible to run <tt>ntpdate</tt> from a <tt>cron</tt> script. However, it is important to note that <tt>ntpdate</tt> with contrived <tt>cron</tt> scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since <tt>ntpdate</tt> does not discipline the host clock frequency as does <tt>ntpd</tt>, the accuracy using <tt>ntpdate</tt> is limited.</p>
 		<p>Time adjustments are made by <tt>ntpdate</tt> in one of two ways. If <tt>ntpdate</tt> determines the clock is in error more than 0.5 second it will simply step the time by calling the system <tt>settimeofday()</tt> routine. If the error is less than 0.5 seconds, it will slew the time by calling the system <tt>adjtime()</tt> routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when <tt>ntpdate</tt> is run by <tt>cron</tt> every hour or two.</p>
 		<p><tt>ntpdate</tt> will decline to set the date if an NTP server daemon (e.g., <tt>ntpd</tt>) is running on the same host. When running <tt>ntpdate</tt> on a regular basis from <tt>cron</tt> as an alternative to running a daemon, doing so once every hour or two will result in precise enough timekeeping to avoid stepping the clock.</p>