RE: RADEXT Issue 148 Item 6

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

Alan,

See in-line.

Regards,

Dan




 
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, December 13, 2005 9:48 PM
> To: radiusext@ops.ietf.org
> Subject: Re: RADEXT Issue 148 Item 6 
> 
> "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.

There is some confusion in what you are describing between the
definition of objects, and measurement methodology. 

My comment in the initial review was triggered by the usage of the term
malformed in the RFC 2618bis-2621bis documents. The term is not defined
in RFC 2865, and the later discussions on the list showed up that there
is no agreement between the subject experts about what this is. 

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

Typically people writing MIB modules are able to provide definitions of
counters without detailing the measurement methodology. But I may be
wrong, I am not a expert in RADIUS, I leave this to the experts. 


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

So, define what kind of objects you are putting in, that's all that I am
asking. 


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

Maybe this is true sometimes, certainly not always. You seem to believe
that MIB objects, or it's only counters maybe, have a level of vagueness
by design. This is simply not true in general. If this is the case of
the RADIUS MIBs objects, or maybe for the 'malformed' objects, you need
to define this in the MIB specification. 

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

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

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

If you believe that a certain level of aproximation for this counteres
is tolerable, you need to define it. 

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

If this is the case, it needs to be documented. 

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

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