From: Shawn Routhier Date: Thu, 19 Nov 2015 06:44:05 +0000 (-0800) Subject: [trac3990] Typo changes X-Git-Tag: trac4204fd_base~10^2~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=8bee85a39e6e4bb1ff9acfc5211bbc6d7a7ce686;p=thirdparty%2Fkea.git [trac3990] Typo changes Some suggested changes to tidy up some of the text. --- diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml index 324cf2f85d..93950b8501 100644 --- a/doc/guide/dhcp4-srv.xml +++ b/doc/guide/dhcp4-srv.xml @@ -2727,28 +2727,30 @@ It is merely echoed by the server 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. + + 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. - To configure decline probation period to a value different + To configure the decline probation period to a value different than the default, the following syntax can be used: "Dhcp4": { @@ -2761,20 +2763,20 @@ It is merely echoed by the server the server to recycle declined leases after an hour. 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). 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. - + 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 diff --git a/doc/guide/dhcp6-srv.xml b/doc/guide/dhcp6-srv.xml index 1f62948580..668f7b85e8 100644 --- a/doc/guide/dhcp6-srv.xml +++ b/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. + + 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. - To configure decline probation period to a value different + To configure the decline probation period to a value different than the default, the following syntax can be used: "Dhcp6": { @@ -2725,20 +2727,20 @@ should include options from the isc option space: the server to recycle declined leases after an hour. 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). 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. 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: 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. @@ -3026,10 +3028,10 @@ should include options from the isc option space: 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 id 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: integer 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. @@ -3054,10 +3056,10 @@ should include options from the isc option space: integer 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 id is the subnet-id of a given subnet. This statistic is exposed for each subnet separately.