Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

["C. M. Heard" <heard@pobox.com>]

On Mon, 7 Apr 2003, Randy Presuhn wrote:
> I get the feeling that the registry policy descriptions aren't
> as clearly separated from the TC semantics as they should be.

That's certainly true for IsakmpExchangeType/IkeExchangeType
(which probably should be called IPsecDoiExchangeType) and
for IsakmpNotifyMessageType/IkeNotifyMessageType, and I have
generated some comments asking that this be fixed up in the
DESCRIPTION clauses.

> For example, part of the IkeExchangeType range is spelled out in
> the TC definition, but the meanings of another part of that
> range is "private use" , and of another part of the range "for
> the IPsec DOI used by IKE."  The former is actually small enough
> that it would be reasonable to document each as "privateUseN (N)".

True, but there are other cases where the private use ranges are
65001..65535, 61440..65535, and 32768..65535 (this seems to vary
according to which RFC defined the item in quesion).  For those
cases the strategy of listing everything isn't very practical.

> The latter can be read either as a description of registry
> policy, or as the definition of a bunch of values that can only
> be interpreted in "the IPsec DOI used by IKE" context, which
> would suggest that one would need an additional object or other
> information to make sense of an object defined using this TC.

It's supposed to reflect registry policy.  The DOI [Domain of
Interpretation] -independent stuff is supposed to exist in
IsakmpExchangeType (and IsakmpNotifyMessageType), and for each
DOI there is supposed to be an extension TC that contains both
the DOI-independent enumerations and the DOI-specific ones.
The latter are to be allocated from the DOI-specific range.

This business of having to "clone" the "base" TC in these cases
is another reason to view enumerated INTEGERs with disfavor for
this application.

Mike