1. Rating
   Rate the paper in the following categories (For each category,
   choose a one numeric rating)
 
  Technical quality
   
    5: Contents are completely correct. There are no errors.
    
  Originality
   
    3: No significantly new ideas, but good analysis of current state
   
  
  Editorial quality
  
    4: Mostly understandable, some improvements identified below
  
  Overall grade (overall, how do you rate this paper?)

    3: Good
   
  Confidence (how confident are you about this review?)
 
    1: This is a completely new subject to me; I made educated guesses


2. Detailed comments

   Provide detailed written comments on the paper.  In general, your
   main aim as a reviewer is to help improve the paper. Be as specific
   as you can when you point out errors or problems. Suggest concrete
   improvements whenever possible.

   Your review should cover the following three aspects.  Use the
   suggested guidelines in composing your review for each aspect.

  2a. Technical quality
      Give a one paragraph summary of the paper.
      Explain what are the strengths and weaknesses of the paper.  In the
       case of weaknesses suggest how they can be corrected.
      Point out any errors, and suggest how they can be corrected.
      Point out any new ideas in the paper that can be improved or further
       developed.  Suggest how.
      Does the paper provide a good survey of the state of the art?
      Point out any important missing references.

      
The paper presents a protocol analysis tool AVISPA. 

In my opinion, the paper gives rather good introduction to AVISPA
tool. The description of the HLPSL language gives good idea on how the
protocols are written for the analyzer. Still, I would have been also
interested in how the four back-ends actually work. In the paper,
these back-ends are just introduced by their name, and not what they
do. 

In the paper, two different protocols are described, that is, the Wide
Mouth Frog in HLPSL introduction and IKEv2 as the case study. Somehow
I find them to be overlapping and probably it would have been better
to write whole paper consentrating on only one protocol. 



  2b. Originality
      Does the paper claim new ideas?  How novel are they?
      How well does the paper analyze and explain the state of the art?

The paper gives nice introduction to AVISPA tool, and thus the idea of
the paper probably was not to claim new ideas.

I am not sure if there are any other toolsa, but it would have been
nice to get some pointers to other protocol analyzers with some
comparison between the different tools.

  2c. Editorial quality

      Is the paper easy to read and understand?
      Does the abstract faithfully describe the contents of the paper?
      Does the Introduction section clearly spell out the problem
       addressed and the scope?

      Can you suggest improvements in organization, and presentation that
       would improve readability and understandability?

As already mentioned, the case study of section 3 (IKEv2) could have
been used to describe the tool without first providing the language
using one protocol before going to case study.

There were quite a lot of typos and other errors, but as Jan-Erik
already listed quite a many of them, I will not do it any more :)


Good references:

This page has some helpful tips of peer-reviewing of student papers:
http://instruct1.cit.cornell.edu/courses/taresources/PR2.PDF

This paper is a classic: A Guide for New Referees in Theoretical
Computer Science.  You can use this when you do actual reviews of
conference/journal papers.
http://citeseer.ist.psu.edu/parberry89guide.html