IACR Publication Reform :  Cryptology ePrint Archive Forum
Discussion related to IACR's current and future publications: conference proceedings, Journal of Cryptology, and revolution of IACR's publications.  
Goto Thread: PreviousNext
Goto: Forum ListMessage ListNew TopicSearchLog In
Some issues + Counter proposal
Posted by: Orr (IP Logged)
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.

Re: Some issues + Counter proposal
Posted by: cbw (IP Logged)
Date: 04 June 2013 11:52


I mainly agree with Orr. However, there are a few points I would like to make:

Ad 5: This could work - but I think it will create some overload. It's a half-baked attempt to keep the original conferences on the surface - but to have /one/ submission venue ("Collection of IACR Conferences") in the background. I think we are better of having /one/ submission venue not only de-facto but also by-name.

Ad X: Yes, I would also like to use JoC in Series A & B mode. However, the destinction should not use all letters of the alphabet. I guess, we are fine with
* JoC-A: currently JoC
* JoC-B: Proc/IACR
* JoC-C: Open Source implementations of cryptographically relevant software

To explain the last: In some areas of mathematics, they have A: Pure, B: Applied, C: Software as otherwise "Software" would not have a place to publish. I do find this a very good suggestion and would like to copy if for the IACR.


Please log in for posting a message. Only registered users may post in this forum.