Re: "Transforms" per se going away?

[Stephen Kent <[e-mail]>]

Dan,

	I don't think my intent has been to move to exactly the "list"
approach you describe in your message.  For example, not all combinations
of encryption algorithms, modes, and IV options make sense.   I was
assuming that we would have a regsitered set (with the IANA) of
combinations of encryption, authentication, and anti-replay options, each
set of which defines a "transform" (using the curent terminology).  This
makes clear to implementors what combinations must be supported and allows
for elimination of combinations that the community (WG?) thinks are
inappropriate, i.e., don't allocate a transform ID for a combination that
is considered "bad."  The real goals of the new AH and ESP specs are to
eliminate the need to issue a combinatorial number of transform RFCs, to
centralize common definitions, etc.  One can still have a fairly modular
implementation as you describe, but by grouping the attributes of
transforms, one also can accommodate less modular implementations as well.

Steve