]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
[5549a] Doc changes after review
authorTomek Mrugalski <tomasz@isc.org>
Tue, 12 Jun 2018 14:54:30 +0000 (16:54 +0200)
committerTomek Mrugalski <tomasz@isc.org>
Tue, 12 Jun 2018 14:54:30 +0000 (16:54 +0200)
doc/guide/classify.xml
doc/guide/dhcp4-srv.xml
doc/guide/dhcp6-srv.xml

index e61229deb629eb12826e0df1ff3d56169f7ecbc3..7ce2cbe94f1354ea2e62ce29179af094892d29e4 100644 (file)
       <listitem><para>
       Host reservations are looked for. If an identifier from the
       incoming packet matches a host reservation in the subnet or
-      shared network, the packet is associated with either the KNOWN
-      or the UNKNOWN builtin classes and all classes of the host
-      reservation.
+      shared network, the packet is associated with the KNOWN class
+      and all classes of the host reservation. If a reservation is not
+      found, the packet is assigned to UNKNOWN class.
       </para></listitem>
       <listitem><para>
       Classes with matching expressions using directly or indirectly
       request") evaluation are processed in the order they are defined
       in the configuration: the boolean expression is evaluated and
       when it returns true ("match") the incoming packet is associated
-      to the class.
+      to the class. The determination whether there is a reservation
+      for a given client is made after a subnet is selected. As such, it
+      is not possible to use KNOWN/UNKNOWN classes to select a shared
+      network or a subnet.
       </para></listitem>
       <listitem><para>
       If needed, addresses and prefixes from pools are assigned,
index c680e95861f65bf085753fc3b80ce93d65f4c6c9..5b48a92a204b114e2091eadfee4e6c8feef1e577 100644 (file)
@@ -2239,12 +2239,15 @@ It is merely echoed by the server
       </para>
 
       <para>
-      In a similar way a pool can be constrained to serve only known clients,
-      i.e. clients which have a reservation, using the build-n "KNOWN" or
-      "UNKNOWN" classes.
-      One can assign addresses to registered clients without giving a
-      different address per reservations, for instance when there is
-      not enough available addresses.
+      In a similar way a pool can be constrained to serve only known
+      clients, i.e. clients which have a reservation, using the
+      build-n "KNOWN" or "UNKNOWN" classes.  One can assign addresses
+      to registered clients without giving a different address per
+      reservations, for instance when there is not enough available
+      addresses. The determination whether there is a reservation
+      for a given client is made after a subnet is selected. As such, it
+      is not possible to use KNOWN/UNKNOWN classes to select a shared
+      network or a subnet.
       </para>
 
       <para>
index 731d48dd6ce3f64bfca988256e4ae282315c0764..9279e76e336d4c50d958a44457dd0e1c2b8dcec6 100644 (file)
@@ -2237,12 +2237,15 @@ should include options from the isc option space:
       </para>
 
       <para>
-      In a similar way a pool can be constrained to serve only known clients,
-      i.e. clients which have a reservation, using the build-n "KNOWN" or
-      "UNKNOWN" classes.
-      One can assign addresses to registered clients without giving a
-      different address per reservations, for instance when there is
-      not enough available addresses.
+      In a similar way a pool can be constrained to serve only known
+      clients, i.e. clients which have a reservation, using the
+      build-n "KNOWN" or "UNKNOWN" classes.  One can assign addresses
+      to registered clients without giving a different address per
+      reservations, for instance when there is not enough available
+      addresses. The determination whether there is a reservation
+      for a given client is made after a subnet is selected. As such, it
+      is not possible to use KNOWN/UNKNOWN classes to select a shared
+      network or a subnet.
       </para>
 
       <para>