RE: RADEXT Issue 148 Item 6

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

Please use this version of the mail.

See in-line. 

Regards,

Dan


 
 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Barney Wolff
> Sent: Tuesday, December 13, 2005 8:32 PM
> Cc: radiusext@ops.ietf.org
> Subject: Re: RADEXT Issue 148 Item 6
> 
> On Tue, Dec 13, 2005 at 06:39:26PM +0200, Romascanu, Dan (Dan) wrote:
> > 
> > Interoperability means that the document is clear enough so 
> that two 
> > different implementers can create two distinct implementations that 
> > result in the same counter values for any given mix of 
> well-formed and 
> > malformed packets. Different implementations following the 
> text in the 
> > documents MUST NOT result in different counter values.
> 
> Why?  What harm would result, to users or providers, if two 
> implementations produced somewhat different counts?  For that 
> matter, what harm would result, to users or providers, if two 
> implementations differed somewhat in how strict their 
> interpretations of "well-formed" on receipt were?

One cannot and should not make assumptions about how objects are used. 

Let me ask you the other way? What is the usage of defining MIB objects
in a way that applications cannot build on these objects having
consistent and repeatable values even if coming from different code
basis. 


> Is every implementation required to be a conformance test suite?
> 
> I imagine we would all agree that a conformant implementation MUST NOT
> *send* malformed packets, and MUST NOT crash or loop on 
> receipt of any packet.
> 
> Seems to me that the only important criterion for counting 
> malformed packets is that the count MUST reflect how many 
> packets were handled as malformed.

If this is what the applications need, then deprecate the current
'malformed' objects, and define 'handled as malformed' objects. The
problem is that today you have 'malformed' objects that not only are not
defined, but you guys do not seem to agree what they mean, and candidly
admit that different implementations will return different values for
these objects. As a MIB reviewer I cannot let this fly. Sorry. 
 
> 
> Regards,
> Barney
> 
> --
> 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/>