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

[Wes Hardaker <hardaker@tislabs.com>]

>>>>> On Thu, 17 Apr 2003 11:03:01 -0700 (PDT), "C. M. Heard" <heard@pobox.com> said:

W> ii) Enabling automated parsing of the MIB so that automatic
W> translations can be used where possible by management
W> applications.  This, in my opinion, is the biggest win for using
W> an enumerated TC.

C> I can easily understand how this is useful in a MIB browser whose
C> understanding of the underlying data is limited to what it can parse
C> from the MIB module.

Many such browsers exist, yes.

C> I have more trouble understanding how it helps very much for a more
C> sophisticated application that has built-in knowledge of the
C> underlying MIB objects.  This is especially true, I should think,
C> of a configuration application, such as might be built on top of
C> the IPSEC-POLICY-MIB module.

There are both smart and generic tools, yes.  Smart tools will likely
display more information than the generic ones, as they will be
preprogrammed with additional information (eg, more humanly
understandable text to supplement or replace the enum labels).  They
will still benefit, however, from enum labels when the standard has
advanced faster than the installed software base.  Smart tools should
use better text when possible, enum labels when updated MIBs are
available but updated software is not, and finally generic numeric
values when all else fails.  This is true for both monitoring and for
configuration, IMHO.  (and specifically, don't forget that monitoring
and display of configuration data is also useful so just because a
variable is read-create or read-write doesn't mean you'll never do a
GET or GETNEXT on it).  Finally, generic tools will likely have only
labels to deal with and/or raw numbers.

...
C> idDerAsn1Dn(9),     -- the binary DER encoding of
C> -- ASN1 X.500
C> -- DistinguishedName
C> idDerAsn1Gn(10),    -- the binary DER encoding of
C> -- ASN1 X.500 GeneralName
...
C> I can easily believe that the enum label might appear in a drop-down
C> box or the like, and that would be nice.  But, it's clearly not
C> enough if you want to provide meaningful help text.
...

Everything you said in the deleted portions makes perfect sense.
Smart applications need more information to display better help text
for the user.  It must get this from comments, description clauses and
programmer knowledge.  I agree absolutely.  What I disagree with is
that smart tools will never need to be updated (or that they'll be
updated at the same time as the MIBs) and that we never need to worry
about generic tools.  I write both.  I'd prefer an enum list for both
sets of my tools.

C> The subranged Unsigned32 lacks the labels for the assignments, but
C> it at least has the proper range limits.  One could argue that this
C> is even more important to have than the enum labels.

This is a definite trade off here.  You can't have both an enum list
and a range list.  An over-site of SMIv2 that is a technical challenge
because parsers would actually break if we use both.  You could argue
that ranges are more important, but I'd argue against it.
Specifically, I'd put the ranges in the description clause (which even
generic tools can display for the end user) but use enums so those
pretty drop down lists can be auto-built when possible (and the smart
tools can use it as a double check).

W> B) The problem is that the IPsec protocols have various places where
W> an integer is used on-the-wire with a "range" of standardized
W> values that do not fall into the maximum allow within the coding
W> of the packet itself.

C> I'm not sure what you mean by this.  The range of "standardized"
C> values is always a subset of that can be coded in the packet.

I think we said the same thing.  In different ways.

C> The problem, rather, is that the enumerated INTEGER SYNTAX is not
C> (according to SMI rules and user expectations) consistent with such
C> a description.

I still can't find a technical argument (and maybe I'm just missing
it) why it's a problem.  What will application will break if a agent
returns a value outside the assigned enum list?  None, since they all
have to deal with outside values now.  What agent will break when a
manager tries to set a value to an agent that it doesn't support?
None, since they must all deal with this anyway.  In fact, the
agent that receives a value outside the legal range of values will
already have to return the exact same error to the management app that
sent an illegal value in the first place.

C> I think I've at least partly answered the arguments about the loss
C> of functionality (i.e. that it's not as much as it appears to be
C> for applications that have built-in MIB knowledge).

Final question: You keep coming back to this.  Does this mean that
there is no use for TCs of enums?  IE, why do we have machine-readable
enums in the first place if if all applications must have built in
knowledge?  It seems your trying to make a point that applications
must have built-in MIB knowledge, in which case we never need
machine-readable enums in the first place?

C> The extra burden on IANA is a very real concern, and when I started
C> the review of this MIB module most of the comments I wrote were
C> related to changes that I thought would be necessary in order to
C> make that tractable.

If that is the reason you want to oppose the use of enums, then it
is a more understandable argument from my eyes at least.
Unfortunately, there is still functionality lost if this is the case.
Does it mean we should never create enums in MIBs when it is supposed
to match another standards document?  We should always use references
and no real values (in enums, description clauses or comments) in that
case?

I would argue that the administrative burden isn't as big a problem
either.  It's certainly going to be the case that the protocol
documents will be updated with new values first.  The MIB will never
have new enums inserted into it before the protocol is defined that
uses those new values.  Thus, the MIB should always be a direct mirror
of the protocol (a frequent case).  If the MIB fails to get updated at
the same time as the master standards document, there is no technical
problem that I can see.  In fact, it's just as if an Unsigned32 had
been used for those unknown values that were being returned/sent.

Now, the one administrative problem that I could see is that human
errors always seem to sneak in.  The worst of which would be a
reordering of the values in question.

W> I suggest something like:
W> 
W> As described in RFC 2407 section 4.4.1, the range of values that
W> will be assigned by IANA for use in this TEXTUAL-CONVENTION and
W> the IPSEC DOI will fall between 0 and 248.  Values in the range
W> 249-255 will not be utilized within IETF standardization
W> documents.

C> I think this would be a step backwards because it suggests that the
C> managed objects won't contain values in the range 249-255, which is
C> not the intent.  The managed objects are supposed to contain a
C> snapshot of what goes in an on-the-wire message, and the DESCRIPTION
C> clause and SYNTAX value should make that fact as clear as they
C> possibly can.

Ok, good point.  How about:

As described in RFC 2407 section 4.4.1, the range of values that will
be assigned by IANA for use in this TEXTUAL-CONVENTION and the IPSEC
DOI will fall between 0 and 248, while legal values on the wire may
fall between 0 and 255.  Values in the range 249-255 will not be
utilized within IETF standardization documents.

My whole goal here is to increase the usability of the MIB that tools
will read.  IMHO, enums are very useful and unless there is a
technical reason why it causes a serious problem to use them in cases
like this, I just don't get why we're removing functionality that is
beneficial to some applications for no technical, engineering gain.
Engineering involves making choices intelligently so things don't
break, while attempting to provide the maximum possible benefit at the
same time.  IMHO, the best gain here is from using enums and I (at
least) have yet to see a reason why things would break.

-- 
Wes Hardaker
Network Associates Laboratories