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

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

On Mon, 7 Apr 2003, Andy Bierman wrote:
> At 04:00 PM 4/7/2003 -0700, Randy Presuhn wrote:
> >Hi -
> >
> >> From: "C. M. Heard" <heard@pobox.com>
> >> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> >> Sent: Monday, April 07, 2003 3:18 PM
> >> Subject: FW: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt
> >...
> >> Here is one I had not encountered before:  folks who want to define
> >> enumerated INTEGER objects that are allowed to assume values that
> >> are not in the enumeration list.  Technically this is not legal (cf.
> >> RFC 2578 Section 7.1.1).  Practically, it does not seem that it
> >> should cause much harm, since enumerated INTEGERS can be extended by
> >> having more enumerations added.  In view of this, is the rule
> >> against assuming values other than the ones specifically enumerated
> >> just another crummy little rule that should not be enforced?  This
> >> would amount to treating enumerated INTEGER like ASN.1 does (i.e.,
> >> the enumerations are just distinguished values, but in no way
> >> constrain what values may be assumed).
> >>
> >> Opinions?
> >...
> >
> >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.
> 
> 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.

The semantic ambiguity in this case is inherent in the data that
they are trying to represent, which are the values of certain fields
in the IPsec-related protocols.  Those fields have some ranges of
values reserved for registered values and other ranges reserved "for
private use between concenting parties".

What the Randy's and Andy's comments are saying -- if I understand
them correctly -- is that enumerated INTEGERs are not the right way
to represent such data, not because of some technical violation of
RFC 2578, but because such usage violates the semantics that are
commonly expected of enumerated INTEGERs.  I tend to agree with
that, and have suggested to the MIB author that a subranged
Unsigned32 would be a more appropriate choice.

On Tue, 8 Apr 2003, Wijnen, Bert (Bert) wrote:
> So if we do allow this, then why are we so hard on ourselves
> when some labels are added in the sense that we then require 
> a new MODULE-COMPLIANCE and to make sure that the old one
> only lists the labels that existed originally?
> 
> Or would we accept the proposal below and then require that
> the MODULE-COMPLIANCE (but here they only do TCs, so we
> would have to keep an eye on it later) would only REQUIRE
> the enumerated values?
> 
> Just thinking aloud here

The problem that an extension to a TC could cause with a compliance
statement is to silently change the meaning with respect to what
values an agent implementation has to support.  As far as I can
tell, that's an issue only for read-write or read-create objects or
index objects in read-create tables, because the manager can select
the values for such objects.  For read-only objects the agent
decides what to return;  the only compliance issue is whether the
object is implemented or not.  So we don't need to be so careful in
that case.  That's why the IF-MIB compliance statements don't need
an OBJECT clause for ifType, even though IANAIfType is an extensible
enumeration.  On the other hand, we've made a big deal of this with
regards to InetAddressType objects precisely because some of those
are writeable.

Currently, the only objects defined using the TCs in this draft are
read-only, so this is not an issue yet.  But it could be later on.

//cmh