[IPsec] Terminology issue (minor)
shore@arsc.edu Mon, 22 March 2010 16:44 UTC
Return-Path: <shore@arsc.edu>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AD333A69C2 for <ipsec@core3.amsl.com>; Mon, 22 Mar 2010 09:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.689
X-Spam-Level:
X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[AWL=-2.441, BAYES_80=2, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3v8j6krx3snv for <ipsec@core3.amsl.com>; Mon, 22 Mar 2010 09:44:08 -0700 (PDT)
Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id B9C103A691D for <ipsec@ietf.org>; Mon, 22 Mar 2010 09:44:06 -0700 (PDT)
Received: from webmail.arsc.edu (web4.arsc.edu [199.165.84.246]) by arsc.edu (20090828.ARSC) with ESMTP id o2MGiF3V003888 for <ipsec@ietf.org>; Mon, 22 Mar 2010 08:44:15 -0800 (AKDT)
Received: from 2001:df8:0:24:225:d3ff:fed5:7b05 by webmail.arsc.edu with HTTP; Mon, 22 Mar 2010 08:44:15 -0800 (ADT)
Message-ID: <2f9f601123df0c8467eab4a5e9fed14b.squirrel@webmail.arsc.edu>
Date: Mon, 22 Mar 2010 08:44:15 -0800
From: shore@arsc.edu
To: ipsec@ietf.org
User-Agent: SquirrelMail/1.4.17
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-CanIt-Geo: ip=199.165.84.246; country=US; region=AK; city=Fairbanks; postalcode=99775; latitude=64.8834; longitude=-147.4984; metrocode=745; areacode=907; http://maps.google.com/maps?q=64.8834,-147.4984&z=6
X-CanItPRO-Stream: default
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 199.165.84.167
Subject: [IPsec] Terminology issue (minor)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Mar 2010 16:44:23 -0000
This is probably a small thing, but in general the term "cluster" implies at least some degree of shared state among cluster members. I understand that there's some suggestion of that in saying that a cluster protects the same domain but there's really quite a bit more to it than that - it's going to things like the SADB or a subset of the SADB. It needn't be in real-time or near real-time, but it has to be there for it to be considered a cluster (rather than, say, multi-homing). I don't think including that in the definition requires that the wg take on state synchronization among cluster members. Melinda