Re: RADEXT Issue 148 Item 6

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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> wrote:
> Can you clarify what you mean by 'test vector with time-dependent
> specifications of input packets and output counts'?

  If we want to specify in *detail* how the implementations increment
the counters, we need:

  a) set of test packets which should increment various counters
  b) for each packet, a list of counter(s) it increments
  c) time ordering for packets: send packet 1, 2, 3, 4...
  d) time ordering for querying the counters: after packet 1,
     the counters should have the following values: a, b, c, d...

  Without that level of detail, *no* management application can
guarantee that the same input to multiple implementations results in
the same MIB values over time.

  And even that level of detail isn't enough, because there may be any
packet ordering, any number of simultaneous packets, and any
combination of the two.

  The suggested equations in the MIB documents *cannot* hold true,
except as approximations over long periods of time.  This is because
the SNMP queries are generally not against a "snapshot" of the system,
but rather a sert of independent queries spread over time.

  At best, the counters are the MIB implementation's idea of what the
values should be, at a particular time.  We shouldn't pretend that the
MIB's offer a rigorously defined view of a transactional and versioned
database.

> >   I'm not sure what you mean by that.  There is no mandated=20
> > behavior for interpretation of the counters by a management=20
> > application.  There is no "interoperability" requirement=20
> > among management applications.
> 
> I am sorry, no offense intended, but are you serious? Of course there
> is, as with any standard. Why are we defining MIB objects at all?

  Because having some information is better than having no information.

  The only way I can interpret your requirement on "interoperability"
of management applications is that for a given set of input, all
RADIUS servers must yield exactly the same values for all counters
over time.  This means that the management application can then know
that the counters have consistent meaning across all implementations.

  I don't see how this is *ever* possible in practice.  Implementation
timing issues result in different counters being incremented at
different points in time.  Unless we are to forbid this behavior, our
only option is to agree that the counters have some level of
implementation-dependent behavior.

> >   Can you give concrete examples of problems caused by=20
> > different implementations of the MIB counters?
> 
> What MIB counters? People are using MIB counters in a zillion of ways,
> from disconnecting backbone networks when networkErrors counters
> thresholds are exceeded to sending congratulation messages each time the
> counter of years in ageOfPerson objects advance? In both cases and in
> many other fuzzy definitions leading to inconsistent implementations may
> cause problems.

  Sorry, I was asking about *RADIUS* counters, and concrete examples
of problems when implementations differ slightly in their incrementing
of the counters.

> Of course implementations may be different, but definitions of objects
> must be clear enough exactly so that the results obtained by
> implementing differently are consistent.

  Consistent, I can agree with.  My concern is that you appeared to be
advocating *identical* results, which I believe to be impossible.

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