Subject: [ipcdn] docsis subscriber mib - TruthValue for docsBpi2CmAuthReset

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 10 Jan 2003 14:11:19 +0100

After I had posted possible safeguards for the ...Reset
object, Randy Presuhn even had another (possibly better)
suggestion, that is to use TestAndIncr TC from RFC2579.

I also saw your response that you use TruthValue in a few
other similar objects in IPCDN originated MIB Modules.
So I posed the question (to my MIB doctors team) if the
problem is serious enough to make you do things different
now conmpared to what you have done in other MIB modules.

No final answer yet, but below is some input that may be
good to review.

Thanks,
Bert 

-----Original Message-----
From: David T. Perkins [mailto:[email-masked]]
Sent: vrijdag 10 januari 2003 0:33
To: Mreview (E-mail)
Subject: RE: docsis subscriber mib

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:[email-masked]]
>> Sent: donderdag 9 januari 2003 23:51
>> To: Mreview (E-mail)
>> Subject: RE: docsis subscriber mib
>> 
>> 
>> Hi -
>> 
>> > From: Wijnen, Bert (Bert) [mailto:[email-masked]]
>> > 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 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn