BIND 10 #1634: Abstract pool/lease store: initial requirements list

[BIND 10 Development]

#1634: Abstract pool/lease store: initial requirements list
-------------------------------------+-------------------------------------
                   Reporter:  tomek  |                 Owner:  UnAssigned
                       Type:  task   |                Status:  reviewing
                   Priority:  major  |             Milestone:  Sprint-
                  Component:  dhcp   |  DHCP-20120220
                   Keywords:         |            Resolution:
            Defect Severity:  N/A    |             Sensitive:  0
Feature Depending on Ticket:         |           Sub-Project:  DHCP
        Add Hours to Ticket:  0      |  Estimated Difficulty:  0
                  Internal?:  0      |           Total Hours:  0
-------------------------------------+-------------------------------------

Comment (by shane):

 I haven't looked at Stephen's or Shawn's comments yet, so there may be
 some duplication.

 First, I think the requirements need an introduction. Something to
 describe what the point of an abstract lease storage is, and how it fits
 into Kea. So, talking about the model of having multiple concrete types of
 lease storage, and so on. It should also discuss the basic functionality
 that lease storage provides, which seems to be both lease storage an pool
 definition according to this document.

 From the general requirements, does it make sense to explicitly mention
 that we want both administrative and programmatic (via an externally-
 exposed API) ability to change leases?

 We should probably say what happens when a pool is removed during
 operation. Possibly when one is added too.

 There is nothing in this document about how lease selection works. From a
 requirements level, we need to say if we want there to be alternative
 algorithms for lease selection. I have a vague feeling that we do,
 although we don't in DHCP 4.x so perhaps that is not important. In any
 case, if we decide that we don't want alternative algorithms we should
 also write that down too.

 We should note that although at an abstract level lease and pool
 definitions must support for a wide range of scaling, concrete
 implementations may not. For example, SQLite does not support wide
 parallelism, but is certainly appropriate for smallish servers.

 Maybe we also want to note support for really, really small scale sites?
 Like SOHO stuff with <10 devices?

 Finally, I think it might make sense to separate out the requirements
 into:

   1. General
   1. DHCP
   1. DHCPv6

 Because it's a bit confusing having them all combined.

 Now I can look at the other comments and see how much overlap there is. :)

-- 
Ticket URL: <http://bind10.isc.org/ticket/1634#comment:7>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development