[Opendnssec-develop] 20080209 Meeting Agenda
rickard.bondesson at iis.se
Mon Feb 2 08:50:11 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
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?
- - 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)
-----END PGP SIGNATURE-----
More information about the Opendnssec-develop