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

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

On Thu, 17 Apr 2003, Wes Hardaker wrote:
> 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).

OK, this makes your position very clear (and I think it is in
agreement with the sentiments expressed by the module author).

> 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.

Agreed.

> 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.

Agreed.

> 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.

Depending on what you mean by "the legal range of values" this can
be a problem.  If you mean "the values in the enum list that are
know to the agent" (which is the behaviour mandated by RFC 2578
Section 7.1.1) then this IS a problem because for the DOI TCs the
agent should ACCEPT any value that is within the range defined for
the underlying protocol data item if (a) it does not require special
knowledge on the part of the agent to process it or (b) it is in the
"private use" range and the agent knows what to do with it.  Note
that in the latter case in particular, the value is _valid_ even
though it does not appear in the enum list.  Now, one could code
around this problem, but that won't be conformant to RFC 2578
Section 7.1.1, which says that "only those named-numbers so
enumerated may be present as a value."

> 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?

The issue isn't whether machine-readable enums are appropriate in
general, but whether they are appropriate for objects where some of
the valid values will never appear in the enum list.

> 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.

You might not think so when you've seen the details that apply to
this case.  Unfortunately, I need to leave right now for an
out-of-town trip, and I will have to defer the details of that
discussion (and the other points in your e-mail) until next week.

Mike