[#2804] Text edits

4 files changed, 70 insertions, 71 deletions

diff --git a/doc/examples/template-ha-mt-tls/info.md b/doc/examples/template-ha-mt-tls/info.md
index d87f70c7c3..f52f250875 100644
--- a/doc/examples/template-ha-mt-tls/info.md
+++ b/doc/examples/template-ha-mt-tls/info.md
@@ -1,16 +1,16 @@
-Template: Secure High Availability Kea DHCP with multi-threading
+Template: Secure High Availability Kea DHCP with Multi-Threading
 ----------------------------------------------------------------
 
 Below are some templates to assist in configuring a secure Kea DHCP server with
 multi-threading. These templates make the following assumptions:
 
-- the administrator wants to set up High Availability with multi-threading.
-- the machines running Kea with multi-threading have at least 4 CPUs.
-- the connection to the peer is secured using TLS.
+- The administrator wants to set up High Availability (HA) with multi-threading.
+- The machines running Kea with multi-threading have at least four CPUs.
+- The connection to the peer is secured using TLS.
 
 The logical setup consists of two hosts, each running a Kea DHCPv4 server and a Control Agent (CA).
-In the multi-threading setup, the CA is not required, as the server is using it's
-own dedicated HTTP listener to communicate with the peer. However it can still
+In the multi-threading setup, the CA is not required, as the server is using its
+own dedicated HTTP listener to communicate with the peer. However, the CA can still
 be used to handle user commands.
 
 .. code-block:: none
@@ -25,21 +25,20 @@ be used to handle user commands.
    |        |       |        |
    +--------+       +--------+
 
-The CA on host-1 and CA on host-2 both listen on port 8001, and the server dedicated HTTP
+The CAs on host-1 and host-2 both listen on port 8001, and the server's dedicated HTTP
 listener uses port 8000. The DHCP servers communicate with each other via the dedicated HTTP
-listener, which forward only the lease updates commands to the peer server.
+listener, which forwards only the lease-update commands to the peer server.
 
 Deployment Considerations
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The setup is not expected to scale automatically. This example uses 4 threads for
-processing DHCP traffic, 4 threads for listening and handling HA peer HTTP requests
-and 4 threads for sending lease updates to the HA peer. The thread queue used to
-store incoming DHCP requests is set to 64, but specific values for better
-performance must be determined on the deployment setup by doing proper testing
-and benchmarks.
+The setup is not expected to scale automatically. This example uses four threads for
+processing DHCP traffic, four threads for listening and handling HA peer HTTP requests,
+and four threads for sending lease updates to the HA peer. The thread queue used to
+store incoming DHCP requests is set to 64, but proper testing and benchmarks are required
+to determine the appropriate values for best performance on the deployment setup.
 
-The assumption is that there are two hosts that are running the Kea setup:
+In this example, there are two hosts running Kea:
 
 - 192.168.1.2 - primary HA server (active, handles all the traffic)
 
@@ -54,16 +53,16 @@ The whole subnet is split into dynamic pools:
 
 To deploy this setup, follow the steps provided in the power user home setup with the following distinctions:
 
-1. Install CA only if the administrator is planning to manage Kea using RESTful API.
-   Otherwise, the High Availability Kea server with multi-threading does not require CA to run.
+1. Install the CA only if the administrator is planning to manage Kea using the RESTful API.
+   Otherwise, the CA is not required for the High Availability Kea server with multi-threading.
 
 2. Alter the following to match the local setup:
 
-   - the paths to ``trust-anchor``, ``cert-file``, ``key-file`` must be set to the
+   - The paths to ``trust-anchor``, ``cert-file``, and ``key-file`` must be set to the
      respective values corresponding to the deployment machine.
 
-   - the addressing, if using something other than 192.168.1.0/24. Make sure the CA port
-     configuration (``http-host`` and ``http-port`` in ``kea-ca.conf``) is different than the DHCPv4 server
+   - The addressing must be updated, if using something other than 192.168.1.0/24. Make sure the CA port
+     configuration (``http-host`` and ``http-port`` in ``kea-ca.conf``) is different from the DHCPv4 server
      configuration (``url`` in ``hook-libraries/parameters/high-availability/peers`` in ``kea-dhcp4.conf``).
      The CA is used to handle only management commands, as the HA module sends lease updates using
      the dedicated HTTP listener to the peer.
@@ -80,8 +79,9 @@ To deploy this setup, follow the steps provided in the power user home setup wit
 Possible Extensions
 ~~~~~~~~~~~~~~~~~~~
 
-The proposed configuration is somewhat basic, but functional. Once it is set up and running, administrators
+This sample configuration is basic but functional. Once it is set up and running, administrators
 may wish to consider the following changes:
 
-- if using a database, configuring TLS for the database backend (either for lease, host, configuration backend or forensic logging)
-  is also possible. See :ref:`database-connectivity` for more information.
+- If using a database, it is also possible to configure TLS for the database backend (for
+  lease, host, configuration backend, or forensic logging). See :ref:`database-connectivity`
+  for more information.
diff --git a/doc/sphinx/arm/agent.rst b/doc/sphinx/arm/agent.rst
index 86c6df681e..2440ca28a0 100644
--- a/doc/sphinx/arm/agent.rst
+++ b/doc/sphinx/arm/agent.rst
@@ -102,11 +102,11 @@ provided above, the RESTful service will be available at the URL
 ``https://10.20.30.40:8000/``. If these parameters are not specified, the
 default URL is ``http://127.0.0.1:8000/``.
 
-When using Kea's HA hook library with multi-threading, make sure
-that the address:port combination used for CA is
+When using Kea's HA hook library with multi-threading,
+the address:port combination used for CA must be
 different from the HA peer URLs, which are strictly
 for internal HA traffic between the peers. User commands should
-still be sent via CA.
+still be sent via the CA.
 
 The ``trust-anchor``, ``cert-file``, ``key-file``, and ``cert-required``
 parameters specify the TLS setup for HTTP, i.e. HTTPS. If these parameters
@@ -147,7 +147,7 @@ ability to store comments or descriptions; the parser translates a
 "comment" entry into a user context with the entry, which allows a
 comment to be attached within the configuration itself.
 
-Basic HTTP authentication was added in Kea 1.9.0; it protects
+Basic HTTP authentication protects
 against unauthorized uses of the control agent by local users. For
 protection against remote attackers, HTTPS and reverse proxy of
 :ref:`agent-secure-connection` provide stronger security.
@@ -173,27 +173,26 @@ is used.
    in UTF-8, but the current Kea JSON syntax only supports the Latin-1
    (i.e. 0x00..0xff) Unicode subset.
 
-To avoid to expose the password or both the user ID and the associated
-password these values can be read from files. The syntax was extended by:
+To avoid exposing the user ID and/or the associated
+password, these values can be read from files. The syntax is extended by:
 
--  The ``directory`` authentication parameter which handles the common
-   part of file paths. By default the value is the empty string.
+-  The ``directory`` authentication parameter, which handles the common
+   part of file paths. The default value is the empty string.
 
--  The ``password-file`` client parameter which with the ``directory``
-   parameter specifies the path of a file where the password or when no
-   user ID is given the whole basic HTTP authentication secret before
-   encoding can be read.
+-  The ``password-file`` client parameter, which, alongside the ``directory``
+   parameter, specifies the path of a file that can contain the password,
+   or when no user ID is given, the whole basic HTTP authentication secret.
 
--  The ``user-file`` client parameter which with the ``directory`` parameter
+-  The ``user-file`` client parameter, which, with the ``directory`` parameter,
    specifies the path of a file where the user ID can be read.
 
-When files are used they are read when the configuration is loaded in order
+When files are used, they are read when the configuration is loaded,
 to detect configuration errors as soon as possible.
 
 Hook libraries can be loaded by the Control Agent in the same way as
 they are loaded by the DHCPv4 and DHCPv6 servers. The CA currently
 supports one hook point - ``control_command_receive`` - which makes it
-possible to delegate processing of some commands to the hook library.
+possible to delegate the processing of some commands to the hook library.
 The ``hooks-libraries`` list contains the list of hook libraries that
 should be loaded by the CA, along with their configuration information
 specified with ``parameters``.
diff --git a/doc/sphinx/arm/classify.rst b/doc/sphinx/arm/classify.rst
index aaa2e52770..5a3a36c572 100644
--- a/doc/sphinx/arm/classify.rst
+++ b/doc/sphinx/arm/classify.rst
@@ -38,24 +38,24 @@ Client classification can be used to change the behavior of almost any
 part of the DHCP message processing. There are currently nine
 mechanisms that take advantage of client classification:
 
-- dropping queries
+- Dropping queries.
 
-- subnet selection
+- Subnet selection.
 
-- pool selection
+- Pool selection.
 
-- lease limiting
+- Lease limiting.
 
-- rate limiting
+- Rate limiting.
 
-- DDNS tuning
+- DDNS tuning.
 
-- definition of DHCPv4 private (codes 224-254) and code 43 options
+- Defining DHCPv4 private (codes 224-254) and code 43 options.
 
-- assignment of different options
+- Assigning different options.
 
-- for DHCPv4 cable modems, the setting of specific options for use with the TFTP
-  server address and the boot file field
+- Setting specific options for use with the TFTP server address
+  and the boot file field for DHCPv4 cable modems.
 
 .. _classify-classification-steps:
 
@@ -88,9 +88,9 @@ The classification process is conducted in several steps:
     The ``pkt4_receive`` and ``pkt6_receive`` callouts are called here.
 
 6.  When the ``early-global-reservations-lookup`` global parameter is
-    configured to ``true`` global reservations are looked for and the 8, 9
-    and 10 steps are partially performed: the lookup is limited to
-    global reservations, if one is found the ``KNOWN`` class is set
+    configured to ``true``, the process looks global reservations and
+    partially performs steps 8, 9, and 10. The lookup is limited to
+    global reservations; if one is found the ``KNOWN`` class is set,
     but if none is found the ``UNKNOWN`` class is **not** set.
 
 7.  A subnet is chosen, possibly based on the class information when
@@ -694,40 +694,40 @@ Configuring Classes
 ===================
 
 A client class definition can contain the following properties:
- - ``name`` parameter is mandatory and must be unique among all classes.
- - ``test`` expression is not mandatory and represents a string containing the
+ - The ``name`` parameter is mandatory and must be unique among all classes.
+ - The ``test`` expression is not mandatory and represents a string containing the
    logical expression used to determine membership in the class. The entire
    expression is included in double quotes (``"``). The result should evaluate
    to a boolean value (``true`` or ``false``).
- - ``template-test`` expression is not mandatory and represents a string
+ - The ``template-test`` expression is not mandatory and represents a string
    containing the logical expression used to generate a spawning class. The
    entire expression is included in double quotes (``"``). The result should
    evaluate to a string value representing the variable part of the spawned
    class name. If the resulting string is empty, no spawning class is generated.
    The resulting spawned class has the following generated name format:
    ``SPAWN_<template-class-name>_<evaluated-value>``.
-   After classes are evaluated and spawned class is generated, the corresponding
+   After classes are evaluated and a spawned class is generated, the corresponding
    template class name is also associated with the packet.
- - ``option-data`` list is not mandatory and contains options that should be
+ - The ``option-data`` list is not mandatory and contains options that should be
    assigned to members of this class. In the case of a template class, these
-   options are assigned to the generated spawning class.
- - ``option-def`` list is not mandatory and is used to define custom options.
- - ``only-if-required`` flag is not mandatory and when the value is set to
-   ``false`` (the default) membership is determined during classification so is
-   available for instance for subnet selection. When the value is set to
+   options are assigned to the generated spawned class.
+ - The ``option-def`` list is not mandatory and is used to define custom options.
+ - The ``only-if-required`` flag is not mandatory; when its value is set to
+   ``false`` (the default), membership is determined during classification and is
+   available for subnet selection, for instance. When the value is set to
    ``true``, membership is evaluated only when required and is usable only for
    option configuration.
- - ``user-context`` is not mandatory and represents a map with user defined data
-   and possibly configuration options for hooks libraries.
- - ``next-server`` is not mandatory and configures the ``siaddr`` field in
+ - The ``user-context`` is not mandatory and represents a map with user-defined data
+   and possibly configuration options for hook libraries.
+ - The ``next-server`` parameter is not mandatory and configures the ``siaddr`` field in
    packets associated with this class. It is used in DHCPv4 only.
- - ``server-hostname`` is not mandatory and configures the ``sname`` field in
-   packets associated with this class. It is used in DHCPv4 only
- - ``boot-file-name`` is not mandatory and configures the ``file`` field in
+ - The ``server-hostname`` is not mandatory and configures the ``sname`` field in
    packets associated with this class. It is used in DHCPv4 only.
- - ``valid-lifetime``, ``min-valid-lifetime``, and ``max-valid-lifetime`` are
+ - The ``boot-file-name`` is not mandatory and configures the ``file`` field in
+   packets associated with this class. It is used in DHCPv4 only.
+ - The ``valid-lifetime``, ``min-valid-lifetime``, and ``max-valid-lifetime`` are
    not mandatory and configure the valid lifetime fields for this client class.
- - ``preferred-lifetime``, ``min-preferred-lifetime`` and
+ - The ``preferred-lifetime``, ``min-preferred-lifetime`` and
    ``max-preferred-lifetime`` are not mandatory and configure the preferred
    lifetime fields for this client class. It is used in DHCPv6 only.
 
diff --git a/doc/sphinx/arm/ctrl-channel.rst b/doc/sphinx/arm/ctrl-channel.rst
index a4c0ae4990..1500b0b1d9 100644
--- a/doc/sphinx/arm/ctrl-channel.rst
+++ b/doc/sphinx/arm/ctrl-channel.rst
@@ -254,7 +254,7 @@ contain responses from each service, in the order they were requested:
     ]
 
 An exception to this are authentication or authorization errors which cause CA
-to reject the command entirely.  The response to such an error will be formatted
+to reject the command entirely.  The response to such an error is formatted
 as a single entry (JSON map) as follows:
 
 ::
@@ -342,7 +342,7 @@ returned is roughly equal to the configuration that was loaded using the
 ``-c`` command-line option during server start-up, or was later set using the
 ``config-set`` command. However, there may be certain differences, as
 comments are not retained. If the original configuration used file
-inclusion, the returned configuration will include all parameters from
+inclusion, the returned configuration includes all parameters from
 all included files.
 
 .. warning::