[kea-dev] Decline support requirements in Kea 1.0

[Thomas Markwalder]

On 6/26/15 2:10 AM, Marcin Siodelski wrote:
>
> On 25.06.2015 18:37, Thomas Markwalder wrote:
>> On 6/25/15 10:35 AM, Tomek Mrugalski wrote:
>>> All,
>>>
>>> Here's another requirements documents written as a preparation for Kea
>>> 1.0. This one covers DECLINE messages support:
>>>
>>> http://kea.isc.org/wiki/DeclineRequirements
>>>
>>> There is one topic that's not covered by the requirements yet: how to
>>> handle declined addresses in the host reservation context. One
>>> reasonable approach is to maintain consistency with what is already
>>> coded. Right now when the server discovers that the reserved address is
>>> used by someone else (there's a lease for someone else), it treats the
>>> reservation as unusable, prints a warning and continues as if there were
>>> no reservation. I'd like to handle the decline case in similar way.
>>> I'm not sure if that requires to be codified in the requirements page,
>>> though.
>>>
>>> Similar to lease expiration discussion, we want to close this discussion
>>> by end of July.
>>>
>>> Comments? Thoughts? Tomatoes?
>>>
>>> Tomek
>>>
>>> _______________________________________________
>>> kea-dev mailing list
>>> kea-dev at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/kea-dev
>> G3 - Stating that a declined address must be removed from the managed
>> pool is a
>> design/implementation detail.  You might reword this a "A declined
>> address MUST not
>> be assigned to a client"
>>
>> C1 - I do not think this requirement is necessary.  G1 and G2 already
>> require it be
>> supported.  I'm not sure you gain anything by having this.
>>
>> C3 - Remove the parenthetical suggestion of how-to.  This belongs in a
>> design document.
>>
>>
>> H1 and H2 - The word "new" is unnecessary.
>>
>>
>> S1 - Change "being declined" to "currently in the declined state"
>>
>>
>> S2 - Clarify that this value resets upon server restart.  Otherwise it
>> implies we must
>> keep track across restarts forever.
>>
>>
>> S3 - As with S1, "being declined" to "currently in the declined state"
>>
>> _______________________________________________
>> kea-dev mailing list
>> kea-dev at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-dev
>>
>
> I agree with Thomas's suggestions above and have the following
> additional comments.
>
> "Declined address" in the terminology - suggest replacing "unknown
> entity" with a "different entity", as "unknown" is ambiguous.
>
> "Declined state":  - suggest to reword to "a state in which an address
> is marked by the server as unavailable for the assignment"
>
> G4 - rather than adding the explanation what it means to "recover an
> address", it would be better to add a new term in the terminology and
> use it here:
>
> "Declined address recovery (or Address Recovery)" - a process by which
> the server marks an address in the declined state as available for
> assignment again, i.e. moves it out of the declined state.
>
> G6 - I think it is too much for the requirements to imply that the
> declined addresses must be kept in the database. It would be sufficient
> to say that "The information about currently declined addresses MUST not
> be lost after system restart or crash".

This one could lead us down a rabbit hole:
>  Plus another requirement which
> would say: "There must be a mechanism by which the system administrator
> can inspect currently declined addresses".
Unless it is sufficient to accept the requirement as met by us documenting
how the information can be understood by examination of the persisted
data.   At first blush it implies we will provide some sort of tool or
interface
for reporting or retrieving this information.   We also made no such
requirement
for any other persisted information.   I would suggest we simply drop it.



> G7 - I suggest updating this requirement to say that the log message
> emitted, when the address is marked declined, includes the duration of
> time for which the address will remain in the declined state.
>
> C2 - I suggest rewording it slightly to use the terminology: "The amount
> of time an address remains in the declined state MUST be configurable"
>
> C3 - Similarly to C2 - It MUST be possible to configure the server to
> keep an address in the declined state until sysadmin intervention.
>
> Marcin
I agree with the rest of Marcin's comments.