RE: docsis subscriber mib

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

HI,

Randy's suggestion is an efficient way to achieve two results:
1) initiating and action, and
2) determining if the action was initiated when no response
   is received.

It's a somewhat unusual application of the TestAndIncr, and
they do have object definitions in the field, and this is
a change of solutions. However, it is a superior solution
to what they have previously done.

Here is the OLD solution....
   docsBpi2CmAuthReset OBJECT-TYPE
        SYNTAX         TruthValue
        MAX-ACCESS     read-write
        STATUS         current
        DESCRIPTION
             "Setting this object to TRUE generates a Reauthorize
        event in the authorization FSM. Reading this object always
        returns FALSE."
        REFERENCE
             "DOCSIS Baseline Privacy Plus Interface Specification,
        Section 4.1.2.3.4."
        ::= { docsBpi2CmBaseEntry 7 }

And here is the NEW solution...
   docsBpi2CmAuthReset OBJECT-TYPE
        SYNTAX         TestAndIncr
        MAX-ACCESS     read-write
        STATUS         current
        DESCRIPTION
             "Setting this object to its current value results in
             incrementing the value and causes a Reauthorize event
             in the authorization FSM. Reading this object always
             returns its current value."
        REFERENCE
             "DOCSIS Baseline Privacy Plus Interface Specification,
             Section 4.1.2.3.4."
        ::= { docsBpi2CmBaseEntry 7 }

Notes: I would probably define another TC that acted like the TestAndIncr
TC, but whose value was the number of "administratively initiated
actions", and to initiate and action, I would write the current value
plus one (instead of the current value).

At 12:17 AM 1/10/2003 +0100, Wijnen, Bert (Bert) wrote:
>Possibly... the reason why I forwarded was,
>cause they seem to want one common way of doing these
>things and we/they already have a set of RFCs that
>do this in the same way as they are proposing in this 
>new MIB module. 
>
>So the question becomes:
> - is it so seriously flawed that we want to force them 
>   to change the way they are doing these resets
> - if so, then we should make a note so that if they
>   respind the existing RFCs, that we then also force them
>   to deprecate and create a new object.
>
>Or does this not make sense what I am asking here?
>
>Thanks,
>Bert 
>
>> -----Original Message-----
>> From: Presuhn, Randy [mailto:Randy_Presuhn@bmc.com]
>> Sent: donderdag 9 januari 2003 23:51
>> To: Mreview (E-mail)
>> Subject: RE: docsis subscriber mib
>> 
>> 
>> Hi -
>> 
>> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
>> > Sent: Thursday, January 09, 2003 13:47
>> > To: Mreview (E-mail)
>> > Subject: Re: docsis subscriber mib
>> > 
>> > 
>> > This is what I get back (or what I see in terms of discussion
>> > on their ipcdn mailing list).
>> ...
>> 
>> Elaborating on my earlier comment:
>> 
>> If the purpose of adding an additional time stamp object is
>> to support detection of the cases Dave Perkins outlined,
>> wouldn't it be simpler to replace the TruthValue with a
>> TestAndIncr?  This would get rid of the odd read/write
>> semantics, prevent the worst replay scenarios, and allow
>> recovery in the "lost response" case.
>> 
>> The semantics they're proposing for these objects really
>> don't match up with TruthValue.
>> 
>>  Randy Presuhn          BMC Software, Inc.  1-3141
Regards,
/david t. perkins