[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: IPSec Monitoring MIB works for IPv4 only?
>>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
Scott> Tim Jenkins wrote:
>> > > > 2) No method to specify the order of the services per >
>> bundle, since the > > normal reasonable order is assumed (see some
>> of the > previous email on > > this). > > No substantive comment,
>> though my gut reaction is that this > may bite us > later.
>>
>> This, and I've said this before, was apparently already decided
>> long ago. Dan Harkins has posted it at least twice, and further,
>> the architecture document itself says that ESP must be applied
>> before AH. This is perfectly enforcable in the context of a
>> protection suite as defined by the isakmp draft.
Scott> No, the architecture document simply does not require support
Scott> for any constructs which choose to apply AH first (for
Scott> whatever reason). I agree that the arch doc is right not to
Scott> require these, but think it's wrong to make design decisions
Scott> which preclude them.
I agree with Tim here.
It's reasonable enough to preclude things if there is no foreseeable
argument why they would become meaningful in the future, which seems
to apply here.
Even if not, there's the problem that it's hard to design in
flexibility for undefinable possible future changes. I've seen enough
examples in the past where protocols had things designed into them
anticipating features of future versions, only to discover by the time
the future version rolled around that the "forward compatibility"
hacks were in fact wrong and did not help, actually made things more
complicated. (Look at DECnet phase 4 for an example... :-( )
I will happily join in complaints when the MIB proposal doesn't
adequately cover things that ARE currently allowed, but for the sake
of making good progress I'd be happy to have it not support things
that aren't currently allowed, don't make sense, and probably never
will.
paul
References: