Re: [Gen-art] Review: draft-ietf-bmwg-ipsec-term-12

["Joel M. Halpern" <[e-mail]>]

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

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.