[kea-dev] Decline support requirements in Kea 1.0

[Marcin Siodelski]

On 26.06.2015 08:10, 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". Plus another requirement which
> would say: "There must be a mechanism by which the system administrator
> can inspect currently declined addresses".
> 
> 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

BTW, I don't believe that the host reservation case requires any special
treatment in the requirements document. It will require some explanation
in the design document, though.

Marcin