// This is a simple example of a configuration for Netconf that handles
// DHCPv4 configuration. This example provides YANG interface for
// DHCPv4 server only.
{
    "Netconf":
    {
        // Three flags control netconf (default values are true):
        // - "boot-update" about the YANG configuration load when
        //   netconf boots.
        // - "subscribe-changes" about the subscription to notifications
        //   when the running YANG module is changed.
        // - "validate-changes" allows to validate changes or not.
        "boot-update": true,
        "subscribe-changes": true,
        "validate-changes": true,

        // This map specifies how each server is managed:
        // the YANG model to use and the control channel.
        "managed-servers":
        {
            // This is how Netconf can communicate with the DHCPv4 server.
            "dhcp4":
            {
                // Eventually, the kea-netconf will be able to handle multiple
                // models. However, for the time being the only choice for
                // DHCPv4 server is kea-dhcp4-server model.
                "model": "kea-dhcp4-server",

                // The three control flags can be defined in this scope too
                // and takes precedence over global and default values.
                // boot-update determines whether the initial configuration
                // should be retrieved from netconf during kea-netconf startup.
                // You almost always want to set this to yes.
                "boot-update": true,

                // This flag control whether the kea-netconf daemon should
                // subscribe to any changes. If set to true, kea-netconf will
                // monitor sysrepo and will pick up any changes that may be
                // introduced, either using netconf clients or sysrepocfg.
                "subscribe-changes": true,

                // This parameters specifies whether kea-netconf will attempt
                // to verify if the upcoming NETCONF configuration is sane. The
                // verification is done by calling config-test. Depending on
                // Kea response, the new configuration is accepted or rejected.
                "validate-changes": false,

                // Currently three control channel types are supported:
                // - "stdout" which output the configuration on the standard
                //   output (this is mainly for testing purposes, but you can
                //   use simple script (such as curl or socat) to pass that
                //   information to the server.
                // - "unix" which uses the local control channel supported by
                //   "dhcp4" and "dhcp6" servers ("d2" support is coming in Kea 1.5)
                // - "http" which uses the Control Agent (CA) to manage itself or
                //   to forward commands to "dhcp4" or "dhcp6".
                "control-socket":
                {
                    "socket-type": "unix",
                    "socket-name": "/tmp/kea4-ctrl-socket"
                },

                // Comment is optional. You can put some notes here.
                "comment": "Kea DHCP4 server serving network on floor 13"
            }

        },

        // Netconf is able to load hook libraries that augment its operation.
        // The primary functionality is the ability to add new commands.
        //
        // Uncomment this section to load a hook library.
        //
        // "hooks-libraries": [
        //    // Hook libraries list may contain more than one library.
        //    {
        //        // The only necessary parameter is the library filename.
        //        "library": "/opt/local/netconf-commands.so",
        //
        //        // Some libraries may support parameters. Make sure you
        //        // type this section carefully, as the CA does not validate
        //        // it (because the format is library specific).
        //        "parameters": {
        //            "param1": "foo"
        //        }
        //    }
        //]

        // Similar to other Kea components, Netconf also uses logging.
        "loggers": [
            {
                "name": "kea-netconf",
                "output_options": [
                    {
                        //"output": "/var/log/kea-netconf.log",
                        "output": "stdout",
                        // Several additional parameters are possible in addition
                        // to the typical output. Flush determines whether logger
                        // flushes output to a file. Maxsize determines maximum
                        // filesize before the file is being rotated. maxver
                        // specifies the maximum number of rotated files being
                        // kept.
                        "flush": true,
                        "maxsize": 204800,
                        "maxver": 4,
                         // We use pattern to specify custom log message layout
                        "pattern": "%d{%y.%m.%d %H:%M:%S.%q} %-5p [%c/%i] %m\n"
                    }
                ],
                // You can change the severity to DEBUG, INFO, WARN, ERROR or
                // CRIT. For DEBUG level, you can also additionally specify
                // debuglevel (0-99, higher = more verbose). All configurations
                // are logged on DEBUG/55.
                "severity": "INFO",
                "debuglevel": 0
            }
        ]
    }
}