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

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

John Shriver wrote:
> C. M. Heard wrote:
> John Shriver wrote:
> > > Let me be sure that I understand your intent.  Because RFC 2578
> > > Section 7.1.1 says that the only legal values of an enumeration
> > > are those in a list, and there may be numbers in the list from
> > > the user-reserved space that may not be in the list, we should
> > > abandon any effort to provide an enumeration for any of these
> > > number spaces in any MIB for IPsec?
> > > 
> > > Instead, they should all be range-limited INTEGERS[?]
[ ... ]
> > > This strikes me as a disservice to the real customers, which are
> > > the users of any IPsec MIBs.  (RFC 2578 is not a customer.)  The
> > > entire purpose of this MIB was to eliminate those manual lookups.
> > 
> > In retrospect, it might have been better if the SMI had adopted the
> > ASN.1 rule that enumerations only specified distinguished values,
> > and that the underlying type was allowed to have all INTEGER values
> > (well, all in the range -2147483648..2147483647, since the SMI
> > restricts INTEGER to that range).  But that wasn't what was decided,
> > and the current rule is the one we have to live with.
[ ... ]
> We discussed the "standards fudge" issue of the non-enumerated values
> back [when this project was started], and people on the IPsec list
> weren't offended by the problem.  A common-sense standards bending
> didn't bother them.

The problem with bending the rules in this way is that it is
confounds expectations that people have (based on what is in
the standard) regarding what enumerated INTEGERs mean.  I put
this question to the other MIB Doctors and got these answers:

On Mon, 7 Apr 2003, Randy Presuhn wrote:
% What bothers me about this proposal is not so much the notion of
% extending enumerations without adjusting the documentation, but
% rather the semantic ambigiuities that will result due to the lack
% of coordination of the enumeration assignments.  For this kind of
% un-coordinated private use, OBJECT IDENTIFIERs are really the way
% to go.  Otherwise, one has no way of knowing whether agent A's 42
% means the same thing as agent (or manager) B's.

On Mon, 7 Apr 2003, Andy Bierman wrote:
% I agree with Randy.  If they are leaving enum values unspecified
% so vendors can assign their own value, then this is a misuse of
% enumerated INTEGER.  If enums are really the appropriate data type,
% and they know now that they want specific values defined, then
% all enum values should be listed and documented.

What the Randy's and Andy's comments are saying is that enumerated
INTEGERs are the wrong data type for this application not because of
an obscure technical violation of RFC 2578 but because this usage
violates the semantics that are expected of enumerated INTEGERs.  I
tend to agree with that, and that's why I have suggested subranged
Unsigned32 would be a more appropriate choice.

> I don't have time to dig the archives...

I looked in the ipsec archives back to 1998 and was not able to find
any discussion of this specific issue (it is entirely possible that
I missed something, in which case a pointer would be helpful). 

Thanks,

Mike Heard