Re: WG last call for IPv4 AH and ESP

"marcus (m.d.) leech" <mleech@bnr.ca> Wed, 22 February 1995 01:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13366; 21 Feb 95 20:14 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa13362; 21 Feb 95 20:14 EST
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa19860; 21 Feb 95 20:14 EST
Received: by interlock.ans.net id AA03017 (InterLock SMTP Gateway 1.1 for ipsec-out@ans.net); Tue, 21 Feb 1995 20:02:58 -0500
Received: by interlock.ans.net (Internal Mail Agent-5); Tue, 21 Feb 1995 20:02:58 -0500
X400-Received: by interlock.ans.net (Internal Mail Agent-4); Tue, 21 Feb 1995 20:02:58 -0500
X400-Received: by interlock.ans.net (Internal Mail Agent-3); Tue, 21 Feb 1995 20:02:58 -0500
X400-Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 21 Feb 1995 20:02:58 -0500
X400-Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 21 Feb 1995 20:02:58 -0500
Date: Tue, 21 Feb 1995 20:02:11 -0500
X400-Originator: mleech@bcarh6dc.ott.bnr.ca
X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; bcars520.b.343:22.01.95.01.02.11]
X400-Content-Type: P2-1984 (2)
Content-Identifier: Re: WG last c...
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "marcus (m.d.) leech" <mleech@bnr.ca>
Message-Id: <"25349 Tue Feb 21 20:02:14 1995"@bnr.ca>
To: PIPER@bilbo.tgv.com
Cc: ipsec@ans.net
In-Reply-To: <01HNBDX8JX3I00002N@BILBO.TGV.COM>
Subject: Re: WG last call for IPv4 AH and ESP
Organization: Bell-Northern Research, Information Technology Division
X-Mailer: ELM [version 2.4 PL21]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1498

-----BEGIN PGP SIGNED MESSAGE-----

> I agree with this.  I'd like to make sure that in-band keys are possible.
> 
> Derrell
> 
> 
I'd like to put in my two-cents worth for avoiding further complication
  in the existing drafts.

At the neither the Toronto, nor the
  San Jose meetings, did this issue come up.  I have been under the
  assumption that there was an implicit understanding that a key-management
  protocol would eventually emerge, and that the "encapsulation" drafts
  should proceed with that assumption.  I think that we would be doing
  a great dis-service to an already very-late process to introduce
  further complications like in-band key change to a pair of proposals
  that are seeming to solidify very rapidly.

The beauty of the existing drafts (AH and ESP) is that they can operate
  in either a manual or automatically-managed key management environment.
  This is, in my opinion, a great step forward.  I'm getting frustrated
  watching this process get derailed, frequently, by what to the casual
  observer seems like creeping featurism...

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQBVAwUBL0qNCKp9EtiCAjydAQF9ZAIAg9hab+1AAt5C08U2ycntvTPZ4kSiQZJO
J3fbUNpAQt6eQhWJQvpIgesLT+xVl7GYHJ2n8vdYYhipjcd4OVwm/g==
=EcgT
-----END PGP SIGNATURE-----

--
Marcus Leech        |Any opinions expressed are mine.         |+1 613 763 9145
VE3MDL              | and not those of my employer            |+1 613 567 5484
mleech@bnr.ca       |                                         |