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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
