2
0
mirror of https://gitlab.isc.org/isc-projects/kea synced 2025-09-01 14:35:29 +00:00

[#2719] Addressed minor review comments

This commit is contained in:
Thomas Markwalder
2023-03-22 07:14:37 -04:00
parent 13fae7730d
commit fe61ecd57a
2 changed files with 4 additions and 5 deletions

View File

@@ -4495,14 +4495,14 @@ By default, kea-dhcp4 does not allocate or store a lease when offering an addres
to a client in response to a DHCPDISCOVER. In general, kea-dhcp4, can fulfill client to a client in response to a DHCPDISCOVER. In general, kea-dhcp4, can fulfill client
demands faster by deferring lease allocation and storage until it receives DHCPREQUESTs demands faster by deferring lease allocation and storage until it receives DHCPREQUESTs
for them. Release 2.3.6 added a new parameter to kea-dhcp4, ``offer-lifetime``, which for them. Release 2.3.6 added a new parameter to kea-dhcp4, ``offer-lifetime``, which
(when not zero) instructs the server to allocate and persist a lease when generating an (when not zero) instructs the server to allocate and persist a lease when generating a
DHCPOFFER and: DHCPOFFER and:
- The persisted lease's lifetime is equal to ``offer-lifetime`` (in seconds). - The persisted lease's lifetime is equal to ``offer-lifetime`` (in seconds).
- The lifetime sent to the client in the DHCPOFFER via option 51 will still be based - The lifetime sent to the client in the DHCPOFFER via option 51 will still be based
on ``valid-lifetime``. This avoids issues with clients that may reject offers lifetimes they on ``valid-lifetime``. This avoids issues with clients that may reject offers whose
perceive as too short. lifetimes they perceive as too short.
- DDNS updates are not performed. As with the default behavior, that occurs on DHCPREQUEST. - DDNS updates are not performed. As with the default behavior, that occurs on DHCPREQUEST.
@@ -4517,7 +4517,7 @@ DHCPOFFER and:
- In sites running multiple instances of kea-dhcp4 against a single, shared lease store, races - In sites running multiple instances of kea-dhcp4 against a single, shared lease store, races
for given address values are lost during DHCPDISCOVER processing rather than during DHCPREQUEST for given address values are lost during DHCPDISCOVER processing rather than during DHCPREQUEST
processing. Servers that lose the race for the address will simply not respond the client processing. Servers that lose the race for the address will simply not respond to the client
rather than NAK them. The client in turn will simply retry DHCPDISCOVER. This should reduce rather than NAK them. The client in turn will simply retry DHCPDISCOVER. This should reduce
the amount of traffic such conflicts incur. the amount of traffic such conflicts incur.

View File

@@ -1534,7 +1534,6 @@ public:
/// If the client query is a BOOTP query or something other than /// If the client query is a BOOTP query or something other than
/// DHCPDISCOVER, return 0. /// DHCPDISCOVER, return 0.
/// ///
/// @todo Classes not supported yet.
/// Otherwise, the value will be selected from the first /// Otherwise, the value will be selected from the first
/// class matched to the query which defines it or from the subnet /// class matched to the query which defines it or from the subnet
/// if none do. Classes are searched in the order they are assigned /// if none do. Classes are searched in the order they are assigned