Some issues + Counter proposal
Posted by: Orr
Date: 31 May 2013 13:56
1. The proposal does not deal with IACR workshops. If the revolution happens as-is, I support the inclusion of the workshops in the proceedings of the IACR as well, and let the workshops pick the papers not taken by the main venues. Otherwise, the workshops will be cannibalized by the Proc.IACR.
2. Depending on the number of the papers in Proc.IACR (anything which is significantly higher than the number of papers accepted at the moment to all IACR venues), the satellite non-IACR venues may be hurt (if Proc.IACR accepts 500 papers rather than ~250-300 papers, people will submit to proc.IACR, and no one will submit to SAC, CT-RSA, Indocrypt, etc., thus "killing" these venues (some of which with great importance in supporting local communities).
3. There should be a wider discussion than just two reviewers + 1 editor. While this does not happen very often (if at all), some members of the community feel that some of the reviews are done according to the person/field/approach rather than the actual technical merits. A 3-person decision is necessarily more susceptible to this problem than a 30-person decision process. This is especially important with the paper we do need to promote which reside on the borderline between two communities (e.g., TCC/FSE papers).
4. If the main problem this problem comes to solve is the review period, a transition to a JoC where the editors are somewhat harsher with reviewers, and reviewers understand the importance of a timely review, is probably a better solution.
5. To reduce the workload of reviewers between committees, we can maintain the reviews from conferences going into the next conference. For example, the papers that were the last one to be rejected (borderline accept/reject papers), the reviews will be transfered to the next committee, and the number of assigned reviewers can be reduced (just a thought).
6. In papers with missing details (due to page limit, lack of time, etc.) - committees should approach things with harsher approaches concerning the missing details. Full proofs can be now described (in some cases) by the automatic tools, we should use them. Pseudo codes of attacks, or VHDL prints can be accessible through some new anonymity preserving mechanisms.
Finally, I would like to suggest to maintain the conference model (with some changes and improvements), and solve the publication issue by introducing a series of "sub-journals": JoC-A, JoC-B, ... (as many as we need).
- All papers will be submitted to JoC.
- If the reviewers decide it's worthy of acceptance, and of value to the entire crypto community -> JoC.
- Worthy of acceptance, value to parts of the crypto community - will be directed to the relevant JoC-A/B/... (dividing the JoC world into several domains). Maybe requiring an additional review.
Of course, one can do the opposite (maybe besides the best paper awards of all IACR venues): submit to JoC-A/B/... according to the domain separation, and if the reviewers+editor of JoC-X thinks it is of value to the entire crypto community, move it to the JoC pile (possibly with an additional reviewer from outside the community).
This way, more good journals are created, and the value of JoC is not cannibalized by the new journals.