There is one important aspect of the configuration is missing here. Almost every server provides the ability to configure where certain elements are stored. In the simplest implementations this may be a file location, but in more flexible DHCP implementations also offer databases. Kea may be an example. We can configure two types of information (leases and host reservations) independently.
Each can be configured to:
memfile (which is essenially a file), it takes name, which defines the filepath)
mysql or postgres (which defines how to contact a database: hostname, username, password, port, database-name)
cassandra (which is a distributed database. it mostly is configured similar to mysql or postgres, but uses so called contact-points to connect. contact-points is essentially a list of IP addresses)
I can imagine other servers may want to contact RADIUS or LDAP, so access parameters for them should be considered.
I don't think the draft need to go through all the possible combinations, it would be too much hassle. Instead, it should have common attributes, like name (which would be name of the file for servers that use files, or database name for SQL backends), some credentials (probably username, password), port, host name and maybe some other parameters, if you manage to make them generic.
Kea server currently allows configuring storage for leases and reservations, but in the near future it will also be able to store subnets, options and client classes in DB. The model could represent this with a field called storage-purpose with an arbitrary string inside.
@ZagHe568 has added the lease-storage container in 07 with cases for memfile, mysql, postgresql and cassandra in ietf-dhcpv6-server.
@tomaszmrugalski, please check if this is OK.
There is one important aspect of the configuration is missing here. Almost every server provides the ability to configure where certain elements are stored. In the simplest implementations this may be a file location, but in more flexible DHCP implementations also offer databases. Kea may be an example. We can configure two types of information (leases and host reservations) independently.
Each can be configured to:
I can imagine other servers may want to contact RADIUS or LDAP, so access parameters for them should be considered.
I don't think the draft need to go through all the possible combinations, it would be too much hassle. Instead, it should have common attributes, like name (which would be name of the file for servers that use files, or database name for SQL backends), some credentials (probably username, password), port, host name and maybe some other parameters, if you manage to make them generic.
Kea server currently allows configuring storage for leases and reservations, but in the near future it will also be able to store subnets, options and client classes in DB. The model could represent this with a field called storage-purpose with an arbitrary string inside.