Browse Source

[trac3990] Typo changes

Some suggested changes to tidy up some of the text.
Shawn Routhier 9 years ago
parent
commit
8bee85a39e
2 changed files with 48 additions and 44 deletions
  1. 20 18
      doc/guide/dhcp4-srv.xml
  2. 28 26
      doc/guide/dhcp6-srv.xml

+ 20 - 18
doc/guide/dhcp4-srv.xml

@@ -2727,28 +2727,30 @@ It is merely echoed by the server
       <para>The DHCPv4 server is configured with a certain pool of addresses
       that it is expected to hand out to the DHCPv4 clients.  It is
       assumed that the server is authoritative and has complete jurisdiction
-      over those addresses. However, due to various reasons, like
-      misconfiguration or faulty client implemetation that retains its
-      address beyond valid lifetime, there may be devices connected that use
-      those addresses without the server's approval or knowledge. Such an
+      over those addresses. However, due to various reasons, such as
+      misconfiguration or a faulty client implemetation that retains its
+      address beyond the valid lifetime, there may be devices connected that use
+      those addresses without the server's approval or knowledge.</para>
+
+      <para>Such an
       unwelcome event can be detected by legitimate clients (using ARP or ICMP
-      Echo Request mechanisms) and reported to the DHCPv4 server using DHCPDECLINE
-      message. The server will sanity check it (if the client declining an
-      address really was supposed to use it), and then will conduct clean up
+      Echo Request mechanisms) and reported to the DHCPv4 server using a DHCPDECLINE
+      message. The server will do a sanity check (if the client declining an
+      address really was supposed to use it), and then will conduct a clean up
       operation. Any DNS entries related to that address will be removed, the
       fact will be logged and hooks will be triggered. After that is done, the
       address will be marked as declined (which indicates that it is used by an
-      unknown entity and thus not available for assignment to anyone) and
-      probation time on it will be set. Unless otherwise configured, the
+      unknown entity and thus not available for assignment to anyone) and a
+      probation time will be set on it. Unless otherwise configured, the
       probation period lasts 24 hours. After that period, the server will
-      recover the lease, i.e. put it back into available state. The address will
+      recover the lease, i.e. put it back into the available state. The address will
       be available for assignment again. It should be noted that if the
       underlying issue of a misconfigured device is not resolved, the duplicate
       address scenario will repeat. On the other hand, it provides an
       opportunity to recover from such an event automatically, without any
       sysadmin intervention.</para>
 
-      <para>To configure decline probation period to a value different
+      <para>To configure the decline probation period to a value different
       than the default, the following syntax can be used:
 <screen>
   "Dhcp4": {
@@ -2761,20 +2763,20 @@ It is merely echoed by the server
       the server to recycle declined leases after an hour.</para>
 
       <para>There are several statistics and hook points associated with the
-      Decline handling procedure. lease4_decline hook is triggered after the
-      incoming DHCPDECLINE message was sanitized and the server is about to
-      decline the lease. declined-addresses statistic is increased after the
+      Decline handling procedure. The lease4_decline hook is triggered after the
+      incoming DHCPDECLINE message has been sanitized and the server is about to
+      decline the lease. The declined-addresses statistic is increased after the
       hook returns (both global and subnet specific variants).</para>
 
       <para>Once the probation time elapses, the declined lease is recovered
-      using standard expired lease reclaimation procedure, with several
+      using the standard expired lease reclaimation procedure, with several
       additional steps. In particular, both declined-addresses statistics
-      (global and subnet specific) are being decreased. At the same time,
+      (global and subnet specific) are decreased. At the same time,
       reclaimed-declined-addresses statistics (again in two variants, global and
       subnet specific) are increased.</para>
-      
+
       <para>Note about statistics: The server does not decrease
-      assigned-addresses statistics when DHCPDECLINE is received and processed
+      assigned-addresses statistics when a DHCPDECLINE is received and processed
       successfully. While technically a declined address is no longer assigned,
       the primary usage of the assigned-addresses statistic is to monitor pool
       utilization. Most people would forget to include declined-addresses in the

+ 28 - 26
doc/guide/dhcp6-srv.xml

@@ -2689,30 +2689,32 @@ should include options from the isc option space:
       addresses that it is expected to hand out to the DHCPv6 clients.
       It is assumed that the server is authoritative and has complete
       jurisdiction over those addresses. However, due to various
-      reasons, like misconfiguration or faulty client implenetation
-      that retains its address beyond valid lifetime, there may be
+      reasons, such as misconfiguration or a faulty client implenetation
+      that retains its address beyond the valid lifetime, there may be
       devices connected that use those addresses without the server's
-      approval or knowledge. Such an unwelcome event can be detected
+      approval or knowledge.</para>
+
+      <para>Such an unwelcome event can be detected
       by legitimate clients (using Duplicate Address Detection) and
-      reported to the DHCPv6 server using DECLINE message. The server
-      will sanity check it (if the client declining an address really
-      was supposed to use it), then will conduct clean up operation
+      reported to the DHCPv6 server using a DECLINE message. The server
+      will do a sanity check (if the client declining an address really
+      was supposed to use it), then will a conduct clean up operation
       and confirm it by sending back a REPLY message. Any DNS entries
       related to that address will be removed, the fact will be logged
       and hooks will be triggered. After that is done, the address
       will be marked as declined (which indicates that it is used by
       an unknown entity and thus not available for assignment to
-      anyone) and probation time on it will be set. Unless otherwise
+      anyone) and a probation time will be set on it. Unless otherwise
       configured, the probation period lasts 24 hours. After that
       period, the server will recover the lease, i.e. put it back into
-      available state. The address will be available for assignment
+      the available state. The address will be available for assignment
       again. It should be noted that if the underlying issue of a
       misconfigured device is not resolved, the duplicate address
       scenario will repeat. On the other hand, it provides an
       opportunity to recover from such an event automatically, without
       any sysadmin intervention.</para>
 
-      <para>To configure decline probation period to a value different
+      <para>To configure the decline probation period to a value different
       than the default, the following syntax can be used:
 <screen>
   "Dhcp6": {
@@ -2725,20 +2727,20 @@ should include options from the isc option space:
       the server to recycle declined leases after an hour.</para>
 
       <para>There are several statistics and hook points associated with the
-      Decline handling procedure. lease6_decline hook is triggered after the
-      incoming Decline message was sanitized and the server is about to decline
-      the lease. declined-addresses statistic is increased after the hook
+      Decline handling procedure. The lease6_decline hook is triggered after the
+      incoming Decline message has been sanitized and the server is about to decline
+      the lease. The declined-addresses statistic is increased after the hook
       returns (both global and subnet specific variants).</para>
 
       <para>Once the probation time elapses, the declined lease is recovered
-      using standard expired lease reclaimation procedure, with several
+      using the standard expired lease reclaimation procedure, with several
       additional steps. In particular, both declined-addresses statistics
-      (global and subnet specific) are being decreased. At the same time,
+      (global and subnet specific) are decreased. At the same time,
       reclaimed-declined-addresses statistics (again in two variants, global and
       subnet specific) are increased.</para>
 
       <para>Note about statistics: The server does not decrease
-      assigned-addresses statistics when Decline message is received and
+      assigned-addresses statistics when a DECLINE message is received and
       processed successfully. While technically a declined address is no longer
       assigned, the primary usage of the assigned-addresses statistic is to
       monitor pool utilization. Most people would forget to include
@@ -3011,10 +3013,10 @@ should include options from the isc option space:
             <entry>
               This statistic shows the number of IPv6 adresses that are
               currently declined. This statistic counts the number of leases
-              being currently unavailable. Once the lease is recovered, this
-              statistic will be decreased. Ideally, this statistic should not
-              have non-zero values. If this statistic has non-zero or increasing
-              values, a network administrator should investigate if there is
+              currently unavailable. Once a lease is recovered, this
+              statistic will be decreased. Ideally, this statistic should be
+              zero. If this statistic is non-zero (or worse increasing),
+              a network administrator should investigate if there is
               a misbehaving device in his network. This is a global statistic
               that covers all subnets.
             </entry>
@@ -3026,10 +3028,10 @@ should include options from the isc option space:
             <entry>
               This statistic shows the number of IPv6 adresses that are
               currently declined in a given subnet. This statistic counts the
-              number of leases being currently unavailable. Once the lease is
+              number of leases currently unavailable. Once a lease is
               recovered, this statistic will be decreased. Ideally, this
-              statistic should not have non-zero values. If this statistic has
-              non-zero or increasing values, a network administrator should
+              statistic should be zero. If this statistic is
+              non-zero (or worse increasing), a network administrator should
               investigate if there is a misbehaving device in his network. The
               <emphasis>id</emphasis> is the subnet-id of a given subnet. This
               statistic is exposed for each subnet separately.
@@ -3041,10 +3043,10 @@ should include options from the isc option space:
             <entry>integer</entry>
             <entry>
               This statistic shows the number of IPv6 adresses that were
-              declined, but are now recovered. Contrary to the
+              declined, but are now recovered. Unlike
               declined-addresses, this statistic never decreases. It can be used
               as a long term indicator of how many actual valid Declines were
-              conducted and recovered from. This is a global statistic that
+              processed and recovered from. This is a global statistic that
               covers all subnets.
             </entry>
             </row>
@@ -3054,10 +3056,10 @@ should include options from the isc option space:
             <entry>integer</entry>
             <entry>
               This statistic shows the number of IPv6 adresses that were
-              declined, but are now recovered. Contrary to the
+              declined, but are now recovered. Unlike
               declined-addresses, this statistic never decreases. It can be used
               as a long term indicator of how many actual valid Declines were
-              conducted and eventually recovered from. The
+              processed and recovered from. The
               <emphasis>id</emphasis> is the subnet-id of a given subnet. This
               statistic is exposed for each subnet separately.
             </entry>