[bind10-dev] Planning for next sprint - input required

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/25/2010 07:25 PM, Stephen Morris wrote:
> As mentioned in the last sprint planning meetings, I would like us to start thinking about what we are going to do in the next sprint when this one finishes.  The basic user stories are fixed for the A-Team (performance improvements) and R-team (working recursor), but within those stories we do have a bit of flexibility as to the tasks we tackle.
> 
> The following list is a set of tasks that I've put together from these stores.  It is by no means complete and not all tasks are equally important.  What I hope it will do is to start a discussion as to what we need to do over the next few months (and in particular the next few weeks) and allow us to prioritise (and estimate) the tasks appropriately so that we can reach our year 2 goals.
> 
> In the short term thought, the six-week release cycle is coming to an end next week.  At the planning meetings next week, we need to assess where we are and what we achieved, decide what our goals are for the following cycle and estimate/select the tasks appropriately.
> 
> So please, come back with additions/deletions to the task list, assessment of priority and any comments you care to make.  Can you also start giving thought to as to the tasks we should focus on for the next sprint?
> 
> Thanks
> 
> Stephen
> 
> 
> 
> General/Common
> ==============
> This section covers tasks that are common to both the A- and R-teams.
> 
> General Requirements
> * Working through DNS RFCs and identifying MUST/SHOULD etc requirements
> * Working through BIND-9 configuration options and identifying specific features
> * Working through BIND-9 bug/enhancement list and identifying specific features
> 
> Notes: the authoritative and recursive servers are subject to a large number of RFCs, many of which have explicit RFC2119 (SHOULD, MUST etc.) requirements and others with indicate best current practice.  In addition, a number of features have been added to BIND over the years (either as enhancements, as a result of bug reports or at customer request) that should be incorporated into BIND10.  (A partial list of BIND-9 features can be found at http://bind10.isc.org/wiki/BIND9Features) The result is that at some point we will need to a check for completeness and feed that into the system test.
> 

'offline' configuration and/or standard initial profiles (as briefly discussed
today).
Whether or not we do this through bindctl, we need some API for this.
* Support for reading spec-files outside of the configuration manager
	- this may include having them in a known location, done for
          installed, but they are spread throughout the source tree
* checking if system is running, connect to that if so, otherwise load
  the config db and write it
* if we do this with bindctl we need to think what form this would take :)

> 
> Logging Framework
> * API Requirements+Design, e.g.
>   - Facilities (auth, recurse, xfrout etc.)
>   - Subcomponents (e.g. cache, query logic, validation etc.)
>   - Levels (info, warning, debug)
>   - Logging destinations
>     - syslog, file, socket, combination
>     - per-destination filters?
> * C++/Python Implementation 
> 
> Notes: this was raised at the last face to face.  BIND-10 needs a comprehensive logging framework.  The longer we put this off, the more code we will have to re-factor to include include it.  It therefore makes sense to do this early and to start adding it to code as we write it.
> 

agree on the logging, sounds like a good next sprint goal.

> 
> DNSSEC Key Interface
> * HSM interface
>   - Key generation
>   - Key addition/removal/listing
> * File interface
>   - Key generation
>   - Key addition/removal/listing
> 
> Notes: many top-level domains use HSMs to store their keys and to sign/check the signatures.  Existing BIND code uses key files.  Ideally we want a single abstract key store to which a variety of storage mechanisms can be connected.  PKCS#11 is the default for HSMs (and that would also allow use of SoftHSM); however some sites may want to continue with the key file idea, in which case a PKCS#11-style interface to those files would simplify the code that uses keys.
> 
> The issue goes deeper than a single HSM as the issue of HSM replacement - and the movement of keys between HSMs - must be considered. (For reference, OpenDNSSEC allows simultaneous access to multiple HSMs, the idea being that when an HSM is retired, if keys can't be transferred to another HSM a key roll takes place, the new key coming from the new HSM.)
> 

OpenDNSSEC has quite a sexy interface for this; the only thing you pass around
are key identifiers, and it figures out by itself which HSM that is to be used
in. I suggest we take a similar approach (i.e. not only use pkcs#11 as the
general backend interface, but also abstract away from HSM's in use and
configuration).

No further comments on the rest at this moment

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkz0E4gACgkQ4nZCKsdOncXvnwCgq0JFM94ullH8ppp2XAHD07Xy
tQMAn3fN92yg9f8rmdFdRK3LHSat4deX
=hnAl
-----END PGP SIGNATURE-----