[5212] Wrapped lines made too long

doc/examples/kea4/advanced.json

@@ -66,12 +66,13 @@
     // when they get their own client-id. Kea can disable RFC6842 support.
     "echo-client-id": false,
 
-    // Some clients don't use stable client identifier, but rather generate them
-    // during each boot. This may cause a client that reboots frequently to get
-    // multiple leases, which may not be desirable. As such, sometimes admins
-    // prefer to tell their DHCPv4 server to ignore client-id value altogether
-    // and rely exclusively on MAC address. This is a parameter that is defined
-    // globally, but can be overridden on a subnet level.
+    // Some clients don't use stable client identifier, but rather
+    // generate them during each boot. This may cause a client that
+    // reboots frequently to get multiple leases, which may not be
+    // desirable. As such, sometimes admins prefer to tell their DHCPv4
+    // server to ignore client-id value altogether and rely exclusively
+    // on MAC address. This is a parameter that is defined globally, but
+    // can be overridden on a subnet level.
     "match-client-id": true,
 
     // The following list defines subnets. Each subnet consists of at
@@ -93,9 +94,10 @@
             "pools": [ { "pool": "192.0.4.1 - 192.0.4.254" } ],
             "subnet": "192.0.4.0/24",
 
-            // Sometimes the relay may use an IPv4 address that does not match
-            // the subnet. This is discouraged, but there are valid cases when it
-            // makes sense. One case is when there is a shared subnet.
+            // Sometimes the relay may use an IPv4 address that does
+            // not match the subnet. This is discouraged, but there are
+            // valid cases when it makes sense. One case is when there
+            // is a shared subnet.
             "relay": {
                 "ip-address": "192.168.1.1"
             }
@@ -103,8 +105,9 @@
     ]
 },
 
-  // The following configures logging. It assumes that messages with at least
-  // informational level (info, warn, error and fatal) should be logged to stdout.
+  // The following configures logging. It assumes that messages with
+  // at least informational level (info, warn, error and fatal) should
+  // be logged to stdout.
   "Logging": {
       "loggers": [
           {

doc/examples/kea4/backends.json

@@ -60,13 +60,14 @@
 //      "connect-timeout": 3
 //  },
 
-// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
-// sure it is up, running and properly initialized. See kea-admin documentation
-// for details on how to initialize the database. The only strictly required
-// parameters are type, keyspace and contact-points. At least one contact point
-// must be specified, but more than one is required for redundancy. Make sure
-// you specify the contact points without spaces. Kea must be compiled with
-// --with-cql option to use this backend.
+// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
+// database. Make sure it is up, running and properly initialized. See
+// kea-admin documentation for details on how to initialize the
+// database. The only strictly required parameters are type, keyspace
+// and contact-points. At least one contact point must be specified, but
+// more than one is required for redundancy. Make sure you specify the
+// contact points without spaces. Kea must be compiled with --with-cql
+// option to use this backend.
 //  "lease-database": {
 //      "type": "cql",
 //      "keyspace": "keatest",
@@ -95,8 +96,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/cassandra.json

@@ -10,13 +10,14 @@
     "interfaces": [ "ethX" ]
   },
 
-// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
-// sure it is up, running and properly initialized. See kea-admin documentation
-// for details on how to initialize the database. The only strictly required
-// parameters are type, keyspace and contact-points. At least one contact point
-// must be specified, but more than one is required for redundancy. Make sure
-// you specify the contact points without spaces. Kea must be compiled with
-// --with-cql option to use this backend.
+// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
+// database. Make sure it is up, running and properly initialized. See
+// kea-admin documentation for details on how to initialize the
+// database. The only strictly required parameters are type, keyspace
+// and contact-points. At least one contact point must be specified, but
+// more than one is required for redundancy. Make sure you specify the
+// contact points without spaces. Kea must be compiled with --with-cql
+// option to use this backend.
   "lease-database": {
       "type": "cql",
       "keyspace": "keatest",
@@ -45,8 +46,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/classify.json

@@ -95,8 +95,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/leases-expiration.json

@@ -19,14 +19,15 @@
       "lfc-interval": 3600
   },
 
-// The following parameters control processing expired leases. Expired leases
-// will be reclaimed periodically according to the "reclaim-timer-wait-time"
-// parameter. Reclaimed leases will be held in the database for 1800s to
-// facilitate lease affinity. After this period the leases will be removed.
-// The frequency of removal is controlled by the "flush-reclaimed-timer-wait-time"
-// parameter. The lease reclamation routine will process at most 500 leases
-// or will last for at most 100ms, during a single run. If there are still
-// some unreclaimed leases after 10 attempts, a warning message is issued.
+// The following parameters control processing expired leases. Expired
+// leases will be reclaimed periodically according to the
+// "reclaim-timer-wait-time" parameter. Reclaimed leases will be held in
+// the database for 1800s to facilitate lease affinity. After this
+// period the leases will be removed.  The frequency of removal is
+// controlled by the "flush-reclaimed-timer-wait-time" parameter. The
+// lease reclamation routine will process at most 500 leases or will
+// last for at most 100ms, during a single run. If there are still some
+// unreclaimed leases after 10 attempts, a warning message is issued.
   "expired-leases-processing": {
     "reclaim-timer-wait-time": 5,
     "hold-reclaimed-time": 1800,
@@ -50,8 +51,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/multiple-options.json

@@ -60,8 +60,10 @@
          },
             // Note the Kea provides some of the options on its own. In
             // particular:
-            // - IP address lease time (option 51) is governed by valid-lifetime
-            //   parameter, so you don't need to specify it as option.
+
+            // - IP address lease time (option 51) is governed by
+            //   valid-lifetime parameter, so you don't need to specify
+            //   it as option.
             // - Subnet mask (option 1) is calculated automatically from the
             //   subnet parameter specified for each "subnet4" entry.
             // - renewal-timer (option 58) is calculated from renew-timer
@@ -75,10 +77,12 @@
              "name": "routers",
              "data": "192.0.2.1"
          },
-            // Typically people prefer to refer to options by their names, so they
-            // don't need to remember the code names. However, some people like
-            // to use numerical values. For example, option "domain-name" uses
-            // option code 15, so you can reference to it either by
+
+            // Typically people prefer to refer to options by their
+            // names, so they don't need to remember the code names.
+            // However, some people like to use numerical values. For
+            // example, option "domain-name" uses option code 15, so you
+            // can reference to it either by
             // "name": "domain-name" or "code": 15.
          {
              "code": 15,
@@ -87,7 +91,9 @@
              // Domain search is also a popular option. It tells the client to
              // attempt to resolve names within those specificed domains. For
              // example, name "foo" would be attempted to be resolved as
-             // foo.mydomain.example.com and if it fails, then as foo.example.com
+             // foo.mydomain.example.com and if it fails, then as
+             // foo.example.com
+
          {
              "name": "domain-search",
              "data": "mydomain.example.com, example.com"
@@ -123,8 +129,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/mysql-reservations.json

@@ -31,18 +31,20 @@
 //  "rebind-timer": 2000,
 
 
-// Kea supports reservations by several different types of identifiers:
-// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
-// client), client-id (client identifier inserted by the client) and circuit-id
-// (circuit identifier inserted by the relay agent). When told to do so, Kea can
-// check for all of those identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports reservations by several different types of
+// identifiers: hw-address (hardware/MAC address of the client), duid
+// (DUID inserted by the client), client-id (client identifier inserted
+// by the client) and circuit-id (circuit identifier inserted by the
+// relay agent). When told to do so, Kea can check for all of those
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
 
 // The example below is not optimal from a performance perspective, but it
 // nicely showcases the host reservation capabilities. Please use the minimum
 // set of identifier types used in your network.
-  "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
+  "host-reservation-identifiers":
+    [ "circuit-id", "hw-address", "duid", "client-id" ],
 
 // Specify connection to the database holding host reservations. The type
 // specifies that the MySQL database is used. user and password are the
@@ -77,8 +79,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/pgsql-reservations.json

@@ -30,18 +30,20 @@
 //  "rebind-timer": 2000,
 
 
-// Kea supports reservations by several different types of identifiers:
-// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
-// client), client-id (client identifier inserted by the client) and circuit-id
-// (circuit identifier inserted by the relay agent). When told to do so, Kea can
-// check for all of those identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports reservations by several different types of
+// identifiers: hw-address (hardware/MAC address of the client), duid
+// (DUID inserted by the client), client-id (client identifier inserted
+// by the client) and circuit-id (circuit identifier inserted by the
+// relay agent). When told to do so, Kea can check for all of those
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
 
 // The example below is not optimal from a performance perspective, but it
 // nicely showcases the host reservation capabilities. Please use the minimum
 // set of identifier types used in your network.
-  "host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
+  "host-reservation-identifiers":
+    [ "circuit-id", "hw-address", "duid", "client-id" ],
 
 // Specify connection to the database holding host reservations. The type
 // specifies that the PostgreSQL database is used. user and password are the
@@ -75,8 +77,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/reservations.json

@@ -29,18 +29,20 @@
 //  "rebind-timer": 2000,
 
 
-// Kea supports reservations by several different types of identifiers:
-// hw-address (hardware/MAC address of the client), duid (DUID inserted by the
-// client), client-id (client identifier inserted by the client) and circuit-id
-// (circuit identifier inserted by the relay agent). When told to do so, Kea can
-// check for all of those identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports reservations by several different types of
+// identifiers: hw-address (hardware/MAC address of the client), duid
+// (DUID inserted by the client), client-id (client identifier inserted
+// by the client) and circuit-id (circuit identifier inserted by the
+// relay agent). When told to do so, Kea can check for all of those
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
 
 // The example below is not optimal from a performance perspective, but it
 // nicely showcases the host reservation capabilities. Please use the minimum
 // set of identifier types used in your network.
-"host-reservation-identifiers": [ "circuit-id", "hw-address", "duid", "client-id" ],
+"host-reservation-identifiers":
+  [ "circuit-id", "hw-address", "duid", "client-id" ],
 
 // Define a subnet with four reservations. Some of the reservations belong
 // to the dynamic pool. Kea is able to handle this case, but it is not
@@ -120,13 +122,15 @@
              "boot-file-name": "/dev/null"
          },
 
-// This reservation is using flexible identifier. Instead of relying on specific
-// field, sysadmin can define an expression similar to what is used for client
-// classification, e.g. substring(relay[0].option[17],0,6). Then, based on the
-// value of that expression for incoming packet, the reservation is matched.
+// This reservation is using flexible identifier. Instead of relying
+// on specific field, sysadmin can define an expression similar to what
+// is used for client classification,
+// e.g. substring(relay[0].option[17],0,6). Then, based on the value of
+// that expression for incoming packet, the reservation is matched.
 // Expression can be specified either as hex or plain text using single
 // quotes.
-// Note: flexible identifier requires flex_id hook library to be loaded to work.
+// Note: flexible identifier requires flex_id hook library to be
+// loaded to work.
          {
              "flex-id": "s0mEVaLue",
              "ip-address": "192.0.2.206"
@@ -137,8 +141,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/several-subnets.json

@@ -59,8 +59,9 @@
   } ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/single-subnet.json

@@ -40,8 +40,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea4/with-ddns.json

@@ -58,8 +58,9 @@
     }
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/advanced.json

@@ -108,8 +108,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/backends.json

@@ -60,13 +60,14 @@
 //      "connect-timeout": 3
 //  },
 
-// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra database. Make
-// sure it is up, running and properly initialized. See kea-admin documentation
-// for details on how to initialize the database. The only strictly required
-// parameters are type, keyspace and contact-points. At least one contact point
-// must be specified, but more than one is required for redundancy. Make sure
-// you specify the contact points without spaces. Kea must be compiled with
-// --with-cql option to use this backend.
+// 4. CQL (Cassandra) backend. Leases will be stored in Cassandra
+// database. Make sure it is up, running and properly initialized. See
+// kea-admin documentation for details on how to initialize the
+// database. The only strictly required parameters are type, keyspace
+// and contact-points. At least one contact point must be specified, but
+// more than one is required for redundancy. Make sure you specify the
+// contact points without spaces. Kea must be compiled with --with-cql
+// option to use this backend.
 //  "lease-database": {
 //      "type": "cql",
 //      "keyspace": "keatest",
@@ -96,8 +97,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/cassandra.json

@@ -46,8 +46,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/classify.json

@@ -77,8 +77,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/leases-expiration.json

@@ -23,10 +23,11 @@
 // will be reclaimed periodically according to the "reclaim-timer-wait-time"
 // parameter. Reclaimed leases will be held in the database for 1800s to
 // facilitate lease affinity. After this period the leases will be removed.
-// The frequency of removal is controlled by the "flush-reclaimed-timer-wait-time"
-// parameter. The lease reclamation routine will process at most 500 leases
-// or will last for at most 100ms, during a single run. If there are still
-// some unreclaimed leases after 10 attempts, a warning message is issued.
+// The frequency of removal is controlled by the
+// "flush-reclaimed-timer-wait-time" parameter. The lease reclamation
+// routine will process at most 500 leases or will last for at most
+// 100ms, during a single run. If there are still some unreclaimed
+// leases after 10 attempts, a warning message is issued.
   "expired-leases-processing": {
     "reclaim-timer-wait-time": 5,
     "hold-reclaimed-time": 1800,
@@ -58,8 +59,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/multiple-options.json

@@ -66,12 +66,13 @@
                 "data": "2001:db8:2::45, 2001:db8:2::100"
             },
 
-            // Typically people prefer to refer to options by their names, so they
-            // don't need to remember the code names. However, some people like
-            // to use numerical values. For example, DHCPv6 can optionally use
-            // server unicast communication, if extra option is present. Option
-            // "unicast" uses option code 12, so you can reference to it either
-            // by "name": "unicast" or "code": 12.
+            // Typically people prefer to refer to options by their
+            // names, so they don't need to remember the code
+            // names. However, some people like to use numerical
+            // values. For example, DHCPv6 can optionally use server
+            // unicast communication, if extra option is present. Option
+            // "unicast" uses option code 12, so you can reference to it
+            // either by "name": "unicast" or "code": 12.
             {
                 "code": 12,
                 "data": "2001:db8:1:0:ff00::1"
@@ -145,8 +146,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/mysql-reservations.json

@@ -25,11 +25,12 @@
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
-// check for each of these identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports two types of identifiers in DHCPv6: hw-address
+// (hardware/MAC address of the client) and duid (DUID inserted by the
+// client). When told to do so, Kea can check for each of these
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
     "host-reservation-identifiers": [ "duid", "hw-address" ],
 
 // Specify connection to the database holding host reservations. The type
@@ -75,8 +76,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/pgsql-reservations.json

@@ -24,11 +24,12 @@
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
-// check for each of these identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports two types of identifiers in DHCPv6: hw-address
+// (hardware/MAC address of the client) and duid (DUID inserted by the
+// client). When told to do so, Kea can check for each of these
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
     "host-reservation-identifiers": [ "duid", "hw-address" ],
 
 // Specify connection to the database holding host reservations. The type
@@ -72,8 +73,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/reservations.json

@@ -27,11 +27,12 @@
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-// Kea supports two types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client) and duid (DUID inserted by the client). When told to do so, Kea can
-// check for each of these identifier types, but it takes a costly database lookup
-// to do so. It is therefore useful from a performance perspective to use only
-// the reservation types that are actually used in a given network.
+// Kea supports two types of identifiers in DHCPv6: hw-address
+// (hardware/MAC address of the client) and duid (DUID inserted by the
+// client). When told to do so, Kea can check for each of these
+// identifier types, but it takes a costly database lookup to do so. It
+// is therefore useful from a performance perspective to use only the
+// reservation types that are actually used in a given network.
     "host-reservation-identifiers": [ "duid", "hw-address" ],
 
 // The following list defines subnets. Subnet, pools and interface definitions
@@ -66,13 +67,13 @@
               "duid": "01:02:03:04:05:0A:0B:0C:0D:0E",
               "ip-addresses": [ "2001:db8:1::100" ]
           },
-// This is similar to the previous one, but this time the reservation is done
-// based on hardware/MAC address. The server will do its best to extract
-// the hardware/MAC address from received packets (see 'mac-sources' directive
-// for details). This particular reservation also specifies two extra options
-// to be available for this client. If there are options with the same code
-// specified in a global, subnet or class scope, the values defined at host level
-// take precedence.
+// This is similar to the previous one, but this time the reservation
+// is done based on hardware/MAC address. The server will do its best to
+// extract the hardware/MAC address from received packets (see
+// 'mac-sources' directive for details). This particular reservation
+// also specifies two extra options to be available for this client. If
+// there are options with the same code specified in a global, subnet or
+// class scope, the values defined at host level take precedence.
           {
               "hw-address": "00:01:02:03:04:05",
               "ip-addresses": [ "2001:db8:1::101" ],
@@ -109,13 +110,15 @@
               } ]
 
           },
-// This reservation is using flexible identifier. Instead of relying on specific
-// field, sysadmin can define an expression similar to what is used for client
-// classification, e.g. substring(relay[0].option[17],0,6). Then, based on the
-// value of that expression for incoming packet, the reservation is matched.
+// This reservation is using flexible identifier. Instead of relying
+// on specific field, sysadmin can define an expression similar to what
+// is used for client classification,
+// e.g. substring(relay[0].option[17],0,6). Then, based on the value of
+// that expression for incoming packet, the reservation is matched.
 // Expression can be specified either as hex or plain text using single
 // quotes.
-// Note: flexible identifier requires flex_id hook library to be loaded to work.
+// Note: flexible identifier requires flex_id hook library to be
+//loaded to work.
          {
              "flex-id": "'somevalue'",
              "ip-addresses": [ "2001:db8:1:cafe::2" ]
@@ -126,8 +129,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/several-subnets.json

@@ -42,8 +42,9 @@
        "subnet": "2001:db8:4::/64"  } ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/simple.json

@@ -42,8 +42,9 @@
   ]
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/stateless.json

@@ -18,8 +18,9 @@
     } ],
 
 // Kea 0.9.1 requires lease-database to be specified, even it is not used.
-// In stateless mode, only options are granted, not addresses or prefixes, so
-// there will be no leases (unless stateless and stateful mode is used together).
+// In stateless mode, only options are granted, not addresses or
+// prefixes, so there will be no leases (unless stateless and stateful
+// mode is used together).
     "lease-database": {
         "type": "memfile",
         "lfc-interval": 3600

doc/examples/kea6/with-ddns.json

@@ -61,8 +61,9 @@
 
 },
 
-// The following configures logging. It assumes that messages with at least
-// informational level (info, warn, error and fatal) should be logged to stdout.
+// The following configures logging. It assumes that messages with at
+// least informational level (info, warn, error and fatal) should be
+// logged to stdout.
 "Logging": {
     "loggers": [
         {