RE: docsis subscriber mib (fwd)

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

The big problem with the current approach, and with what you propose
is that you don't know if the "action" was performed. The TestAndIncr
definition has the problem that concerns you, which is writing the
current value actually causes an action to be performed.

So, at a higher level, it really points to the "configuration problem"
with SNMP. A MIB tools vendor might create an "annotation"
approach to associate additional info with items defined in MIB
modules, so that more "intelligent" mgmt apps could be written,
so that action objects were not "pushed". 

At 06:34 AM 1/31/2003 -0800, Michael Kirkham wrote:

>[I sent this to Bert Wijnen, who kindly suggested that I bring this up
>here on the mibs list.]
>
>Hi, I was just thumbing through some of the mreview archives (for
>additional things I should test for or anything I shouldn't generate
>errors for that I currently do).  While not related to that goal, I
>thought I should comment on this thread of a couple weeks ago, posed by
>Bert:
>
>> Does anyone see a problem with this:
>>
>>   docsSubMgtCpeControlReset OBJECT-TYPE
>>       SYNTAX  TruthValue
>>       MAX-ACCESS read-write
>>       STATUS  current
>>       DESCRIPTION
>>           "This object always returns false on read.  If this object is
>>       set to true, the rows with  'learned' addresses in
>>       docsSubMgtCpeIpTable for this CM are deleted from that table."
>>       ::= { docsSubMgtCpeControlEntry 4 }
>
>I would suggest that a different TC be defined, with the same
>semantics/values as used in these Reset objects, rather than the
>TestAndIncr approach suggested in the thread, which otherwise might be a
>good idea.  The problem is, one of the many things one wants to test in an
>agent implementation is that nothing catastrophic happens if you set an
>object to its current value. Both the TestAndIncr approach and another
>comment I saw, where only one value was ever allowed (the value both read
>and written) have the problem that if you nonchalantly set every writable
>object to its current value, bad/unexpected things happen.
>
>The object should be protected from unintential resets, at the very least
>by having the "reset button" be a different value than what is read.
>Better still would be to use both a TestAndIncr object -and- the actual
>"true/false" reset button object, but as mentioned in the thread this
>method is already deployed in an RFC.
>
>ResetButtonTC TEXTUAL-CONVENTION
>    STATUS  current
>    DESCRIPTION
>       "Objects of this type always return the 'idle' value when
>        read.  When written with the value 'reset', a reset of some
>        type is performed.  Objects of this type MUST describe the
>        nature of the reset in their DESCRIPTION, and SHOULD be
>        paired with a TestAndIncr object that, if defined, MUST
>        be set to its current value in the same request as that
>        of the reset to prevent unintentional resets or replay
>        attacks from succeeding.  Setting an object of this type
>        to the value 'idle' has no effect."
>    SYNTAX  INTEGER { reset(1), idle(2) }
>
>This would be compatible with current definitions, avoid accidental
>resets, and avoid confusion caused by the use of 'TruthValue'.  If you
>wanted to go a step further you could define another textual convention,
>similar to TestAndIncr, to be used in place of TestAndIncr on a paired
>object, that must be set to its NEXT value, rather than its current value,
>though it's probably not necessary to go that far.
>
>--
>Michael Kirkham
>www.muonics.com
Enjoy,
/david t. perkins