Här är en start på det vi kommer att behöva. Kanske inte exakt så här, och sannolikt lite till. Men om vi skriver detta så kan vi stuva om och komplettera efteråt.
[ ] Introduction. Problembeskrivning, referenser till existerande RFC + draft in-progress. Referens till MUSIC och att modellen med extern access till att modifiera zon inte funkat.
[ ] Modeller för distribuerad multi-signer: "tightly coupled": en controller leder varje process. Pros and cons: måste välja en ledare, X509, non-DNS, etc. "loosely coupled": alla controllers kör eget race, endast notifieringar delas. Om de drar olika slutsatser så stannar maskinen.
Påpeka att båda modellerna beror av att individuella controllers kan lokalisera varandra.
[ ] Requirement for tightly coupled: validated TLSA, established secure comms, etc.
[ ] Requirements for loosely coupled: valudated SIG(0) public keys, established secure DNS messages, etc.
[ ] The MSIGNER RRset: detaljer, detaljer
[ ] REST API beskrivning: /hello, /heartbeat, /event, /election, ...
[ ] DNS-based beskrivning: det enda som skickas är i princip NOTIFIES för zonen där man informerar om vilken state transition som sker (alternativt i vilket state man är). Jag gissar att specifikationen åker som en EDNS(0) payload enligt en separat draft a la "Multi-Signer State Notificatation via DNS". Men vi behöver fortfarande beskriva att det är SIG(0)-signerade NOTIFY-meddelanden med "state" i en EDNS(0) opt.
[ ] Comparision between models.
[ ] Security Considerations. Denna kräver beskrivning av att all kommunikation måste säkras för att inte öppna för attacker samt att detta har gjorts för båda modellerna: antingen via verifiering av CERT mot TLSA mot DNSSEC, eller verifiering av publik SIG(0)-nyckel mot DNSSEC.
[ ] IANA Considerations. Om vi lägger de nya EDNS(0) sakerna i en separat draft så blir det kanske tomt här?
Jag tror att vi måste dela upp dessa mellan oss på något bra sätt. Välj de punkter ni vill arbeta med och gör dem till egna issues och tilldela er själva.
Här är en start på det vi kommer att behöva. Kanske inte exakt så här, och sannolikt lite till. Men om vi skriver detta så kan vi stuva om och komplettera efteråt.