OpenDNSSEC phone meeting 17-06-2009
Present: Stephen, Rick, Sion, Roy, Alex, Antoine, Rickard, Jakob.
0. Who takes minutes?
Rick.
1. Agenda
OK.
2. Components
KASP enforcer: Has issues with concurrent access to SQLite; locking is a compile-time option and it is disabled in several distributions. A rogue work-around through file locking has been created to compensate in a general manner.
Signer engine v2: Has not yet been discussed at NLnet Labs. The structures of v1 are followed in its implementation, but it is written in C.
Libhsm: More or less done.
Auditor: Everyone can test now.
Signer engine v1: Some bugs have been found in the signing part. Most of these are resolved.
3. HSMbully
Implemented, with the exception of one test which is expected to be done today. Actively looking for HSM's to test on.
4. Integration
All seems to be working for the first version.
5. Ready for alpha?
Probably. More insight is likely to come next week, when programmers meet en face. We want a turnkey solution, and demonstrate it, no matter how minimalistic it is.
6. System testing
The latest version has been uploaded. It contains tests for regularly resigning and ZSK rollover. Tests for KSK rollover remain to be done.
7. Requirement testing by SIDN
Antoine tells us that SIDN (the .nl registry) has been wondering what they could add to the OpenDNSSEC project. Programmers are clearly not needed, and adding marketing also seems like overkill. But SIDN has a very good test lab, and is offering to toss in their support. These testers would do requirements testing, treating OpenDNSSEC as a black box.
It will take July to hire someone. A tester will most likely need better user documentation than what currently exists. Patrick will write such documentation.
8. NSEC existence
Signers spit out NSEC records, even if no signing is done. Is that OK? This probably is a bug, but it should be harmless, albeit superfluous.
9. Negative values
If we allow for negative values, we can end up having rather surprising configurations. As it seems, only one place uses negative values, namely the inseption offset which is always negative. It is better to redefine this parameter so it is always positive, and simply disallow negative numbers in the configuration file. his ought to save us quite a bit of trouble.
10. Configuration changes and notifications
Are we happy to have a commandline program to do notifications when a configuration change occurs? Or do we want to poll for changes?
We decide that it is better to explicitly run a command; this means that saved mistakes are not automatically incorporated into the signer; it means that we will not need to poll files; and it means that halfway made changes are not signed and published.
11. Dependencies?
This will be dealt with in Amsterdam.
12. Marketing materials
Not everyone has seen this, so a general discussion is not possible. The ideas will be sent to the mailing list.
13. Announcement and user lists
Do we want to setup any such lists? Roy maintains them.
We decide to create an announcement list right now, so interested parties can subscribe and be informed when our alpha (and later versions) are issued.
A user list is also considered necessary, but that only needs to exist at the time we actually come to our first release.
14. Next meeting?
No date for a phone meeting is set yet.
The face to face programming/integration effort will be on the 22nd and 23rd of June, 2009. These meetings will start at 9:30 as most people will be able to arrive at that time, or shortly thereafter.
15. Questions?
Nothing tables.
