RE: draft-ietf-ospf-mib-update-04

["Chapman, Ken" <KChapman@unispherenetworks.com>]

Mike,
This is a better alternate, but doesn't take into consideration the
rules in RFC2578 clause 10.2 that dictate defining new, replacement 
objects if the "semantic" are changed, which is the problem Spencer
was trying to explain to me.

I am now thinking that the MIBs or SNMP WG should help us understand 
this particular case, since I now see a possibility that we CAN just 
change the syntax to Integer32 (0..2147483647) without breaking any
SMIv2 rules.  I just reread the first paragraph in clause 10:

"  As experience is gained with an information module, it may be
   desirable to revise that information module.  However, changes are
   not allowed if they have any potential to cause interoperability
   problems "over the wire" between an implementation using an original
   specification and an implementation using an updated
   specification(s)."

In this case, since the original syntax would cause a basic encoding 
error with unpredictable results, there could be no "interoperability"
using a negative value.  Therefore, fixing it actually leads to BETTER
interoperability!  So, is it, or is it not OK to make these changes?

Cheers,
	Ken


> -----Original Message-----
> From: C. M. Heard [mailto:heard@vvnet.com]
> Sent: Thursday, October 19, 2000 11:06 PM
> To: mibs@ops.ietf.org; ospf@discuss.microsoft.com
> Subject: RE: draft-ietf-ospf-mib-update-04
> 
> 
> On Thu, 19 Oct 2000, Chapman, Ken wrote:
> 
> > Integer objects used as INDEX (auxiliary) objects can't be 
> negative (RFC2578
> > clause 7.7 bottom of page 27). 
> > Therefore, you need to change the SYNTAX for ospfAddressLessIf,
> > ospfIfMetricAddressLessIf, ospfNbrAddressLessIndex, and
> > ospfLocalLsdbAddressLessIf from Integer32 to Unsigned32.
> 
> Index objects cannot be negative, but it does not follow that 
> it is not
> legal for them to have a SYNTAX of Integer32.  A syntax of 
> Integer32 is
> perfectly legal provided that they cannot assume negative values.
> 
> Rather than change the SYNTAX to Unsigned32 consider instead adding a
> range clause that restricts the objects to non-negative values (as is
> done in the InterfaceIndex TC, to name one example).
> 
> //cmh
> 
>