Re: response to Last Call on: IP Authentication using Key
"Housley, Russ" <housley@spyrus.com> Mon, 03 July 1995 16:28 UTC
Received: from interlock.ans.net by ftp.ans.net with SMTP id AA04991 (5.65c/IDA-1.4.4 for <archive-ipsec@ftp.ans.net>); Mon, 3 Jul 1995 12:28:45 -0400
Received: by interlock.ans.net id AA25537 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 3 Jul 1995 12:11:57 -0400
Message-Id: <199507031611.AA25537@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-3); Mon, 3 Jul 1995 12:11:57 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 3 Jul 1995 12:11:57 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 3 Jul 1995 12:11:57 -0400
Date: Mon, 03 Jul 1995 08:58:44 -0000
From: "Housley, Russ" <housley@spyrus.com>
Encoding: 807 Text
Cc: ipsec@ans.net
Subject: Re: response to Last Call on: IP Authentication using Key
>> Now that it may finally be on the table to do something about >> draft-ietf-ipsec-ah-md5-03.txt >> I would like to remind this community that not only >> should the MAC be defined independent of >> its intended use, so too should the encryption transform. > > More properly, you should state that it is your opinion that the > transforms should be independant of use. There are many advantages to a protocol specifiation that is independent of mechanism and a separate mechanism description. One iportnat benefit is that other IETF groups can use the same mechanism description in the same way that Hugo's I-D references the MD5 RFC. Good modularity in the specifications saves alot of time and effort down the road. And, it makes specification maintenence easier too. Russ
- Re: response to Last Call on: IP Authentication u… Housley, Russ