Check out the new USENIX Web site. USENIX - How to Submit

Please read this message carefully. It is written to help you give your submission its best possible chance of being accepted. As you know, the Program Committee cannot accept every paper submitted to the conference.

Generally speaking, we are looking for papers that span a broad range of practical issues in network administration. However, please don't choose not to submit your paper because you think that it will not "fit" the conference format. Some of the best papers are those that are unusual and definitely not "traditional."

The key element of a good paper is that it provides the reader with clear and concise information that can be used for network management or during the development of a tool to help perform related tasks.


The Network Administration Conference will be held in Santa Clara, California, April 7-9, 1999. The technical sessions will be held Thursday and Friday, April 8-9.

Dates for paper submissions:
  • Submissions Proposals Due: November 6, 1998
  • Notification to authors: December 1, 1998
  • Camera-ready final papers due: February 23, 1999


Authors of an accepted paper must provide a final paper for publication in the conference proceedings. At least one author of each accepted paper will present the paper during the technical track of the conference. These presentations generally include a 20 minutes talk with five to ten minutes of questions from the audience. We also ask that, if possible, copies of presentation slides be made available for publication.

Conference proceedings containing all accepted papers will be distributed to attendees and, following the conference, will be available online to USENIX members and for purchase from USENIX.

Note that USENIX conferences, like most conferences and journals, requires that papers not be submitted simultaneously to more than one conference or publication and that submitted papers not be previously or subsequently published elsewhere. Papers accompanied by so-called "non-disclosure agreement" forms are not acceptable and will be returned to the author(s) unread. All submissions are held in the highest confidentiality prior to publication in the Proceedings, both as a matter of policy and in accord with the U.S. Copyright Act of 1976 (Title 17, U.S. Code, Section 102).


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 works; it may be good work but if there is nothing new to learn, it isn't worth reading (or writing) a 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.

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 favour papers where the author appears to be familiar with the current literature.

The Program Committee will also be trying to decide if papers will lead to a good 25-minute presentation. Some papers 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.


An "abstract" might better be thought of as a "condensed paper." The Program Committee will be trying to evaluate your final paper, not merely whether the work you are reporting on is good. This means that we will view the abstract as a sample of your ability to write clearly about your topic, to organize your paper, and to convey sufficient information to the readers.

When you write an abstract, you are explicitly leaving things out of the paper without making it hard for the program committee to judge the paper. Don't leave out references to related work, but you can probably reduce this part to an explanation pitched to the program committee, rather than an "introduction to the field" written for the benefit of a non-expert reader. Include graphs, figures, and tables that are central to understanding the paper!

Also, it's perfectly okay to write notes to the Program Committee in your abstract! Tell them why you left something out, if a section may be fundamentally changed in the final paper, or similar comments that will help them better understand your abstract.

A conventional abstract is typically one paragraph. An extended abstract is usually five to 10 paragraphs. It should have the same basic structure of the final paper, but not all the information. Some sections may be omitted (such as previous work). The extended abstract should meet these objectives: a representative sample of the authors' writing, a summary of the work to be presented, sufficient detail to convince the committee that the work has substance and merit.

Finally, if a sample abstract would help, you can get a copy of the (extended) abstract and postscript copy of the final paper that Matt Blaze did for the Winter 1992 USENIX conference (pp. 333-343). The abstract is probably most useful when compared with the final paper.

You can also view a copy of the final paper


  • Please e-mail your submission in one of the following formats:

    • plain text with no extra markup
    • PostScript formatted for 8.5" x 11" page
    • Microsoft Word
    • RTF
    • HTML
  • A cover letter with the following required information in the format below must be included with all submissions:

    • Authors: Names and affiliation of all authors
    • Contact: Primary contact for the submission
    • Address: Contact's full postal address
    • Phone: Contact's telephone number
    • Fax: Contact's fax number
    • E-mail: Contact's e-mail address
    • URL: For all speaker/authors (if available)
    • Category: Category of the submission (paper, invited talk, panel, WIP)
    • Title: Title of the submission
    • Needs: Audio-visual requirements for presentation

  • If you enclose files as an attachment to your submission, please use MIME encoding.
  • We will acknowledge receipt of a submission by e-mail within one week.


Lots of papers and books have been written about how to write a good paper. We'd like to 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. The authors have graciously agreed to make this paper available online.

Although SOSP and USENIX papers do differ somewhat (SOSP submissions are often more theoretical, and are reviewed based on full papers rather than abstracts), they give good advice for authors of any kind of systems paper.

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 Chairs

Good Luck,

The NETA Program Committee

?Need help? Use our Contacts page.
First posted: October 22, 1998 tv
Last changed: October 23, 1998 ah
Conference Index
Events Calendar