[master] Merge branch 'trac5212' (config comments # -> //)

# Conflicts:
#	doc/examples/kea4/reservations.json
#	doc/examples/kea6/reservations.json

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

@@ -9,10 +9,10 @@
     "interfaces": [ "ethX" ]
   },
 
-// We need to specify the the database used to store leases. As of
-// September 2016, four database backends are supported: MySQL,
-// PostgreSQL, Cassandra, and the in-memory database, Memfile.
-// We'll use memfile  because it doesn't require any prior set up.
+// We need to specify the the database used to store leases. As of September
+// 2016, four database backends are supported: MySQL, PostgreSQL, Cassandra, and
+// the in-memory database, Memfile.  We'll use memfile because it doesn't
+// require any prior set up.
   "lease-database": {
       "type": "memfile",
       "lfc-interval": 3600
@@ -28,15 +28,15 @@
 //  "renew-timer": 1000,
 //  "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), circuit-id
-// (circuit identifier inserted by the relay agent) and flex-id (flexible identifier
-// available when flex_id hook library is loaded). 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.
+// (circuit identifier inserted by the relay agent) and flex-id (flexible
+// identifier available when flex_id hook library is loaded). 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
@@ -122,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"
@@ -139,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

@@ -1,92 +1,93 @@
-# This is an example configuration file for the DHCPv6 server in Kea.
-# It is a basic scenario with one IPv6 subnet configured. It demonstrates
-# how to configure Kea to use various backends to store leases:
-# - memfile
-# - MySQL
-# - PostgreSQL
-# - CQL (Cassandra) backend
+// This is an example configuration file for the DHCPv6 server in Kea.
+// It is a basic scenario with one IPv6 subnet configured. It demonstrates
+// how to configure Kea to use various backends to store leases:
+// - memfile
+// - MySQL
+// - PostgreSQL
+// - CQL (Cassandra) backend
 
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# We need to specify lease type. Exactly one lease-database section
-# should be present. Make sure you uncomment only one.
+// We need to specify lease type. Exactly one lease-database section
+// should be present. Make sure you uncomment only one.
 
-# 1. memfile backend. Leases information will be stored in flat CSV file.
-# This is the easiest backend to use as it does not require any extra
-# dependencies or services running.
+// 1. memfile backend. Leases information will be stored in flat CSV file.
+// This is the easiest backend to use as it does not require any extra
+// dependencies or services running.
   "lease-database": {
       "type": "memfile",
       "persist": true,
       "lfc-interval": 3600
   },
 
-# 2. MySQL backend. Leases will be stored in MySQL 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 and name. If other parameters are not specified,
-# Kea will assume the database is available on localhost, that user and
-# password is not necessary to connect and that timeout is 5 seconds.
-# Kea must be compiled with --with-dhcp-mysql option to use this backend.
-#  "lease-database": {
-#      "type": "mysql",
-#      "name": "keatest",
-#      "host": "localhost",
-#      "port": 3306,
-#      "user": "keatest",
-#      "password": "secret1",
-#      "connect-timeout": 3
-#  },
+// 2. MySQL backend. Leases will be stored in MySQL 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 and name. If other parameters are not specified,
+// Kea will assume the database is available on localhost, that user and
+// password is not necessary to connect and that timeout is 5 seconds.
+// Kea must be compiled with --with-dhcp-mysql option to use this backend.
+//  "lease-database": {
+//      "type": "mysql",
+//      "name": "keatest",
+//      "host": "localhost",
+//      "port": 3306,
+//      "user": "keatest",
+//      "password": "secret1",
+//      "connect-timeout": 3
+//  },
 
-# 3. PostgreSQL backend. Leases will be stored in PostgreSQL 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 and name. If other parameters are not specified,
-# Kea will assume the database is available on localhost, that user and
-# password is not necessary to connect and that timeout is 5 seconds.
-# Kea must be compiled with --with-dhcp-pgsql option to use this backend.
-#  "lease-database": {
-#      "type": "pgsql",
-#      "name": "keatest",
-#      "host": "localhost",
-#      "port": 5432,
-#      "user": "keatest",
-#      "password": "secret1",
-#      "connect-timeout": 3
-#  },
+// 3. PostgreSQL backend. Leases will be stored in PostgreSQL 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 and name. If other parameters are not specified,
+// Kea will assume the database is available on localhost, that user and
+// password is not necessary to connect and that timeout is 5 seconds.
+// Kea must be compiled with --with-dhcp-pgsql option to use this backend.
+//  "lease-database": {
+//      "type": "pgsql",
+//      "name": "keatest",
+//      "host": "localhost",
+//      "port": 5432,
+//      "user": "keatest",
+//      "password": "secret1",
+//      "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.
-#  "lease-database": {
-#      "type": "cql",
-#      "keyspace": "keatest",
-#      "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3",
-#      "port": 9042
-#  },
+// 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",
+//      "contact-points": "192.0.2.1,192.0.2.2,192.0.2.3",
+//      "port": 9042
+//  },
 
-# Addresses will be assigned with preferred and valid lifetimes
-# being 3000 and 4000, respectively. Client is told to start
-# renewing after 1000 seconds. If the server does not respond
-# after 2000 seconds since the lease was granted, client is supposed
-# to start REBIND procedure (emergency renewal that allows switching
-# to a different server).
+// Addresses will be assigned with preferred and valid lifetimes
+// being 3000 and 4000, respectively. Client is told to start
+// renewing after 1000 seconds. If the server does not respond
+// after 2000 seconds since the lease was granted, client is supposed
+// to start REBIND procedure (emergency renewal that allows switching
+// to a different server).
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -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

@@ -1,16 +1,16 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# The purpose of this example is to showcase how clients can be classified.
+// This is an example configuration file for the DHCPv4 server in Kea.
+// The purpose of this example is to showcase how clients can be classified.
 
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# Let's use the simplest backend: memfile and use some reasonable values
-# for timers. They are of no concern for the classification demonstration.
+// Let's use the simplest backend: memfile and use some reasonable values
+// for timers. They are of no concern for the classification demonstration.
   "lease-database": {
       "type": "memfile",
       "lfc-interval": 3600
@@ -20,11 +20,11 @@
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
 
-# This list defines several classes that incoming packets can be assigned to.
-# One packet can belong to zero or more classes.
+// This list defines several classes that incoming packets can be assigned to.
+// One packet can belong to zero or more classes.
   "client-classes": [
 
-# The first class attempts to match all packets coming in on ethX interface.
+// The first class attempts to match all packets coming in on ethX interface.
   {
       "name": "lab",
       "test": "pkt.iface == 'ethX'",
@@ -34,16 +34,16 @@
       }]
   },
 
-# Let's classify all incoming RENEW (message type 5) to a separate
-# class.
+// Let's classify all incoming RENEW (message type 5) to a separate
+// class.
   {
       "name": "renews",
       "test": "pkt6.msgtype == 5"
   },
 
-# Let's pick cable modems. In this simple example we'll assume the device
-# is a cable modem if it sends a vendor option with enterprise-id equal
-# to 4491.
+// Let's pick cable modems. In this simple example we'll assume the device
+// is a cable modem if it sends a vendor option with enterprise-id equal
+// to 4491.
   {
       "name": "cable-modems",
       "test": "vendor.enterprise == 4491"
@@ -52,8 +52,8 @@
   ],
 
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
     {
         "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -61,9 +61,9 @@
         "client-class": "cable-modems",
         "interface": "ethX"
     },
-# The following subnet contains a class reservation for a client using
-# DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned
-# to this class.
+// The following subnet contains a class reservation for a client using
+// DUID 01:02:03:04:05:0A:0B:0C:0D:0E. This client will always be assigned
+// to this class.
     {
         "pools": [ { "pool": "2001:db8:2::/80" } ],
         "subnet": "2001:db8:2::/64",
@@ -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/duid.json

@@ -1,23 +1,23 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It demonstrates how to configure Kea to use DUID-LLT with some
-# values specified explicitly.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It demonstrates how to configure Kea to use DUID-LLT with some
+// values specified explicitly.
 
 { "Dhcp6":
 
 {
 
-# Configure server identifier (DUID-LLT). The hexadecimal value of the
-# identifier will be used as link layer address component of the DUID.
-# The link layer type will be ethernet. The value of time is set to 0
-# which indicates that the server must generate this value, i.e. use
-# current time. Note that it is easy to move from this configuration
-# to DUID-EN or DUID-LL. It would require changing the "type" value
-# to "EN" or "LL" respectively. The "identifier" would hold a
-# DUID-EN variable length identifier or DUID-LL link layer address.
-# The values of "time" and "htype" would be ignored for DUID-EN.
-# If one wanted to use a non-default enterprise-id for DUID-EN, the
-# "enterprise-id" parameter would need to be added. Note that only
-# a "type" parameter is mandatory while specifying "server-id" map.
+// Configure server identifier (DUID-LLT). The hexadecimal value of the
+// identifier will be used as link layer address component of the DUID.
+// The link layer type will be ethernet. The value of time is set to 0
+// which indicates that the server must generate this value, i.e. use
+// current time. Note that it is easy to move from this configuration
+// to DUID-EN or DUID-LL. It would require changing the "type" value
+// to "EN" or "LL" respectively. The "identifier" would hold a
+// DUID-EN variable length identifier or DUID-LL link layer address.
+// The values of "time" and "htype" would be ignored for DUID-EN.
+// If one wanted to use a non-default enterprise-id for DUID-EN, the
+// "enterprise-id" parameter would need to be added. Note that only
+// a "type" parameter is mandatory while specifying "server-id" map.
   "server-id": {
     "type": "LLT",
     "identifier": "12C4D5AF870C",
@@ -25,33 +25,33 @@
     "htype": 1
   },
 
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# We need to specify the the database used to store leases. As of
-# September 2016, four database backends are supported: MySQL,
-# PostgreSQL, Cassandra, and the in-memory database, Memfile.
-# We'll use memfile  because it doesn't require any prior set up.
+// We need to specify the the database used to store leases. As of
+// September 2016, four database backends are supported: MySQL,
+// PostgreSQL, Cassandra, and the in-memory database, Memfile.
+// We'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
       "type": "memfile",
       "lfc-interval": 3600
   },
 
-# Addresses will be assigned with preferred and valid lifetimes
-# being 3000 and 4000, respectively. Client is told to start
-# renewing after 1000 seconds. If the server does not respond
-# after 2000 seconds since the lease was granted, client is supposed
-# to start REBIND procedure (emergency renewal that allows switching
-# to a different server).
+// Addresses will be assigned with preferred and valid lifetimes
+// being 3000 and 4000, respectively. Client is told to start
+// renewing after 1000 seconds. If the server does not respond
+// after 2000 seconds since the lease was granted, client is supposed
+// to start REBIND procedure (emergency renewal that allows switching
+// to a different server).
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -61,8 +61,8 @@
   ]
 },
 
-# The following configures logging. It assumes that messages with at least
-# informational level (info, warn, error) will will be logged to stdout.
+// The following configures logging. It assumes that messages with at least
+// informational level (info, warn, error) will will be logged to stdout.
 "Logging": {
     "loggers": [
         {

doc/examples/kea6/leases-expiration.json

@@ -1,32 +1,33 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It provides parameters controlling processing of expired leases,
-# a.k.a. leases reclamation.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It provides parameters controlling processing of expired leases,
+// a.k.a. leases reclamation.
 
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# We need to specify the the database used to store leases. As of
-# September 2016, four database backends are supported: MySQL,
-# PostgreSQL, Cassandra, and the in-memory database, Memfile.
-# We'll use memfile  because it doesn't require any prior set up.
+// We need to specify the the database used to store leases. As of
+// September 2016, four database backends are supported: MySQL,
+// PostgreSQL, Cassandra, and the in-memory database, Memfile.
+// We'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
       "type": "memfile",
       "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,
@@ -36,19 +37,19 @@
     "unwarned-reclaim-cycles": 10
   },
 
-# Addresses will be assigned with preferred and valid lifetimes
-# being 3000 and 4000, respectively. Client is told to start
-# renewing after 1000 seconds. If the server does not respond
-# after 2000 seconds since the lease was granted, client is supposed
-# to start REBIND procedure (emergency renewal that allows switching
-# to a different server).
+// Addresses will be assigned with preferred and valid lifetimes
+// being 3000 and 4000, respectively. Client is told to start
+// renewing after 1000 seconds. If the server does not respond
+// after 2000 seconds since the lease was granted, client is supposed
+// to start REBIND procedure (emergency renewal that allows switching
+// to a different server).
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -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

@@ -1,46 +1,47 @@
-# This is an example configuration file for the DHCPv6 server in Kea.
-# It contains configuration of the MySQL host database backend, used
-# to retrieve reserved addresses, host names, DHCPv4 message fields
-# and DHCP options from MySQL database.
+// This is an example configuration file for the DHCPv6 server in Kea.
+// It contains configuration of the MySQL host database backend, used
+// to retrieve reserved addresses, host names, DHCPv4 message fields
+// and DHCP options from MySQL database.
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# We need to specify the the database used to store leases. As of
-# September 2016, four database backends are supported: MySQL,
-# PostgreSQL, Cassandra, and the in-memory database, Memfile.
-# We'll use memfile  because it doesn't require any prior set up.
+// We need to specify the the database used to store leases. As of
+// September 2016, four database backends are supported: MySQL,
+// PostgreSQL, Cassandra, and the in-memory database, Memfile.
+// We'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
       "type": "memfile",
       "lfc-interval": 3600
   },
 
-# This is pretty basic stuff, it has nothing to do with reservations.
+// This is pretty basic stuff, it has nothing to do with reservations.
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "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
-# specifies that the MySQL database is used. user and password are the
-# credentials used to connect to the database. host and name specify
-# location of the host where the database instance is running, and the
-# name of the database to use. The server processing a packet will first
-# check if there are any reservations specified for this client in the
-# reservations list, within the subnet (configuration file). If there are
-# no reservations there, the server will try to retrieve reservations
-# from this database.
+// Specify connection to the database holding host reservations. The type
+// specifies that the MySQL database is used. user and password are the
+// credentials used to connect to the database. host and name specify
+// location of the host where the database instance is running, and the
+// name of the database to use. The server processing a packet will first
+// check if there are any reservations specified for this client in the
+// reservations list, within the subnet (configuration file). If there are
+// no reservations there, the server will try to retrieve reservations
+// from this database.
   "hosts-database": {
     "type": "mysql",
     "name": "kea",
@@ -51,11 +52,11 @@
     "readonly": true
   },
 
-# Define a subnet with a pool of dynamic addresses and a pool of dynamic
-# prefixes. Addresses and prefixes from those pools will be assigned to
-# clients which don't have reservations in the database. Subnet identifier
-# is equal to 1. If this subnet is selected for the client, this subnet
-# id will be used to search for the reservations within the database.
+// Define a subnet with a pool of dynamic addresses and a pool of dynamic
+// prefixes. Addresses and prefixes from those pools will be assigned to
+// clients which don't have reservations in the database. Subnet identifier
+// is equal to 1. If this subnet is selected for the client, this subnet
+// id will be used to search for the reservations within the database.
   "subnet6": [
     {
       "subnet": "2001:db8:1::/48",
@@ -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,12 +27,13 @@
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-// Kea supports three types of identifiers in DHCPv6: hw-address (hardware/MAC address
-// of the client), duid (DUID inserted by the client) and flex-id (flexible identifier
-// available when flex_id hook library is loaded) 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 three types of identifiers in DHCPv6: hw-address (hardware/MAC
+// address of the client), duid (DUID inserted by the client) and flex-id
+// (flexible identifier available when flex_id hook library is loaded) 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", "flex-id" ],
 
 // The following list defines subnets. Subnet, pools and interface definitions
@@ -67,13 +68,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" ],
@@ -110,13 +111,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" ]
@@ -127,8 +130,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

@@ -1,38 +1,38 @@
-# This is an example configuration file for DHCPv6 server in Kea.
-# It's a basic scenario with one IPv6 subnet configured. It is
-# assumed that one subnet (2001:db8:1::/64 is available directly
-# over ethX interface.
+// This is an example configuration file for DHCPv6 server in Kea.
+// It's a basic scenario with one IPv6 subnet configured. It is
+// assumed that one subnet (2001:db8:1::/64 is available directly
+// over ethX interface.
 
 { "Dhcp6":
 
 {
-# Kea is told to listen on ethX interface only.
+// Kea is told to listen on ethX interface only.
   "interfaces-config": {
     "interfaces": [ "ethX" ]
   },
 
-# We need to specify the the database used to store leases. As of
-# September 2016, four database backends are supported: MySQL,
-# PostgreSQL, Cassandra, and the in-memory database, Memfile.
-# We'll use memfile  because it doesn't require any prior set up.
+// We need to specify the the database used to store leases. As of
+// September 2016, four database backends are supported: MySQL,
+// PostgreSQL, Cassandra, and the in-memory database, Memfile.
+// We'll use memfile  because it doesn't require any prior set up.
   "lease-database": {
       "type": "memfile",
       "lfc-interval": 3600
   },
 
-# Addresses will be assigned with preferred and valid lifetimes
-# being 3000 and 4000, respectively. Client is told to start
-# renewing after 1000 seconds. If the server does not respond
-# after 2000 seconds since the lease was granted, client is supposed
-# to start REBIND procedure (emergency renewal that allows switching
-# to a different server).
+// Addresses will be assigned with preferred and valid lifetimes
+// being 3000 and 4000, respectively. Client is told to start
+// renewing after 1000 seconds. If the server does not respond
+// after 2000 seconds since the lease was granted, client is supposed
+// to start REBIND procedure (emergency renewal that allows switching
+// to a different server).
   "preferred-lifetime": 3000,
   "valid-lifetime": 4000,
   "renew-timer": 1000,
   "rebind-timer": 2000,
 
-# The following list defines subnets. Each subnet consists of at
-# least subnet and pool entries.
+// The following list defines subnets. Each subnet consists of at
+// least subnet and pool entries.
   "subnet6": [
     {
       "pools": [ { "pool": "2001:db8:1::/80" } ],
@@ -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

@@ -1,9 +1,9 @@
-# A very simply stateless configuration that provides information about DNS
-# servers to all clients, regardless of their point of attachment.
-#
-# It is also possible to specify options on a per subnet basis
-# in the same way as in stateful mode.
-#
+// A very simply stateless configuration that provides information about DNS
+// servers to all clients, regardless of their point of attachment.
+//
+// It is also possible to specify options on a per subnet basis
+// in the same way as in stateful mode.
+//
 
 {
 "Dhcp6": {
@@ -11,15 +11,16 @@
         "interfaces": [ "ethX" ]
     },
 
-# This is the list of options that will be granted to all clients that ask.
+// This is the list of options that will be granted to all clients that ask.
     "option-data": [ {
         "name": "dns-servers",
         "data": "2001:db8::1, 2001:db8::2"
     } ],
 
-# 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).
+// 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).
     "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": [
         {