ISAKMP - Vendor ID Payload
"Elfed T. Weaver" <weaver@hydra.dra.hmg.gb> Thu, 05 March 1998 16:19 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA24260 for ipsec-outgoing; Thu, 5 Mar 1998 11:19:11 -0500 (EST)
Message-Id: <199803051629.LAA10841@relay.hq.tis.com>
Comments: Authenticated sender is <weaver@hydra.dra.hmg.gb>
From: "Elfed T. Weaver" <weaver@hydra.dra.hmg.gb>
Organization: DERA
To: ipsec@tis.com
Date: Thu, 05 Mar 1998 16:30:16 +0000
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: ISAKMP - Vendor ID Payload
CC: wdm@epoch.ncsc.mil
X-mailer: Pegasus Mail for Win32 (v2.54)
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Is this extension to ISAKMP really necessary. It sounds to me that what it is meant to achieve can be achieved by defining a vendor specific DOI - based primarily on the Internet DOI. Having a DOI ID in, SA Payload, Notification Payload and the Delete Payload should support use of a different DOI in Phase 2 even if Phase 1 was established using the Internet DOI. Adding extra payloads at this stage in the standardisation process is only opening us up to additional delays - you can bet your bottom dollar that once you get it in the draft someone will want to change something ! If it can be worked around using another DOI ID then do that, please (personally I'm getting quite fed-up with having to read endless documents that only have minor (non-critical) tweaks in them since the last version) - Elfed **************************************************** "The views expressed above are entirely those of the writer and do not represent the views, policy or understanding of any other person or official body." Elfed T. Weaver DERA Malvern UK weaver@hydra.dra.hmg.gb ****************************************************
- ISAKMP - Vendor ID Payload Elfed T. Weaver