[bmwg] draft-ietf-bmwg-ipsec-term-03.txt
"Hickman, Brooks" <brooks.hickman@spirentcom.com> Thu, 29 April 2004 19:13 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21051 for <bmwg-archive@lists.ietf.org>; Thu, 29 Apr 2004 15:13:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGhG-0003ny-B0; Thu, 29 Apr 2004 14:55:46 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJFfg-0006rj-L1 for bmwg@optimus.ietf.org; Thu, 29 Apr 2004 13:50:04 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16518 for <bmwg@ietf.org>; Thu, 29 Apr 2004 13:50:02 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJFfa-0006xC-VL for bmwg@ietf.org; Thu, 29 Apr 2004 13:49:59 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJFeS-0006b8-00 for bmwg@ietf.org; Thu, 29 Apr 2004 13:48:48 -0400
Received: from smtp.spirentcom.com ([199.1.46.14] helo=exch-connector.netcomsystems.com) by ietf-mx with esmtp (Exim 4.12) id 1BJFdk-0006Dn-00 for bmwg@ietf.org; Thu, 29 Apr 2004 13:48:04 -0400
Received: by exch-connector.netcomsystems.com with Internet Mail Service (5.5.2655.55) id <H54R7V9W>; Thu, 29 Apr 2004 10:47:37 -0700
Message-ID: <629E717C12A8694A88FAA6BEF9FFCD4405779FBD@brigadoon.spirentcom.com>
From: "Hickman, Brooks" <brooks.hickman@spirentcom.com>
To: "'bmwg@ietf.org'" <bmwg@ietf.org>
Date: Thu, 29 Apr 2004 10:47:35 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [bmwg] draft-ietf-bmwg-ipsec-term-03.txt
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
I have been reading over the IPSec Terminology document and have a few comments/suggestions. I am by no means an expert on IPSec, so if I am mistaken on any on the items below, please let me know. 7.7.1 IKE Tunnel Definition: One simplex Phase 1 IKE SA The definition states "One simplex Phase 1 IKE SA". I thought that Phase 1 tunnels are always bi-directional. The term "simplex" in the definition implies one direction. Would suggest removing the word simplex from the definition. 7.7.3 Tunnel Issues: If only a single Phase 2 SA or more then two Phase 2 SA's have been negotiated through a single IKE Tunnel, then this specific ratio must be mentioned and the term 'Tunnel' MUST NOT be used in this context. If I am not mistaken, I believe the verbiage is to cover the case where anything other than one IPSec Tunnel is configured for each direction. If so, what if I have two Phase 2 SA's configured in the same direction. I could use the term "Tunnel" in this case. Also, should the first occurrence of "must" in the sentence be upper case or lower case? Suggest something along the lines of: If other than a single Phase 2 SA, for each direction, have been negotiated through a single IKE Tunnel, then this specific ratio MUST be mentioned and the term 'Tunnel' MUST NOT be used in this context." 7.7.3 Active Tunnel Definition: A tunnel that has completed Phase 1 and Phase 2 SA negotiations and is transmitting data. Suggest: "A tunnel that has completed Phase 1 and Phase 2 SA negotiations and is forwarding data." 10.3.2 IPSec Tunnel Encryption Frame Loss Rate 10.3.3 IPSec Tunnel Decryption Frame Loss Rate Both the definition and unit of measurement in sections 10.3.2 and 10.3.3 are terms of a percentage, not a rate. The unit of measurement is not "n packets/second". While I realize that this is basically carrying over the term defined in RFC1242(Section 3.6), I think that the rate should be dropped from the term in both cases. In addition, were there any plans to add tunnel(Phase I and Phase 2) establishment time to the terminology document. _______________________________________________ bmwg mailing list bmwg@ietf.org https://www1.ietf.org/mailman/listinfo/bmwg
- [bmwg] draft-ietf-bmwg-ipsec-term-03.txt Hickman, Brooks
- Re: [bmwg] draft-ietf-bmwg-ipsec-term-03.txt Tim Van Herck