... | ... | @@ -23,20 +23,24 @@ This page documents status of client classification as of 1.5.0 (January 2019), |
|
|
1. Need to weigh pros and cons of keeping the options precedence or changing it. In any case, we need to explain our decision and clearly say that it's gonna stay that way.
|
|
|
|
|
|
|
|
|
# Possible directions
|
|
|
# Possible actions
|
|
|
|
|
|
Direction A: We could change the order to match ISC DHCP
|
|
|
**Action A**: We could change the order to match ISC DHCP
|
|
|
|
|
|
There are arguments in favor of going the way ISC DHCP with options precedence:
|
|
|
1. some people perceive client classes as more generic host reservations, almost like reservations with wildcards. ("I don't mean this Arris AG561 modem with MAC 01:02:03:04:05:06, I mean all all Arris AG561 modems").
|
|
|
2. fewer surprises when migrating from ISC DHCP
|
|
|
1. PRO: some people perceive client classes as more generic host reservations, almost like reservations with wildcards. ("I don't mean this Arris AG561 modem with MAC 01:02:03:04:05:06, I mean all all Arris AG561 modems").
|
|
|
|
|
|
Direction B: We could make the order configurable.
|
|
|
1. PRO: Fewer surprises when migrating from ISC DHCP
|
|
|
|
|
|
1. + This would allow us to solve all the "but I want the class/pool/subnet options to be sent" requests.
|
|
|
1. - If misconfigured, there's a huge potential to shoot your own foot.
|
|
|
1. CON: The obvious drawback is a change for Kea users. Although we warned them in 1.4 release notes that the precedence may change.
|
|
|
|
|
|
Direction C: **add your proposal here**
|
|
|
**Action B**: We could make the order configurable.
|
|
|
|
|
|
1. PRO: This would allow us to solve all the "but I want the class/pool/subnet options to be sent" requests.
|
|
|
|
|
|
1. CON: If misconfigured, there's a huge potential to shoot your own foot.
|
|
|
|
|
|
**Action C**: _add your proposal here_
|
|
|
|
|
|
# References
|
|
|
- https://jenkins.isc.org/job/Kea_doc/guide/kea-guide.html#dhcp4-client-classifier
|
... | ... | |