Sponsored by USENIX, The Advanced Computing Systems Association

Please read these guidelines carefully. We have written them to help you give your submission its best possible chance to be accepted. (As you know, the Program Committee can't accept every paper submitted to the conference.) Generally speaking, we are looking for papers in a broad range of practical issues in the technology and use of open computer systems. However, please don't choose not to submit your paper because you think that it will not "fit" the USENIX conference format. Some of the best papers of the past conferences have been papers that were unusual and definitely not "traditional". The key element of a good paper is that it teaches the readers something that they can use when designing or using their systems, or causes them to think about a computing issue in new ways. CONFERENCE DATES: The USENIX conference will be held in New Orleans, Louisiana, June 15-19, 1998. The technical sessions will be held Wednesday through Friday, June 17-19. Dates for paper submissions: Submissions due: November 25, 1997 Notification to authors: January 26, 1998 Full papers due for editorial review: March 30, 1998 Camera-ready papers due: April 27, 1998 THE CALL FOR PAPERS: For your convenience, here is a summary of the important information in the Call For Papers: Authors must submit a full draft of the paper to the program chair via one of the following methods. Papers should be 8 to 12 single-spaced 8.5"x11" pages (about 4000-6000 words), not counting figures and references. Papers longer than 12 pages will be discarded without review. All submissions will be acknowledged. Preferred Method: Email to usenix98papers@usenix.org. If possible, please use MIME to attach your paper. You should attach the cover letter (see below) as a separate MIME enclosure. Alternate Method: Surface mail to: Fred Douglis Room A181 AT&T Labs - Research 180 Park Avenue Florham Park, NJ 07932-0971 Phone: 973-360-8775 The authors must also submit via Email to usenix98papers@usenix.org the following information: The title of the manuscript and the names of the authors. The name of one author who will serve as a contact, their email address, day and evening phone numbers, postal mail address, and a fax number, if available. An indication of which, if any, of the authors are full-time students. A short abstract of the paper (100-200 words) (this can be the same as the paper's abstract). If you wish to ensure confidentiality, you may PGP-encrypt your submission. You may retrieve the program chair's PGP key at the following URL: https://www.research.att.com/~douglis/pgp.txt. Its fingerprint is: E9 F8 BF BE 52 D6 07 A6 D9 D5 28 B8 20 46 D5 1E The final paper should be 8-12 USENIX conference pages in length. WHAT KINDS OF PAPERS DOES USENIX PUBLISH? The most important thought to keep in mind when deciding whether to submit a paper is "what will the audience or readers learn from my paper?" We don't expect every paper to report on a major breakthrough, but we do look for something new, potentially useful, and not entirely obvious. Think about how different your work is from previously published papers; it may be good work but if there is nothing new to learn, it isn't worth reading (or writing) a conference paper about it. Think about how other people might find your work useful; can they apply what you are teaching them to their own systems? And, does your work really improve upon the previous state of the art? Or does it show how other people have been confused? "Negative results" that contradict the conventional wisdom are often more important than positive results. Trying to decide if something is non-obvious isn't easy (patent lawyers make lots of money arguing about this), and sometimes the best ideas seem obvious in hindsight; but if lots of people have done the same thing, and you are simply the first person to have considered writing a paper about it, perhaps it's too obvious. Also think about whether a USENIX conference is the right place to publish your paper. Perhaps it belongs in a more theoretical conference, or a conference with a different kind of focus. Or perhaps it doesn't belong in a conference at all; it might be more appropriate for a USENIX publication, like the newsletter ;login: or a journal such as ACM Transactions on Computing Systems. On the other hand, USENIX conferences typically cover a broad range of practical issues in open computer systems. It may be that you can take a paper that has several possible themes, and write it to concentrate on issues specifically interesting to a USENIX audience. The Program Committee will also be trying to decide if papers will lead to a good 25-minute presentation. Some systems are just too complex to be presented this way (perhaps you should focus on just one aspect); other papers just don't have enough to talk about for that long. On the other hand, a few rare papers are accepted mostly because the committee expects them to produce an interesting talk, but that might not otherwise merit publication. Again, when you are writing your paper, keep in mind "what do I intend to teach the reader?" That means keeping the paper focused on one or a few main points. Don't try to cram too many big issues into the paper, and don't fill it up with irrelevant details. But do include enough background for the reader to understand why your problem is important, how your work relates to previous work in the field, and how it might fit into a practical system. Also, provide enough detail for the reader to put your performance measurements in context. It is vitally important to provide a good bibliography, both so that you give proper credit to previous work, and so that a reader can know where to turn to find additional background information. The program committee will not look kindly on a paper if the author doesn't appear to be familiar with the current literature. WHAT DO WE MEAN BY A DRAFT OF A FULL PAPER? You will have the opportunity to revise your paper before the camera-ready copy deadline, so it's OK to have a few rough edges or to include a few explanatory notes for the program committee. However, a submitted draft of your paper should include essentially all of your results and a substantial portion of your analysis. Please do not omit any essential details. Note that although in some past years, and at other conferences, one could submit an "extended abstract," you MUST submit a full paper for this conference. HOW SHOULD I GET MY MANUSCRIPT TO YOU? The Program Committee would prefer to receive submissions via electronic mail, but there are occasionally problems in printing them. If you have any reason to suspect that your submission might not be easy for us to print, please submit a printed hardcopy by surface mail in addition to your electronic version. Submissions via email can be made in several formats. The simplest to read and distribute is Postscript, as long as it uses standard fonts or includes everything needed, and has not been generated in a non-portable environment. (Some PostScript generators are quite buggy and we may not be able to print their output. For example, lots of software generates PostScript that can only be printed on Apple Laserwriters.) If you send PostScript, remember the following: Use only the most basic of fonts (TimesRoman, Helvetica, Courier), or include nonstandard fonts. Other fonts are often not available with every printer or previewer. PostScript that requires some special prolog to be loaded into the printer won't work for us. Don't send it. If you used a PC or Macintosh-based word processor to generate your PostScript, print it on a more generic PostScript printer before sending it, to make absolutely sure that the PostScript is portable. Another portable method is Adobe's PDF format. That's somewhat less desirable since not everyone who reviews your paper may have easy access to acroread. Flat text files are always easy to print, but if you have any figures or graphics this probably won't work. If you do use flat text, please remember to format it neatly and keep lines under 80 columns in width. We really don't want to have to format your input ourselves. If you can't generate Postscript or PDF, contact the chair to discuss alternatives, such as providing LaTeX input. NOTE: no extensions will be granted in cases of non-standard formats -- if you need us to do something special, we absolutely need everything from you by the November 25 deadline. By the way, if you are using troff or LaTeX, try to use either the troff template or LaTeX template available here. DON'T send files meant for other word-processing packages (Word, WordPerfect, MacWrite, etc.). We don't have the resources to deal with them. Since electronic mail systems have been known to mangle mail, it is always a good idea to wrap up your submission either by using MIME encapsulation (quoted-printable or base64, as appropriate) or by using shar(1) or tar(1). MIME is much preferred. Note, if you use tar, or, if your email contains any non-printing characters, use uuencode(1) to convert your email to pure ASCII characters. If you want to use PGP, see above. Overseas authors should make sure that their abstract prints properly on US-style 8.5x11 inch paper. Please make sure that you leave enough room for top and bottom margins. MORE INFORMATION IS AVAILABLE: Lots of papers and books have been written about how to write a good paper. We strongly suggest that you read a paper called "An Evaluation of the Ninth SOSP Submissions; or, How (and How Not) to Write a Good Systems Paper." This was written by Roy Levin and David D. Redell, the program committee co-chairs for SOSP-9, and first appeared in ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July, 1983), pages 35-40. Although SOSP and USENIX papers do differ somewhat (SOSP submissions are often more analytical), they give good advice for authors of any kind of systems paper. The authors have graciously agreed to make this paper available online in HTML, ASCII and PostScript. send advice papers in the body of your email. Another helpful paper is: "The Science of Scientific Writing", George D. Gopen and Judith A. Swan, American Scientist, Vol. 78, No. 6 (Nov-Dec, 1990), pp. 550-558. This article describes not how to write an entire paper, but how to write sentences and paragraphs that readers can understand. Unfortunately, due to copyright restrictions we cannot make this available online or send you photocopies, but almost any library should have copies of this magazine. We also recommend that you read the proceedings of some recent USENIX conferences to get an idea of what kinds of papers are published. Not every one of these papers is perfect (or even great), but most of them are better than most of the ones that got rejected. Finally, if you have any other questions, feel free to send mail to the Program Chairman at usenix98authors-request@usenix.org. Good Luck, The Program Committee

webster@usenix.org Last changed: Jul 17, 1997 jackson	USENIX 1998 Technical Conference home USENIX home