[Opendnssec-develop] 20080209 Meeting Agenda

[Rickard Bondesson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

These are the meeting topics:

*************************************

1. Who will write minutes?
- - Decide who will write minutes during this meeting.

2. System architect
- - Do we need an architect who makes the end decisions about the overall architecture? What are the responsibilities?

3. Marketing plan
- - Use Cases
  Discuss the use cases presented on the mailing list. Do we need to fulfil all of the use cases? What do we need to fulfil the individual use case? 
- - Market study
  What experiences do we have from the market? Do we need to do a study of what our potential users might want? How should such study be performed? Who should we ask?
- - Marketing of our product
  Do we want our product to be noticed by other parties than us? Who would that be? How do we reach them?

4. Tasks, priorities, scheduling

Discuss what tasks pop up, where they come from, which component is in charge of scheduling.  This can be a major source of complexity if we want to deliver a reliable signer.

One of the possible problems that could arise is that there are many sources of events, and nobody has an overview of what should be done when. Let alone that it would be possible to schedule downtime for maintenance.  (Matthijs pointed out this issue.)

All these issues may suggest that we need some form of realtime scheduler, so we don't have to invent too many wheels.

5. Robustness through redundancy

For some applications, such as TLDs and the root zone, we should look into what it takes to create a robust setup.  We do not want to fail our most important domains "just" because of a local earthquake. Designing this into the system is not very difficult, using existing clustering techniques, but it is good to have in mind early in the design process.

This can probably be established in the KASP with either of the following approaches:

a) The KASP is redundant, for example because it uses a distributed redundancy mechanism (think of MySQL replication, DRBD, ...) and the result is that keys are available to all signers. Slaves can simply be directed to the signer that is currently to be trusted.

b) The DNSKEY records of each of two (or more) independent signers are brought into all the signers, in some way that integrates with the IXFR approach and/or with the master name server.

6. Design diagrams
- - What proposals of system design do we have? Pros and cons? Can we bring them together?

7. System design for phase 1 and 2
- - General architecture
  Do we agree on the general concept? Is there something we would like to change?
- - Components
  Can we specify the components any more? Any requirements?
- - Data flow diagram
  Discuss how the data is flowing through the architecture.
- - API between the components
  How should each component talk to its neighbours?

8. Discussion about each component
- - What has been done?
- - What needs to be done?
- - How much time does each subtask need?
- - Testing?

9. SoftHSM
- - Should the object information be kept further away than they are now? As of now, all object information is available within the linked library. Should this information be kept away more securely in a form of “server”, which the linked library talks to?

10. OpenDNSSEC v1.0 and v1.1
- - How should we fit everything together?
- - Testing?

11. Comparison of HSM:s
- - What information do we want on the wiki? A more detailed comparison? A how-to? Configurations? Recommendations?

12. About the project
- - Trademark
  How should we protect our trademark?
- - Packaging the code
  How should our program/code be published? Debian/RPM/…?
- - Statistics
  Do we want to keep statistics on our wiki visitors? Page views, downloads, etc. 

13. Next meeting
- - How and when?
-----BEGIN PGP SIGNATURE-----
Version: 9.8.3 (Build 4028)
Charset: utf-8

wsBVAwUBSYazw+CjgaNTdVjaAQg1Fwf+NVnvwd5wmOTpaCU8UEPhi0m11LAeUamx
jixHnshTw1BgeskKNpsXHBTga6pFLxQwHOLhTqmyu2Qi6RT9XcXiOnvu0FN2FRfR
SXYSx3FOpQZtRqsUcMKauV2pgk1b2cjPvJTbgNySZEcGygqZ4+BrFmp9yDWO20iQ
QUtVOt8hYa5Ao25KJzr4CXTCSW0pn6XBCOklmhPG3j3cnc3QnEBOWe6zqI1jkTVo
3EbseqJg2Z4lKI2ySS+BKswz+qsO1Gqk2VmSB4Lm+gLF2AuVeUavqHMKs2gNZv/6
tG6mEUq1H9q6IrPW3J8EQEb5Nky9vfb4q3yR9xTtUBMEHf6Si1SlQA==
=IN0C
-----END PGP SIGNATURE-----