Re: RADEXT Issue 148 Item 6

["Alan DeKok" <aland@ox.org>]

"Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:
> There is some confusion in what you are describing between the
> definition of objects, and measurement methodology.

  I understand.  My reason for the confusion, though, is that for many
reasons I see those issues as overlapping.

  Another disconnect, I think, is the differences between design and
implementation.  The MIB's define counters, which is well and good,
but implementations have to make *some* decision for topics on which
the MIBs are silent.  Since we can't describe all possible scenarios
in the MIB specification, some level of vagueness is built-in to it.

> A clear definition of what you are counting MUST be provided. It is
> missing now.

  I agree.  The definition for "malformed" is generally agreed on:
doesn't match the packet format as defined in RFC 2865.  The rest of
the arguments are over the details.

> You seem to believe that MIB objects, or it's only counters maybe,
> have a level of vagueness by design.

  No, I'm saying that the *measurement* of those counters is
imprecise.  Each implementation defines exactly which counter it
increments, and when.  But that information may not be visible to the
management application that queries the counters.  As a result, the
management application may have to assume that the counters are close
to being consistent, but may not be perfect.

  e.g. If you query the counters, the equation relating them may *not*
hold true, but it should be *close*.

> What is the admissible variation due to implementation timing? Is it
> possible that one implementation never counts anything because of timing
> issues? Probably not.

  Or, an implementation simply doesn't increment a particular counter.

  These issues hold true not only for RADIUS, but for any MIB
implementation which have relationships between multiple counters.
The only way those relationships can hold true is if the SNMP queries
are against a transactional versioned database.

  Such MIB implementations are not common.  Rather, the common
implementation is that the MIB data is a "snapshot" of the current
counter, at the time it was queried.


  In any case, I think we've wandered far afield from the original
topic.  My background here is from implementation, where imperfect
specs lead to implementation-defined behavior.  We try to get
implementations inter-operable, but they will never be identical.

  As for this issue, I think the consensus is that the definition of
"malformed" is "does not match the packet format as defined in RFC
2865".  If you're OK with that, I think we can move forward.

  That's what implementations have deployed today, and that appears to
be the consensus so far here.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>