Document: draft-ietf-bmwg-ipsec-term-12
    Terminology for Benchmarking IPsec Devices
Reviewer: Joel M. Halpern
Review Date: 16-Oct-2009
IESG Telechat date: 22 Oct 2009

Summary: This document is almost ready for publication as an 
Informational RFC.

Major issues: -
Minor issues:
    In section 3.1.1, where Security Association is information defined 
the text reads "An SA is a relationship between two or more entities ..."  
But, section 7.4 which formally defines "Security Association" it says 
"It is a negotation agreement between two IPsec devices ..."  Is it 
always two (in which case why the "or more" in section 3.1.1), or can 
there be more?  And is it always a "negotiation agreement"?  (The earlier 
text talked about manual provisioning of SAs.)

    In section 10.2 on throughput, the throughput measurement is 
defined in terms of packets per second.  This is probably the 
dominant factor.  However, some implementations may well be limited 
by cryptographic block processing, and therefore have different packet 
processing performance for different ranges of packet sizes.  
Section 10.2 should say something about the assumptions or requirements 
relative to packet size.  I think this is important enough that it 
should not be assumed that readers will understand this from the 
reference to RFC 1242.

Nits/editorial comments:
    The document is missing the IANA considerations placeholder.
    There seem to be a number of references that are missing.  (while 
idnits catches these, it requires care as if also catches some 
non-errors.  RFC1962 is an example of the problem.)

    The "Issue" in section 7.5 looks like a reasonable issue, but 
it appears to have nothing to do with selectors, the subject of 7.5.

    The definitions in section 7.7.3  and 7.7.4 define the terms 
"Established Tunnel" and "Active Tunnel" and defines them as 
"An IPsec device ...".  The other tunnel definitions are in terms 
of the association.  It is quite jarring to see a device referred 
to as a tunnel.  Are these terms supposed to be Tunnel Endpoints?

    The definition of 7.10.1 describes the properties of AH, but 
does not actually say what it is.  Instead of starting "Provides", 
it probably should start something like "A protocol header which 
provides".

A similar comment applies to 7.10.2 on ESP.