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

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 10 Jan 2003 08:26:33 -0700

All, 
testAndIncrements /spinlock kind of solution is targeted for s'locking'
multiple iterations, would be acceptable  but not intuitive.

 if a massive re-authorization is needed, Why would be needed to read
the value and  set back , What value is added in the testAndIncrement
process?

I will suggest that if ThruthValue is not appropiate, eventualy a new
label for 1,2 would be appropiated:

   docsBpi2CmAuthReset OBJECT-TYPE
        SYNTAX         INTEGER  { -- or propose any other TC convention
for reset-button to IETF
			     reset(1),
                       idle(2)
                       }
        MAX-ACCESS     read-write
        STATUS         current
        DESCRIPTION
             "Setting this object to 'reset' generates a Reauthorize
        event in the authorization FSM. Reading this object always
        returns idle."
        REFERENCE
             "DOCSIS Baseline Privacy Plus Interface Specification,
        Section 4.1.2.3.4."
        ::= { docsBpi2CmBaseEntry 7 }

Eduardo
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Friday, January 10, 2003 6:11 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] docsis subscriber mib - TruthValue for
docsBpi2CmAuthReset

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
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Kirk Friedman" <[email-masked]>
Date: Fri, 10 Jan 2003 11:17:24 -0800

All,

     It seems like the testAndIncrement solution would break the 'setwalk'
test feature from Wilson's email yesterday.  Writing back the same value
read would cause the reset or other action that was not intended.  The
'setwalk' is used by automated SNMP test programs to make sure that a R/W
object is writable.  Using the testAndIncrement for these parameters could
cause many unexpected consequences.

Thanks,

Kirk

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Eduardo Cardona
Sent: Friday, January 10, 2003 7:27 AM
To: Wijnen, Bert (Bert); Ipcdn (E-mail)
Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for
docsBpi2CmAuthReset

All,

Eduardo
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Friday, January 10, 2003 6:11 AM
To: Ipcdn (E-mail)
Subject: [ipcdn] docsis subscriber mib - TruthValue for
docsBpi2CmAuthReset

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,

Regards,
/david t. perkins