Date: Tue, 6 Aug 1996 13:59:56 -0400
From: John Kohl <jtk@atria.com>
Message-Id: <9608061759.AA02779@mango>
To: eichin@cygnus.com, jtk@atria.com
Subject: 1997 USENIX Paper Submission
Lines: 276
Xref: maneki-neko.cygnus.com mail.personal:2741

This note mechanically notifies you of the status of your submission to
the 1997 USENIX Conference.  It was generated by a program.

We have reviewed your paper (our number 037) with the title:

Autoconf for large scale portability: Kerberos V5, a case study

and regret to inform you that the committee did not accept your paper
for this year's conference.  We received 70 submissions and accepted
only 23 of them; thus, we inevitably had to reject a number
of papers that we found interesting or well-written.

Below are some (anonymous) comments about your abstract from the referees.
We hope you will consider the comments and submit another paper or abstract
to another USENIX conference or workshop, or perhaps to another
conference or publication that might be more suitable for your paper.
You might also consider presenting your ideas at a works-in-progress
(WIP) session at Anaheim.  If you're interested, contact the WIP coordinator,
Bob Gray <wips97@usenix.org>.

One reviewer noted:

        Summary:  Your paper is very hard to read.  Perhaps it is just 
        a first draft.  If so, it needs lots of grammatical checks and
        consistency checks.  It also needs many more concrete examples
        of autoconf and imake features, descriptions of what these tools
        are, a better Abstract and it definitely needs some references!

        The title is confusing.  The paper really has nothing to do with
        Kerberos.  The paper just uses the Kerberos source tree as a big
        case study.  Perhaps "Autoconf for Large Scale Portablility: A
        Case Study" would be clearer.  Also, titles should have each
        word capitalized.

        Global comment:  Section and Subsection headers should be
        consistently capitalized or not capitalized.

        Global comment: You reference HP/UX, Solaris (Sun), Vax BSD and
        other products.  You never give credit to the companies.  I
        don't know if this can be done by simply saying that the
        trademarks are of these companies, or if it can be done by
        including references.

        Global comment:  You should have a section which describes each
        of Kerberos V5 source tree, imake and autoconf.  

        Global comment:  If a section has only 1 subsection, then there
        should NOT be as subsection.  That is a subsection 1 must have
        a subsection 2, or more, with it!!!

        You MUST have a reference section and use these references where
        appropriate throughout your paper. 

        Be consistent in how you refer to Kerberos V5.  Sometimes you
        call it V5, sometimes Kerberos, sometimes Kerberos V5.

        The last sentence in the abstract is not correct grammatically.
        The abstract, in general, is not clear.  It states the goals and
        conclusions, but should also indicate what Kerberos, Imake and 
        autoconf are.

        Section 1.1: It's called Imake Problems, but the first
        subsection is called "where imake succedes".  This is
        contradictory.  Throughout your paper the section headers do not
        clearly summarize what is to follow in the text.

        Section 1.2:  It's called autoconf advantages.  You may want to 
        call secton 1.1 "Imake Pros and Cons" and section 1.2 "Autoconf
        Pros and Cons"

        Section 1.1 and 1.2 should have similar sub section style.  That
        is, in one you have a succedes and a fails subsection with
        bolded paragraph headers.  In the next you have random
        subsections.

        Section 1.2.1: The last sentence is not clear to me (not the one
        in parentheses).  I cannot tell if the scripts create Makefiles
        or what they do...  Here's where a better description of
        autoconf would have helped.

        Section 1.2.2: It's called "Feature testing - enhancing
        portability of code.  The section doesn't say HOW it does
        this!!!  Also, the first sentence of this section says "The
        primary appeal of autoconf..."  Who say's it's the primary.
        That is, this is an awfully strong statement that is not
        supported by any proof!

        Section 1.2.3:  comments like [does it?] should not be in your 
        paper.  YOU should find out the answers!

        Section 1.2.4 is very awkward.

        Section 2.1:  In parentheses you say "We can confirm this..."  If 
        so, you should PROVE IT.

        Section 2.2.1 second paragraph.  I don't understand what you
        want to change in the future.  Also, in the last paragraph of
        this section, I don't know what this has to do with anything!

        Section 2.3.2:  Huh?  Title and text don't seem to agree.

        Section 2.3.3:  what's FSF?

        Section 3.1:  You should indicate what you mean by a "style guide"
        since some people have differing meanings of what a style guide is.

        Section 3.2:  Needs lots of work.

        Section 6.3:  Does your question (?) after the word "work" mean
        that they might not work?

        Section 6.6: First paragraph referes to Training Trainers
        fallacy.  What's this????

        Section 6.7:  Why are the first two paragraphs bolded and then 
        there is a section 6.7.1.  Also why is there a 6.7.1 without a 
        section 6.7.2?  And, get rid of comments like "like ken did to
        clients".

        Section 8: Last sentence: consider going back to what???  Also,
        by this conclusion, I get the feeling that imake does some
        things better than autoconf.  Does it?  if so, the paper should
        indicate this more clearly.

Another reviewer noted:

	I think this work is of interest to a reasonable enough portion
	of the community to consider accepting it.

	The abstract does its job, although it could be a bit longer and
	more complete.

	There are no references, and very few are alluded to in the
	text.

	The usage and grammar is weak: There is inconsistent use of
	"feature test" v. "feature-test," incorrect use of ellipses, at
	least one made-up word ("autoconfiscation"), and too many
	sentences that end with prepositions. Also, incorrect use is
	made of bold-face type, and the use of capitals is incorrect.

	The order of sections is somewhat confusing: The paper jumps
	from problems with the old system, to advantages of the new
	system, to future issues, to a definition of the problem
	(portability) and why the problem is important, to what was
	done, to lessons learned, to alternative solutions, and last, to
	three seemingly-unrelated paragraphs. A better order is needed,
	although an easily-described one doesn't spring to mind.

	There are two "unresolved" references: In 6.7, 2nd paragraph,
	the paper refers to "ken"; who or what is "ken"? If the answer
	is "Ken Thompson," the reference isn't clear, and the whole name
	should be used. Then, in 7.2, 3rd paragraph, the acronym "CNS"
	appears: Should this be "CVS"? Either way, the acronym should be
	expanded. (If this was done earlier, I missed it.)

	The goals of this paper are fine: It's a case study, and it does
	what case studies are supposed to do (describe what was done,
	and what was learned from the experience).

	In order to recommend that this paper be accepted, all of the
	"complaints" noted above would need to be corrected.


Another reviewer noted:

	- The paper is concise -- but also terse.  One might assume that
	  the terseness is a result of being a draft, but for the final
	  version the terseness leaves one with the feeling that important
	  information is being discarded casually.  For example, there
	  are no examples or samples that illustrate the points made in the
	  prose.  There are phrases that look like notes to the author, etc.
	- Presumably the final draft would include a) references, and b)
	  completion of items such as those discussed above.

Another reviewer noted:

	The abstract does not clearly state the purpose of the paper.
	In section 1, you need to include a description of Imake and
	autoconf (with references).  Section 2 (experiences), is very
	weak.  What other options were considered?  Why were they
	rejected?  What *exactly* did you do?  The organization of the
	paper does not make it easy for the reader to understand what
	was done and why.  You might like to follow a process of:
		- what problem was I trying to solve 
		- what options were available and considered 
		- what option was chosen and why 
		- what was done for the implementation 
		- what could have been done better 
		- what are the plans for the future 
		- how this could be used for other projects
		- conclusion

Another reviewer noted:

	This paper is weak for a Usenix Conference, the depth of
	coverage and writing is shallow and the grammar and formatting
	has many errors.

	The paper really has very little to say about Kerberos V5 and I
	think "Kerberos" should be removed from the title.

	There are no references provided although the body of the paper
	does have reference numbers.  Some references are just left as
	"ref?".

	The Abstract does not say what the paper will really cover.

	The headings are poorly formatted with incorrect capitalization
	etc.  This includes but is not limited to Headings under section
	2.  Note heading 2 (experience) is not capitalized nor is 2.1
	(what worked) but 2.2 (Surprise Advantages) is.

	The body of the paper includes several questions implying the
	paper is incomplete.  For example the final sentence of section
	1.2.3 reads "if Solaris 2.5 fixes the problem [does it?.] then
	the test....."  there were several more examples of this.

	Finally my general impression was that the depth of coverage and
	writing was somewhat shallow.  The grammar is of mediocre
	writing and this paper is incomplete.

Another reviewer noted:

	Well, I like autoconf a lot, but I hate case studies and
	comparison papers.  If this paper is accepted it needs some
	heavy handed editing to clearly present the information.
	Writing a paper using outlines is great, but you don't need
	to show them all in the paper.


Another reviewer noted:

	Case studies can be interesting and can make great papers, but
	only if they tell you something surprising and put the
	experience into some context that supports some coherent story.
	This paper doesn't do this, and it was hard to fill in the
	details to understand whether such a story even exists here.


During the program committee discussion, the following points were noted:

  
    	There's something good in here (maybe) but the paper doesn't
    	capture it well.
  
  	The useful information here deserves to be disseminated, but
  	USENIX is not quite the right venue.
  
  	We strongly encourage you to turn this into a tutorial document,
  	white paper, and/or or offer to FSF to put this into their
  	documentation.
  
  	It would also fit nicely into the USENIX newsletter ";login:".
  	Contact the editor at <login@usenix.org> if you wish to submit
  	to ;login:.
  
    	This might be good at LISA as a half-day tutorial?
  

Thank you again for your submission.  Please contact me if you have
any questions.

We hope to see you in Anaheim!

				Your program committee chair,
					John Kohl


					Atria Software, Inc.
					+1 (617) 676-2641
					jtk@atria.com