[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: ISAKMP Version
> 1. The distinction of Major Version and Minor Version is not clear from the
> document. Why isn't there just a Version ? (In particular how should the
> future processing of minor version differ from the future processing of
> major version when there are multiple versions? I usually like to provide
> for future probable evolution paths and the fact that you have made this
> distinction seems to imply you have something in mind that isn't explicitly
> stated.)
There is no pre-planned use for the minor version numbers. They can be
useful, they can also go unused. Future use of them will be determined
when we come up with an incompatible change to make.
Nonetheless, your point is valid that their use is ambiguous. We should
define for now that an implementation should never accept packets with a
major OR minor number that is larger than it's own. As for accepting ones
that are smaller, that will be defined as those changes are made.
One motivation for the distinction between major and minor version is that
the old 4 bit version number just happens to occupy the same four bits as
the current major version number. So if previous implementations of ISAKMP
receive the current packets, they can easily tell they are the wrong
version. Same thing when going the other way as well.
> 2. If versioning is useful in ISAKMP itself it would appear to be at least
> as useful at the DOI level (which I would guess would be subject to more
> frequent change than is ISAKMP itself). Certainly our application
> envisions an evolving DOI with provision for some level of backward
> compatibility.
Good thought. I'll have to ponder this a bit more...
Dave
References: