RE: docsis subscriber mib (fwd)

[Michael Kirkham <mikek@muonics.com>]

[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