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