[#1917] Final updates

13 files changed, 51 insertions, 51 deletions

diff --git a/doc/sphinx/arm/classify.rst b/doc/sphinx/arm/classify.rst
index a07db5d08e..8691cf4f95 100644
--- a/doc/sphinx/arm/classify.rst
+++ b/doc/sphinx/arm/classify.rst
@@ -90,7 +90,7 @@ The classification process is conducted in several steps:
 9.  When the incoming packet belongs to the special class, `DROP`, it is
     dropped and an informational message is logged with the packet
     information. Since Kea version 1.9.8 it is allowed to make DROP
-    class dependent of KNOWN/UNKNOWN classes.
+    class dependent on KNOWN/UNKNOWN classes.
 
 10. If needed, addresses and prefixes from pools are assigned, possibly
     based on the class information when some pools are reserved for
@@ -382,7 +382,7 @@ Notes:
    relay from which to extract the information, with a value of 0
    indicating the relay closest to the DHCPv6 server. Negative values
    allow specifying relays counted from the DHCPv6 client, -1 indicating
-   the relay closest to the client. In general, negative "nest" level is
+   the relay closest to the client. In general, a negative "nest" level is
    the same as the number of relays + "nest" level. If the requested
    encapsulation doesn't exist, an empty string "" is returned. This
    expression is allowed in DHCPv6 only.
diff --git a/doc/sphinx/arm/ctrl-channel.rst b/doc/sphinx/arm/ctrl-channel.rst
index 4f9f74187a..60099fc2cd 100644
--- a/doc/sphinx/arm/ctrl-channel.rst
+++ b/doc/sphinx/arm/ctrl-channel.rst
@@ -656,8 +656,8 @@ The ``status-get`` command returns server's runtime information:
  - packet-queue-statistics: average queue size for last 10, 100 and 1000
    packets. Statistics using an approach similar to the Unix ``top`` command.
    The averaged queue size for the last 10 packets can be considered an
-   instantaneous value, while average for the last 1000 packets shows
-   longer term trend.
+   instantaneous value, while the average for the last 1000 packets shows
+   a longer term trend.
 
 The ``high-availability`` information is returned only when the command is
 sent to the DHCP servers being in the HA setup. This parameter is
diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index 7cc9ecafaf..47fcbd6888 100644
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -1347,7 +1347,7 @@ subnets.
    }
 
 
-Note that only one of name or code is required; there is no need to
+Note that either name or code is required; there is no need to
 specify both. Space has a default value of "dhcp4", so this can be skipped
 as well if a regular (not encapsulated) DHCPv4 option is defined.
 Finally, csv-format defaults to true, so it too can be skipped, unless
@@ -7038,7 +7038,7 @@ Kea DHCPv4 Compatibility Configuration Parameters
 By default, Kea aims to follow the RFC documents to promote better standards
 compliance. However, there are buggy implementations out there that cannot be
 easily fixed or upgraded. Therefore Kea provides an easy to use compatibility
-mode for broken or non-compliant clients. In that purpose, flags have to be
+mode for broken or non-compliant clients. For that purpose, flags have to be
 enabled in order to enable uncommon practices:
 
 .. code-block:: json
diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst
index e0d4dafa4a..a640f06c02 100644
--- a/doc/sphinx/arm/dhcp6-srv.rst
+++ b/doc/sphinx/arm/dhcp6-srv.rst
@@ -4617,7 +4617,7 @@ in the database for the lease for which the new reservation is being added.
 Similar to DHCPv4 (see :ref:`multiple-reservations-same-ip4`), the DHCPv6
 server can also be configured to allow creating multiple reservations
 for the same IPv6 address and/or delegated prefix in a given subnet. This
-is supported beginning with Kea 1.9.1 release as optional mode of operation
+is supported beginning with Kea release 1.9.1 as an optional mode of operation
 enabled with the ``ip-reservations-unique`` global parameter.
 
 The ``ip-reservations-unique`` is a boolean parameter, which defaults to
@@ -4739,7 +4739,7 @@ or prefix) from any of the pools defined within the subnets belonging to
 the shared network. Internally, the server selects one of the subnets
 belonging to a shared network and tries to allocate a lease from this
 subnet. If the server is unable to allocate a lease from the selected
-subnet (e.g., due to pools exhaustion), it will use another subnet from
+subnet (e.g., due to pool exhaustion), it will use another subnet from
 the same shared network and will try to allocate a lease from this subnet,
 etc. Therefore, the server will typically allocate all leases
 available in a given subnet before it starts allocating leases from
@@ -4902,7 +4902,7 @@ However, care should be taken for each subnet to have the same value.
     We view this largely as a site configuration issue.  A shared-network
     generally means the same physical link, so services configured by options
     from subnet A should be as easily reachable from subnet B and vice versa.
-    There are number of ways to avoid this situation:
+    There are a number of ways to avoid this situation:
 
     - Use the same values for options and parameters for subnets within the shared-network.
     - Use subnet selectors or client class guards that ensure that for a single client's query, the same subnet will be used for all IA options in that query.
diff --git a/doc/sphinx/arm/hammer.rst b/doc/sphinx/arm/hammer.rst
index 77e1ab755d..6f1ff58231 100644
--- a/doc/sphinx/arm/hammer.rst
+++ b/doc/sphinx/arm/hammer.rst
@@ -28,7 +28,7 @@ help:
 It will list available parameters.
 
 Hammer is able to set up various operating systems running either in LXC
-or in VirtualBox. To list of supported systems, use the
+or in VirtualBox. For a list of supported systems, use the
 ``supported-systems`` command:
 
 .. code-block:: console
diff --git a/doc/sphinx/arm/hooks-cb-cmds.rst b/doc/sphinx/arm/hooks-cb-cmds.rst
index f5f865c817..d6f2f21dfd 100644
--- a/doc/sphinx/arm/hooks-cb-cmds.rst
+++ b/doc/sphinx/arm/hooks-cb-cmds.rst
@@ -773,7 +773,7 @@ network name and the metadata. In order to fetch the detailed information about
 the selected shared network, use the `remote-network[46]-get` command.
 
 The example response above contains three shared networks. One of the
-shared networks is associated will all servers, so it is included in
+shared networks is associated with all servers, so it is included in
 the list of shared networks to be used by "server1" and "server2".
 The remaining two shared networks are returned because one of them
 is associated with the "server1" and another one is associated with
@@ -1242,7 +1242,7 @@ shared network, no option is deleted. In particular, the given
 option may be present for a subnet belonging to the shared network.
 Such an option instance is not affected by this command as this
 command merely deletes the shared network level option. In order to
-delete subnet level option the `remote-option[46]-subnet-del`
+delete a subnet level option the `remote-option[46]-subnet-del`
 command must be used instead.
 
 The following command attempts to delete an option having the
@@ -1286,7 +1286,7 @@ an existing option in the database. The structure of the option information
 is the same as in the Kea configuration file (see :ref:`dhcp4-std-options`
 and :ref:`dhcp6-std-options`). The option information is carried in the
 `options` list. Another list, `shared-networks`, contains a map with the
-name of the shared network for which the option is to be set. If such option
+name of the shared network for which the option is to be set. If such an option
 already exists for the shared network, it is replaced with the new instance.
 
 ::
@@ -1329,9 +1329,9 @@ and option space and these two parameters are passed within the
 prefix delegation pool prefix and length identifying the pool. If the
 option is not explicitly specified for this pool, no option is deleted.
 In particular, the given option may exist for a subnet containing
-the specified pool. Such option instance is not affected by this
+the specified pool. Such an option instance is not affected by this
 command as this command merely deletes a prefix delegation pool level
-option. In order to delete subnet level option the
+option. In order to delete a subnet level option the
 `remote-option6-subnet-del` command must be used instead.
 
 ::
@@ -1468,8 +1468,8 @@ an existing option in the database. The structure of the option information
 is the same as in the Kea configuration file (see :ref:`dhcp4-std-options`
 and :ref:`dhcp6-std-options`). The option information is carried in the
 `options` list. Another list, `pools`, contains a map with the IP address
-range or prefix identifying the pool. If such option already exists for the
-pool, it is replaced with the new instance.
+range or prefix identifying the pool. If such an option already exists for
+the pool, it is replaced with the new instance.
 
 For example:
 
@@ -1557,7 +1557,7 @@ option in the database. The structure of the option information is the same as
 in the Kea configuration file (see :ref:`dhcp4-std-options`
 and :ref:`dhcp6-std-options`). The option information is carried in the
 `options` list. Another list, `subnets`, contains a map with the identifier of
-the subnet for which the option is to be set. If such option already exists
+the subnet for which the option is to be set. If such an option already exists
 for the subnet, it is replaced with the new instance.
 
 ::
diff --git a/doc/sphinx/arm/hooks-ha.rst b/doc/sphinx/arm/hooks-ha.rst
index af1a2da342..a36485b7a6 100644
--- a/doc/sphinx/arm/hooks-ha.rst
+++ b/doc/sphinx/arm/hooks-ha.rst
@@ -111,11 +111,11 @@ of DHCP responses, because not only do active servers send lease updates
 to each other, but also to the backup servers. As of Kea 1.7.8 the active
 servers no longer expect the acknowledgments from the backup servers
 before responding to the DHCP clients, therefore the overhead of sending
-the lease updates to the backup servers is minimized comparing to the
+the lease updates to the backup servers is minimized compared to the
 earlier Kea versions.
 
 The last supported configuration, passive-backup, has been introduced
-in Kea 1.7.8 release. In this configuration there is only one active
+in Kea release 1.7.8. In this configuration there is only one active
 server and typically one or more backup servers. A passive-backup
 configuration with no backup servers is also accepted but it is no
 different than running a single server with no HA function at all.
@@ -131,7 +131,7 @@ servers should have accurate or nearly accurate information about the
 allocated leases. The major advantage of the passive-backup mode is that
 it provides some redundancy of the lease information but with better
 performance of the primary server responding to the DHCP queries. Since
-Kea 1.7.8 release, the primary server does not have to wait for the
+Kea release 1.7.8, the primary server does not have to wait for the
 acknowledgments to the lease updates from the backup servers before it
 sends a response to the DHCP client. This reduces the response time
 comparing to the load-balancing and hot-standby cases in which the
@@ -324,7 +324,7 @@ The following is the list of all possible server states:
    default, the primary server does not wait for the acknowledgments from
    the backup servers and responds to the DHCP query right after sending
    the lease updates to all backup servers. If any of the lease updates
-   fails, a backup server misses such lease update but the DHCP client
+   fail, a backup server misses the lease update but the DHCP client
    is still provisioned. This default configuration can be changed by
    setting the ``wait-backup-ack`` configuration parameter to ``true``,
    in which case the primary server always waits for the acknowledgements
@@ -523,7 +523,7 @@ with the only difference that ``this-server-name`` should be set to
    A server will only use the pool fragments owned by the partner when
    the partner is not running. See the notes in the
    :ref:`ha-supported-configurations` highlighting differences between
-   the ``load-balancing`` and ``hot-standby`` modes. The semantics of the pools
+   the ``load-balancing`` and ``hot-standby`` modes. The semantics of the pool
    partitioning is explained further in this section.
    The :ref:`ha-load-balancing-advanced-config` provides advanced pools
    partitioning examples.
@@ -647,7 +647,7 @@ behavior with respect to HA:
 -  ``delayed-updates-limit`` - specifies a maximum number of lease
    updates which can be queued while the server is in the
    ``communication-recovery`` state. This parameter was introduced in
-   Kea 1.9.4 release. The special value of 0 configures the server to
+   Kea release 1.9.4. The special value of 0 configures the server to
    never transition to the ``communication-recovery`` state and the
    server behaves as in earlier Kea versions. The default value of this
    parameter is 100.
@@ -720,7 +720,7 @@ state these problems are avoided.
 If a server in the ``communication-recovery`` state re-establishes
 communication with its partner, it will try to send the partner all
 of the outstanding lease updates the server has queued. This is done
-synchronously and may take considerable amount of time before the server
+synchronously and may take a considerable amount of time before the server
 transitions to the ``load-balancing`` state and resumes normal operation.
 The maximum number of lease updates which can be queued in the
 ``communication-recovery`` state is controlled by the ``delayed-updates-limit``.
@@ -989,7 +989,7 @@ In this mode, the non-primary active server is called ``standby`` and
 that is its role.
 
 Finally, because there is always one server responding to DHCP queries,
-there is only one scope - ``HA_server1`` - in use within pools
+there is only one scope - ``HA_server1`` - in use within pool
 definitions. In fact, the ``client-class`` parameter could be removed
 from this configuration without harm, because there can be no conflicts
 in lease allocations by different servers as they do not allocate leases
@@ -1598,24 +1598,24 @@ the maintenance is not supported for the backup server or the server being
 in the terminated state. Also, an error will be returned if the maintenance
 request was already sent to the other server.
 
-Upon receiving the ``ha-maintenance-start`` command, the server1 will
-send the ``ha-maintenance-notify`` command to the server2 to put this
-server in the ``in-maintenance`` state. If the server2 confirms, the server1
+Upon receiving the ``ha-maintenance-start`` command, server1 will
+send the ``ha-maintenance-notify`` command to server2 to put this
+server in the ``in-maintenance`` state. If server2 confirms, server1
 will transition to the ``partner-in-maintenance`` state. This is similar
 to the ``partner-down`` state, except that in the ``partner-in-maintenance``
-state the server1 continues to send lease updates to the server2 until
-the administrator shuts down the server2. The server1 now responds to all
+state server1 continues to send lease updates to server2 until
+the administrator shuts down server2. Server1 now responds to all
 DHCP queries.
 
-The administrator may safely shut down the server2 being in the
+The administrator may safely shut down server2 it being in the
 ``in-maintenance`` state and perform necessary maintenance actions. When
-the server2 is offline, the server1 will encounter communication issues
+server2 is offline, server1 will encounter communication issues
 with the partner and will immediately transition to the ``partner-down``
 state in which it will continue to respond to all DHCP queries but will
-no longer send lease updates to the server2. Starting the server2 after
+no longer send lease updates to server2. Starting server2 after
 the maintenance will trigger normal state negotiation, lease database
 synchronization and, ultimately, a transition to the load-balancing or
-hot-standby state. The maintenance can now be performed for the server1.
+hot-standby state. The maintenance can now be performed on server1.
 It should be initiated by sending the ``ha-maintenance-start`` to the
 server2.
 
@@ -1670,7 +1670,7 @@ trigger lease-database synchronization on demand. It may also be useful
 to manually set the HA scopes that are being served.
 
 Note that the backup server can sometimes be used to handle DHCP traffic
-if both active servers are down. The backup server does not perform
+if both active servers are down. The backup server does not perform the
 failover function automatically; thus, in order to use the backup server
 to respond to DHCP queries, the server administrator must enable this
 function manually.
@@ -2080,7 +2080,7 @@ This command causes the server to reset its High Availability state machine
 by transitioning it to the waiting state. A partner in the
 ``communication-recovery`` state may send this command to cause the server
 to synchronize its lease database. The database synchronization is required
-when the partner failed to send all lease database updates after
+when the partner has failed to send all lease database updates after
 re-establishing connection after a temporary connection failure. It is also
 required when the ``delayed-updates-limit`` is exceeded when the server is
 in the ``communication-recovery`` state.
diff --git a/doc/sphinx/arm/hooks-lease-cmds.rst b/doc/sphinx/arm/hooks-lease-cmds.rst
index a6002acd31..edfb4bacca 100644
--- a/doc/sphinx/arm/hooks-lease-cmds.rst
+++ b/doc/sphinx/arm/hooks-lease-cmds.rst
@@ -230,7 +230,7 @@ The commands can take several additional optional parameters:
 
 -  ``state`` - specify the state of added lease, can be 0 for ``default``,
    1 for ``declined`` and 2 for ``expired-reclaimed`` state. Any other
-   value will cause error. Note that using 1 for a "IA_PD" lease type is
+   value will cause an error. Note that using 1 for a "IA_PD" lease type is
    illegal and will be rejected.
 
 -  ``user-context`` - specifies the user context to be associated with
@@ -341,7 +341,7 @@ or update two other leases in the database:
        }
    }
 
-If any of the leases is malformed, no leases changes are applied
+If any of the leases are malformed, no lease changes are applied
 to the lease database. If the leases are well-formed but there is a
 failure to apply any of the lease changes to the database, the command
 continues to be processed for other leases. All the leases for which
diff --git a/doc/sphinx/arm/hooks.rst b/doc/sphinx/arm/hooks.rst
index 53afdec27a..28247124c2 100644
--- a/doc/sphinx/arm/hooks.rst
+++ b/doc/sphinx/arm/hooks.rst
@@ -1722,7 +1722,7 @@ true.
 The option to which an action applies may be specified by either its
 numeric code or its name.. At least the code or the name must be
 specified. The option space is the DHCPv4 or DHCPv6 spaces depending
-of the server where the hook library is loaded. Other spaces as vendor
+on the server where the hook library is loaded. Other spaces as vendor
 spaces could be supported in a further version.
 
 The library is available since Kea 1.7.1 and can be loaded in a
@@ -1860,7 +1860,7 @@ the reservation belongs. This is done via the ``subnet-id`` parameter.
 For global reservations, use a value of zero (0). For reservations
 scoped to a specific subnet, use that subnet's ID.
 
-At the opposite when the subnet id is not specified in the command
+On the other hand when the subnet id is not specified in the command
 parameters it is added to each host in responses. If the subnet id
 has the unused special value this means the host entry belongs only
 to the other IP version (i.e. IPv6 in DHCPv4 server or IPv4 in DHCPv6
@@ -3116,11 +3116,11 @@ An example response could look as follows:
                # It is replaced by the "reservations-global"
                # "reservations-in-subnet" and "reservations-out-of-pool"
                # parameters.
-               # Specify if server should lookup global reservations.
+               # Specify if the server should lookup global reservations.
                "reservations-global": false,
-               # Specify if server should lookup in-subnet reservations.
+               # Specify if the server should lookup in-subnet reservations.
                "reservations-in-subnet": true,
-               # Specify if server can assume that all reserved addresses
+               # Specify if the server can assume that all reserved addresses
                # are out-of-pool.
                "reservations-out-of-pool": false,
                "subnet4": [
diff --git a/doc/sphinx/arm/keactrl.rst b/doc/sphinx/arm/keactrl.rst
index c1075d20df..bf1796e7cc 100644
--- a/doc/sphinx/arm/keactrl.rst
+++ b/doc/sphinx/arm/keactrl.rst
@@ -346,7 +346,7 @@ service etc.
 As such, it is recommended to use ``systemctl`` commands if they are available. Native
 Kea packages do not provide keactrl and instead ``systemctl`` service definitions are
 provided instead. Consult documentation of your system for details. Briefly, here
-are example commands to checks status, start, stop and restart various Kea daemons:
+are example commands to check status, start, stop and restart various Kea daemons:
 
 .. code-block:: console
 
diff --git a/doc/sphinx/arm/logging.rst b/doc/sphinx/arm/logging.rst
index 3bdb0279f4..7131b7e208 100644
--- a/doc/sphinx/arm/logging.rst
+++ b/doc/sphinx/arm/logging.rst
@@ -555,7 +555,7 @@ output), ``stderr`` (messages are printed on stderr), ``syslog``
 (messages are logged to syslog using a specified name). Any other value is
 interpreted as a filename to which messages should be written.
 
-The flush (true of false) Option
+The flush (true or false) Option
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 Flush buffers after each log message. Doing this will reduce performance
diff --git a/doc/sphinx/arm/security.rst b/doc/sphinx/arm/security.rst
index 84d311063c..054d625f40 100644
--- a/doc/sphinx/arm/security.rst
+++ b/doc/sphinx/arm/security.rst
@@ -106,7 +106,7 @@ The TLS configuration parameters are:
   being configured.
 
 - the ``key-file`` string parameter specifies the private key of the
-  end-entity certificate of Kea instance being configured.
+  end-entity certificate of the Kea instance being configured.
   The file must not be encrypted and it is highly recommended to
   restrict its access.
 
@@ -350,7 +350,7 @@ processes that are used to ensure adequate code quality:
   packets per seconds, CPU usage, memory utilization and others).
 - Kea uses CI (Continuous Integration). This means that the great majority of tests (all unit and system
   tests, and in some cases also performance tests) are run for every commit. Many lighter tests are
-  ran on branches, before the code is even accepted.
+  run on branches, before the code is even accepted.
 - Negative testing. Many unit and system tests check for negative scenarios, such as incomplete,
   broken, truncated packets, API commands, configuration files, incorrect sequences (such as sending
   packets in invalid order) and more.
diff --git a/doc/sphinx/arm/stats.rst b/doc/sphinx/arm/stats.rst
index 73735884a9..16695a113e 100644
--- a/doc/sphinx/arm/stats.rst
+++ b/doc/sphinx/arm/stats.rst
@@ -310,7 +310,7 @@ The statistic-sample-age-set-all Command
 --------------------------------------------
 
 The ``statistic-sample-age-set-all`` command sets time based limits
-for collecting samples for all statistics. It takes single-integer parameter
+for collecting samples for all statistics. It takes a single-integer parameter
 called ``duration``, which specifies the time limit for statistic
 in seconds. An example command may look like this:
 
@@ -396,12 +396,12 @@ points, perhaps to do some form of statistical analysis afterwards.
 
 Since Kea 1.6, by default, each statistic holds 20 data points. Setting such
 a limit prevents unlimited memory growth.
-There are two ways to define the limts: time based (e.g. keep samples from
+There are two ways to define the limits: time based (e.g. keep samples from
 the last 5 minutes) and size based. It's possible to change the size based
 limit by using one of two commands: ``statistic-sample-count-set``,
 to set size limit for single statistic and ``statistic-sample-count-set-all``
 for setting size based limits for all statistics. To set time based
-limit for single statistic use ``statistic-sample-age-set``, and
+limits for single statistic use ``statistic-sample-age-set``, and
 ``statistic-sample-age-set-all`` to set time based limits for all statistics.
 For a given statistic only one type of limit can be active. It means that storage
 is limited only by time based limit or size based, never by both of them.