[3484] Further corrections to spelling and grammar in the documentation

src/bin/dhcp4/dhcp4.dox

@@ -105,11 +105,11 @@ access to these parameters must be as efficient as possible. In fact,
 currently the code has to only call @c Subnet4::getT1(), regardless if the
 "renew-timer" has been specified as a global or subnet specific value.
 
-Debugging configuration parser may be confusing. Therefore there is a special
+Debugging a configuration parser may be confusing. Therefore there is a special
 class called DebugParser. It does not configure anything, but just
 accepts any parameter of any type. If requested to commit configuration, it will
 print out received parameter name and its value. This class is not currently used,
-but it is convenient to have it every time a new parameter is added to DHCP
+but it is convenient to have it every time a new parameter is added to the DHCP
 configuration. For that purpose it should be left in the code.
 
 @section dhcpv4OptionsParse Custom functions to parse message options
@@ -169,8 +169,8 @@ or 2 NameChangeRequests during single message processing. Server generates no
 NameChangeRequests if it is not configured to update DNS or it rejects the DNS
 update for any other reason.
 
-The server may generate one NameChangeRequest in the case when client acquires a new
-lease or it releases an existing lease. In the former case, the NameChangeRequest
+The server may generate one NameChangeRequest in the case where a client acquires a new
+lease or it releases an existing one. In the former case, the NameChangeRequest
 type is CHG_ADD, which indicates that the kea-dhcp-ddns module should add a new
 DNS binding for the client, and it is assumed that there is no DNS binding for
 this client already. In the latter case, the NameChangeRequest type is CHG_REMOVE

src/bin/dhcp4/dhcp4_hooks.dox

@@ -55,24 +55,24 @@ packet processing. Hook points that are not specific to packet processing
    - name: @b query4, type: isc::dhcp::Pkt4Ptr, direction: <b>in/out</b>
 
  - @b Description: this callout is executed when the server has received a
-   buffer containing a DHCPv4 message, but the message hasn't been parsed
-   yet. The sole argument "query4" contains a pointer to the isc::dhcp::Pkt4
+   buffer containing a DHCPv4 message, but the message hasn't yet been parsed.
+   The sole argument "query4" contains a pointer to the isc::dhcp::Pkt4
    object, which contains the source and destination address of the
-   received packet, interface over which the packet has been received, and
+   received packet, the interface over which the packet has been received, and
    a raw buffer, stored in the data_ field, containing the DHCPv4 message
    in the wire format. None of the packet fields (op_, hlen_, chaddr_, etc.)
    are set yet. Callouts installed on this hook point can modify the data
     in the received buffer. The server will parse the buffer afterwards.
 
  - <b>Skip flag action</b>: If any callout sets the skip flag, the server will
-   skip the buffer parsing. In such case there is an expectation that
-   the callout will parse options carried in the buffer, create
+   skip the buffer parsing. In this case there is an expectation that
+   the callout will parse the options carried in the buffer, create
    @c isc::dhcp::Option objects (or derived) and add them to the "query4"
    object using the @c isc::dhcp::Pkt4::addOption.
    Otherwise the server will find out that some mandatory options are
    missing (e.g. DHCP Message Type) and will drop the message. If you
    want to have the capability to drop a message, it is better to use
-   skip flag in "pkt4_receive" callout.
+   the skip flag in the "pkt4_receive" callout.
 
  @subsection dhcpv4HooksPkt4Receive pkt4_receive
 

src/bin/dhcp6/dhcp6.dox

@@ -52,7 +52,7 @@ src/bin/dhcp6/json_config_parser.cc.
 @section dhcpv6ConfigInherit DHCPv6 Configuration Inheritance
 
 One notable useful feature of DHCP configuration is its parameter inheritance.
-For example, "renew-timer" value may be specified at a global scope and it then
+For example, the "renew-timer" value may be specified at a global scope and it then
 applies to all subnets. However, some subnets may have it overwritten with subnet
 specific values that takes precedence over global values that are considered
 defaults. The parameters inheritance is implemented by means of the "global
@@ -64,7 +64,7 @@ parsers being invoked to parse the global values. Parsers will store the
 parsed values into these storages. Once the global parameters are stored in the
 global context, the parsers for the nested configuration parameters are invoked.
 These parsers check the presence of the parameters overriding the values of
-the global parameters. If a value is not present, the values from the global
+the global parameters. If a value is not present, the value from the global
 context is used.
 
 A good example of inheritance is the implementation of the @ref
@@ -96,7 +96,7 @@ SubnetConfigParser::getParam(const std::string& name) {
 @endcode
 
 Note that if the value is neither present in the local storage nor in the global
-context an error is signalled.
+context, an error is signalled.
 
 Parameter inheritance is done once, during the reconfiguration phase.
 Reconfigurations are rare, so extra logic here is not a problem. On the other
@@ -105,9 +105,9 @@ access to these parameters must be as efficient as possible. In fact,
 currently the code has to only call @c Subnet6::getT1(), regardless if the
 "renew-timer" has been specified as a global or subnet specific value.
 
-Debugging configuration parser may be confusing. Therefore there is a special
+Debugging a configuration parser may be confusing. Therefore there is a special
 class called DebugParser. It does not configure anything, but just
-accepts any parameter of any type. If requested to commit configuration, it will
+accepts any parameter of any type. If requested to commit a configuration, it will
 print out received parameter name and its value. This class is not currently used,
 but it is convenient to have it every time a new parameter is added to DHCP
 configuration. For that purpose it should be left in the code.

src/lib/dhcp/libdhcp++.dox

@@ -28,8 +28,8 @@ add any server-specific code to libdhcp++ and use \ref libdhcpsrv instead.
 
 The following classes for packet manipulation are implemented:
 
-- isc::dhcp::Pkt4 - represents DHCPv4 packet.
-- isc::dhcp::Pkt6 - represents DHCPv6 packet.
+- isc::dhcp::Pkt4 - represents a DHCPv4 packet.
+- isc::dhcp::Pkt6 - represents a DHCPv6 packet.
 
 The following pointer types are defined: \c Pkt4Ptr and \c Pkt6Ptr. They are
 smart pointers using the \c boost::shared_ptr type. There are no const
@@ -50,9 +50,9 @@ specific formats:
 - isc::dhcp::Option6AddrLst -- DHCPv6 option, contains one or more IPv6 addresses;
 - isc::dhcp::Option4ClientFqdn -- DHCPv4 Client FQDN option;
 - isc::dhcp::Option6ClientFqdn -- DHCPv6 Client FQDN option;
-- isc::dhcp::Option6IAAddr -- DHCPv6 option, represents the IAADDR option (an option that
+- isc::dhcp::Option6IAAddr -- DHCPv6 option, represents an IAADDR option (an option that
                               contains IPv6 address with extra parameters);
-- isc::dhcp::Option6IAPrefix -- DHCPv6 option, represents the IAPREFIX option (an option
+- isc::dhcp::Option6IAPrefix -- DHCPv6 option, represents an IAPREFIX option (an option
                                 that contains IPv6 prefix in prefix delegation);
 - isc::dhcp::Option6IA -- DHCPv6 option used to store IA_NA and its suboptions.
 - isc::dhcp::Option6StatusCode -- DHCPv6 option, carries a status code to the client;