[#2073] Text edits (interim save through line 4582)

diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index 8f6b22ea1cfabbfaf433eef35daf493cbd97ac50..afc862aaa271c45b718cc9427201b3d1efa86ecb 100644 (file)
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -4361,13 +4361,13 @@ Reserving a Hostname
 --------------------
 
 When the reservation for a client includes the ``hostname``, the server
-will return this hostname to the client in the Client FQDN or Hostname
+returns this hostname to the client in the Client FQDN or Hostname
 option. The server responds with the Client FQDN option only if the
 client has included the Client FQDN option in its message to the server. The
-server will respond with the Hostname option if the client included
+server responds with the Hostname option if the client included
 the Hostname option in its message to the server, or if the client
 requested the Hostname option using the Parameter Request List option.
-The server will return the Hostname option even if it is not configured
+The server returns the Hostname option even if it is not configured
 to perform DNS updates. The reserved hostname always takes precedence
 over the hostname supplied by the client or the autogenerated (from the
 IPv4 address) hostname.
@@ -4395,7 +4395,7 @@ configuration:
            }
        }
 
-will result in assigning the "alice-laptop.example.isc.org." hostname to
+will result in assigning the `"alice-laptop.example.isc.org."` hostname to
 the client using the MAC address "aa:bb:cc:dd:ee:ff". If the
 ``ddns-qualifying-suffix`` is not specified, the default (empty) value will
 be used, and in this case the value specified as a ``hostname`` will be
@@ -4436,7 +4436,7 @@ options follow the same rules as any other options. These can be
 standard options (see :ref:`dhcp4-std-options`),
 custom options (see :ref:`dhcp4-custom-options`),
 or vendor-specific options (see :ref:`dhcp4-vendor-opts`). The following
-example demonstrates how standard options can be defined.
+example demonstrates how standard options can be defined:
 
 ::
 
@@ -4483,19 +4483,19 @@ Vendor-specific options can be reserved in a similar manner:
        } ]
    }
 
-Options defined at host level have the highest priority. In other words,
-if there are options defined with the same type on global, subnet,
-class, and host levels, the host-specific values will be used.
+Options defined at the host level have the highest priority. In other words,
+if there are options defined with the same type on the global, subnet,
+class, and host levels, the host-specific values are used.
 
 .. _reservation4-message-fields:
 
 Reserving Next Server, Server Hostname, and Boot File Name
 ----------------------------------------------------------
 
-BOOTP/DHCPv4 messages include "siaddr", "sname", and "file" fields. Even
+BOOTP/DHCPv4 messages include `"siaddr"`, `"sname"`, and `"file"` fields. Even
 though DHCPv4 includes corresponding options, such as option 66 and
 option 67, some clients may not support these options. For this reason,
-server administrators often use the "siaddr", "sname", and "file" fields
+server administrators often use the `"siaddr"`, `"sname"`, and `"file"` fields
 instead.
 
 With Kea, it is possible to make static reservations for these DHCPv4
@@ -4527,11 +4527,11 @@ Reserving Client Classes in DHCPv4
 
 :ref:`classification-using-expressions` explains how to configure
 the server to assign classes to a client, based on the content of the
-options that this client sends to the server. Host reservations
+options that this client sends to the server. Host reservation
 mechanisms also allow for the static assignment of classes to clients.
 The definitions of these classes are placed in the Kea configuration or
 a database. The following configuration snippet shows how to specify that
-a client belongs to classes ``reserved-class1`` and ``reserved-class2``. Those
+a client belongs to the classes ``reserved-class1`` and ``reserved-class2``. Those
 classes are associated with specific options sent to the clients which belong
 to them.
 
@@ -4574,11 +4574,11 @@ to them.
 
 In some cases the host reservations can be used in conjunction with client
 classes specified within the Kea configuration. In particular, when a
-host reservation exists for a client within a given subnet, the "KNOWN"
+host reservation exists for a client within a given subnet, the `"KNOWN"`
 built-in class is assigned to the client. Conversely, when there is no
-static assignment for the client, the "UNKNOWN" class is assigned to the
+static assignment for the client, the `"UNKNOWN"` class is assigned to the
 client. Class expressions within the Kea configuration file can
-refer to "KNOWN" or "UNKNOWN" classes using the "member" operator.
+refer to `"KNOWN"` or `"UNKNOWN"` classes using the `"member"` operator.
 For example:
 
 ::