[5132] Comments converted in reservations examples

doc/examples/kea4/reservations.json

@@ -1,59 +1,59 @@
-# This is an example configuration file for the DHCPv4 server in Kea.
-# It contains one subnet in which there are two static address reservations
-# for the clients identified by the MAC addresses.
+// This is an example configuration file for the DHCPv4 server in Kea.
+// It contains one subnet in which there are two static address reservations
+// for the clients identified by the MAC addresses.
 { "Dhcp4":
 
 {
-# 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 a lifetime of 4000 seconds.
+// Addresses will be assigned with a lifetime of 4000 seconds.
   "valid-lifetime": 4000,
 
-# Renew and rebind timers are commented out. This implies that options
-# 58 and 59 will not be sent to the client. In this case it is up to
-# the client to pick the timer values according to RFC2131. Uncomment the
-# timers to send these options to the client.
-#  "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) 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.
+// Renew and rebind timers are commented out. This implies that options
+// 58 and 59 will not be sent to the client. In this case it is up to
+// the client to pick the timer values according to RFC2131. Uncomment the
+// timers to send these options to the client.
+//  "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) 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" ],
 
-# 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
-# recommended from a performance perspective, as Kea would not only need to
-# check if a given address is free, but also whether it is reserved.
-# To avoid this check, one can change reservation-mode to out-of-pool, rather
-# than 'all'. If a subnet does not have reservations at all, the reservation
-# lookup can be skipped altogether (reservation-mode is set to 'disabled').
-
-# Note that the second reservation is for an address which is within the
-# range of the pool of the dynamically allocated address. The server will
-# exclude this address from this pool and only assign it to the client which
-# has a reservation for it.
+// 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
+// recommended from a performance perspective, as Kea would not only need to
+// check if a given address is free, but also whether it is reserved.
+// To avoid this check, one can change reservation-mode to out-of-pool, rather
+// than 'all'. If a subnet does not have reservations at all, the reservation
+// lookup can be skipped altogether (reservation-mode is set to 'disabled').
+
+// Note that the second reservation is for an address which is within the
+// range of the pool of the dynamically allocated address. The server will
+// exclude this address from this pool and only assign it to the client which
+// has a reservation for it.
   "subnet4": [
     {
        "pools": [ { "pool":  "192.0.2.1 - 192.0.2.200" } ],
@@ -62,26 +62,26 @@
         "reservation-mode": "out-of-pool",
         "reservations": [
 
-# This is a reservation for a specific hardware/MAC address. It's a very
-# simple reservation: just an address and nothing else.
+// This is a reservation for a specific hardware/MAC address. It's a very
+// simple reservation: just an address and nothing else.
          {
              "hw-address": "1a:1b:1c:1d:1e:1f",
              "ip-address": "192.0.2.201"
          },
 
-# This is a reservation for a specific client-id. It also shows
-# the this client will get a reserved hostname. A hostname can be defined
-# for any identifier type, not just client-id.
+// This is a reservation for a specific client-id. It also shows
+// the this client will get a reserved hostname. A hostname can be defined
+// for any identifier type, not just client-id.
          {
              "client-id": "01:11:22:33:44:55:66",
              "ip-address": "192.0.2.202",
              "hostname": "special-snowflake"
          },
 
-# The third reservation is based on DUID. This reservation also
-# defines special option values for this particular client. If
-# the domain-name-servers option would have been defined on a global,
-# subnet or class level, the host specific values take preference.
+// The third reservation is based on DUID. This reservation also
+// defines special option values for this particular client. If
+// the domain-name-servers option would have been defined on a global,
+// subnet or class level, the host specific values take preference.
          {
              "duid": "01:02:03:04:05",
              "ip-address": "192.0.2.203",
@@ -91,9 +91,9 @@
              } ]
          },
 
-# The fourth reservation is based on circuit-id. This is an option inserted
-# by the relay agent that forwards the packet from client to the server.
-# In this example the host is also assigned vendor specific options.
+// The fourth reservation is based on circuit-id. This is an option inserted
+// by the relay agent that forwards the packet from client to the server.
+// In this example the host is also assigned vendor specific options.
          {
              "client-id": "01:11:22:33:44:55:66",
              "ip-address": "192.0.2.204",
@@ -109,9 +109,9 @@
                  }
              ]
          },
-# This reservation is for a client that needs specific DHCPv4 fields to be
-# set. Three supported fields are next-server, server-hostname and
-# boot-file-name
+// This reservation is for a client that needs specific DHCPv4 fields to be
+// set. Three supported fields are next-server, server-hostname and
+// boot-file-name
          {
              "client-id": "01:0a:0b:0c:0d:0e:0f",
              "ip-address": "192.0.2.205",
@@ -137,8 +137,8 @@
   ]
 },
 
-# 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

@@ -1,42 +1,42 @@
-# This is an example configuration file for DHCPv6 server in Kea
-# that showcases how to do host reservations. It is
-# assumed that one subnet (2001:db8:1::/64) is available directly
-# over ethX interface. A number of hosts have various combinations
-# of addresses and prefixes reserved for them.
+// This is an example configuration file for DHCPv6 server in Kea
+// that showcases how to do host reservations. It is
+// assumed that one subnet (2001:db8:1::/64) is available directly
+// over ethX interface. A number of hosts have various combinations
+// of addresses and prefixes reserved for them.
 
 { "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" ],
 
-# The following list defines subnets. Subnet, pools and interface definitions
-# are the same as in the regular scenario, without host reservations.
-# least subnet and pool entries.
+// The following list defines subnets. Subnet, pools and interface definitions
+// are the same as in the regular scenario, without host reservations.
+// least subnet and pool entries.
   "subnet6": [
     {
       "subnet": "2001:db8:1::/48",
@@ -54,25 +54,25 @@
 
       "reservation-mode": "out-of-pool",
 
-# Host reservations. Define several reservations, note that
-# they are all within the range of the pool of the dynamically
-# allocated address. The server will exclude the addresses from this
-# pool and only assign them to the client which has a reservation for
-# them.
+// Host reservations. Define several reservations, note that
+// they are all within the range of the pool of the dynamically
+// allocated address. The server will exclude the addresses from this
+// pool and only assign them to the client which has a reservation for
+// them.
       "reservations": [
-# This is a simple host reservation. The host with DUID matching
-# the specified value will get an address of 2001:db8:1::100.
+// This is a simple host reservation. The host with DUID matching
+// the specified value will get an address of 2001:db8:1::100.
 	  {
 	      "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" ],
@@ -87,12 +87,12 @@
 	      }],
 	      "client-classes": [ "special_snowflake", "office" ]
 	  },
-# This is a bit more advanced reservation. The client with the specified
-# DUID will get a reserved address, a reserved prefix and a hostname.
-# This reservation is for an address that it not within the dynamic pool.
-# Finally, this reservation features vendor specific options for CableLabs,
-# which happen to use enterprise-id 4491. Those particular values will
-# be returned only to the client that has a DUID matching this reservation.
+// This is a bit more advanced reservation. The client with the specified
+// DUID will get a reserved address, a reserved prefix and a hostname.
+// This reservation is for an address that it not within the dynamic pool.
+// Finally, this reservation features vendor specific options for CableLabs,
+// which happen to use enterprise-id 4491. Those particular values will
+// be returned only to the client that has a DUID matching this reservation.
 	  {
 	      "duid": "01:02:03:04:05:06:07:08:09:0A",
 	      "ip-addresses": [ "2001:db8:1:cafe::1" ],
@@ -126,8 +126,8 @@
   ]
 },
 
-# 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": [
 	{