[3565] Updated the wording in the kea user guide for reservation-mode param.

diff --git a/doc/guide/dhcp4-srv.xml b/doc/guide/dhcp4-srv.xml
index 859b9742bc76fab26e33a656d28718f2e954283b..188eb169ab994fe16c2a739a4e5c304e3fb88b86 100644 (file)
--- a/doc/guide/dhcp4-srv.xml
+++ b/doc/guide/dhcp4-srv.xml
@@ -1891,24 +1891,28 @@ temporarily override a list of interface names and listen on all interfaces.
       <title>Fine Tuning IPv4 Host Reservation</title>
 
       <note>
-        <para><command>reservation-mode</command> in DHCPv6 server in 0.9.1 beta is
-        accepted, but not used. Full implementation will be available in the upcoming
-        releases.</para>
+        <para><command>reservation-mode</command> configuration parameter in DHCPv4
+        server is accepted, but not used in the Kea 0.9.1 beta. Full implementation
+        will be available in the upcoming releases.</para>
       </note>
 
       <para>Host reservation capability introduces additional restrictions for the
       allocation engine during lease selection and renewal. In particular, three
       major checks are necessary. First, when selecting a new lease, it is not
-      sufficient for a candidate lease to be not used by anyone else. It also must
-      not be reserved for anyone else. Second, when renewing a lease, additional
-      check must be performed whether the address being renewed is not reserved
-      for anyone else. Finally, when a host renews an address, the server has to
-      check whether there's a reservation for this host, so the exisiting (dynamically
-      allocated) address should be revoked and the reserved one be used instead.
-      </para>
-      <para>Some of those checks in certain deployments may be not necessary. Skipping
-      them may improve performance. The Kea server allows configuration of the
-      reservation types allowed for each subnet using <command>reservation-mode</command>.
+      sufficient for a candidate lease to be not used by another DHCP client. It
+      also must not be reserved for another client. Second, when renewing a lease,
+      additional check must be performed whether the address being renewed is not
+      reserved for another client. Finally, when a host renews an address, the server
+      has to check whether there's a reservation for this host, so the exisiting
+      (dynamically allocated) address should be revoked and the reserved one be
+      used instead.
+      </para>
+      <para>Some of those checks may be unnecessary in certain deployments. Not
+      performing them may improve performance. The Kea server provides the
+      <command>reservation-mode</command> configuration parameter to select the
+      types of reservations allowed for the particular subnet. Each reservation
+      type has different constraints for the checks to be performed by the
+      server when allocating or renewing a lease for the client.
       Allowed values are:
 
       <itemizedlist>

diff --git a/doc/guide/dhcp6-srv.xml b/doc/guide/dhcp6-srv.xml
index 6f609ece9690e2e530238f88e72510ed5a7f9f1a..b7578e000cf41f2c30284d4268b6628cc1f875e3 100644 (file)
--- a/doc/guide/dhcp6-srv.xml
+++ b/doc/guide/dhcp6-srv.xml
@@ -1898,23 +1898,27 @@ should include options from the isc option space:
       <title>Fine Tuning IPv6 Host Reservation</title>
 
       <note>
-        <para><command>reservation-mode</command> in the DHCPv6 server in 0.9.1 beta is
-        implemented, but was not tested and is considered experimental.</para>
+        <para><command>reservation-mode</command> in the DHCPv6 server is
+        implemented in Kea 0.9.1 beta, but has not been tested and is
+        considered experimental.</para>
       </note>
 
       <para>Host reservation capability introduces additional restrictions for the
       allocation engine during lease selection and renewal. In particular, three
       major checks are necessary. First, when selecting a new lease, it is not
-      sufficient for a candidate lease to be not used by anyone else. It also must
-      not be reserved for anyone else. Second, when renewing a lease, additional
-      check must be performed whether the address being renewed is not reserved
-      for anyone else. Finally, when a host renews an address, the server has to
-      check whether there's a reservation for this host, so the exisiting (dynamically
-      allocated) address should be revoked and the reserved one be used instead.
-      </para>
-      <para>Some of those checks in certain deployments may be not necessary. Skipping
-      them may improve performance. The Kea server allows configuration of the
-      reservation types allowed for each subnet using <command>reservation-mode</command>.
+      sufficient for a candidate lease to be not used by another DHCP client. It
+      also must not be reserved for another client. Second, when renewing a lease,
+      additional check must be performed whether the address being renewed is not
+      reserved for another client. Finally, when a host renews an address or a
+      prefix, the server has to check whether there's a reservation for this host,
+      so the existing (dynamically allocated) address should be revoked and the
+      reserved one be used instead.</para>
+      <para>Some of those checks may be unnecessary in certain deployments. Not
+      performing them may improve performance. The Kea server provides the
+      <command>reservation-mode</command> configuration parameter to select the
+      types of reservations allowed for the particular subnet. Each reservation
+      type has different constraints for the checks to be performed by the
+      server when allocating or renewing a lease for the client.
       Allowed values are:
 
       <itemizedlist>