]> git.ipfire.org Git - thirdparty/kea.git/commitdiff
[1371] Edit from review
authorVicky Risk <vicky@isc.org>
Thu, 20 Aug 2020 20:00:00 +0000 (20:00 +0000)
committerVicky Risk <vicky@isc.org>
Thu, 20 Aug 2020 20:21:47 +0000 (20:21 +0000)
doc/sphinx/umls.rst

index a2abdb033b997a5869cc6871d7e936595ec01d9a..e9d7ddad12b1ba90561f29ec39724a97ad2b2f33 100644 (file)
@@ -13,7 +13,7 @@
 Kea Flow Diagrams
 =================
 
-These UML activity diagrams describe the Kea DHCPv4 server implementation. They may be useful for system administrators to understand for several reasons. In order to design a configuration that will result in clients getting the intended addresses and options it is important to understand the sequence of request processing steps. For example, Kea will iterate looking for a suitable address, and will conditionally accept the first available address, so the order in which addresses are evaluated matters.
+These flow diagrams describe the Kea DHCPv4 server implementation. They may be useful for system administrators to understand for several reasons. In order to design a configuration that will result in clients getting the intended addresses and options it is important to understand the sequence of request processing steps. For example, Kea will iterate looking for a suitable address, and will conditionally accept the first available address, so the order in which addresses are evaluated matters.
 
 It is also useful to understand Kea's processing logic because there are configuration choices which can make the process far more efficient. Kea is very flexible so that it can be applied to very different use cases and in different environments.  In an environment where throughput and efficiency are a priority, the administrator can choose to limit some of the processing steps. For example, it is possible to limit the number of different client identifiers Kea evaluates in looking for a host reservation, or even to skip the whole step of checking for host reservations.