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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Sat, 11 Jan 2003 16:36:07 +0100

I would think that for a RESET button you would actually not
let anyone do just a setWalk. In fact, I think that a setWalk
is a really bad idea, except for when you are testing the SNMP
stack or maybe the instrumentation. You would never do so 
(I think) on an operational system. 

Access control (VACM after authenticated access) would make
sure that only appropriate personal or tools would get SET
access to MIB objects.

Inline.

Thanks,
Bert 

> -----Original Message-----
> From: Kirk Friedman [mailto:[email-masked]]
> Sent: zaterdag 11 januari 2003 1:45
> To: 'Wijnen, Bert (Bert)'; 'Eduardo Cardona'; 'Ipcdn (E-mail)'
> Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for
> docsBpi2CmAuthReset
> 
> 
> Hi Bert,
> 
>     I think we all very much appreciate the ideas, I just
> want to make sure
> that this is not going to cause problems for DOCSIS testing 
> and operation.
> If I understand RFC2579 then reading the value from the 
> object and setting
> exactly the same value back causes the object to increment 
> the value by 1,
> and possibly perform the action.  Any other set causes an error of
> 'inconsistentValue'.  So snipping from Daniel Perkins example:
> 
>    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 }
> 
> A setwalk would result in an AuthRest for every CM in the 
> system.  Does this
> sound correct?  I don't think this is the intended operation 
> of the setwalk test that many vendors use.

That is correct, and the setWalk would have that effect.
See above why I think you should never run a setWalk on
an operational system.

> I think this is why the TruthValue has been used in the past.
> 
Sounds like you guys should continue with that.

> Is this what you are suggesting for docsSubMgtCpeControlReset?  The
> docsSubMgtCpeControlReset as a TestAndIncr would clear all of 
> the 'learned' addresses in docsSubMgtCpeIpTable for a given CM being 
> deleted. Again, I do not think this is the intended result.
> Any automated test program would
> have to realize that after this, any entries in the 
> docsSubMgtCpeIpTable that it read previously, should not be tested.
> 
Even when you use TruthValue, I would NOT allow uncontroled access
to this object. Instead protect it via VACM, and never run a 
setWalk against operational systems (unless you are aware of the 
side-effects and don't care).

Bert
> Thanks,
> 
> Kirk
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email-masked]]
> Sent: Friday, January 10, 2003 4:02 PM
> To: Kirk Friedman; 'Eduardo Cardona'; 'Wijnen, Bert (Bert)'; 'Ipcdn
> (E-mail)'
> Subject: RE: [ipcdn] docsis subscriber mib - TruthValue for
> docsBpi2CmAuthReset
> 
> 
> >      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.
> 
> Why would setwalk break with a TestAndIncr ??? You can read the
> value and set it back to the same value (as per RFC2579).
> 
> And in any event, if the setwalk breaks on it, then it will
> break already at many places in the MIB tree, cause we do have
> quite a set of TestAndIncr objects in various stds track MIB
> modules already.
> 
> Please note that I was not trying to force the WG to go to
> TestAndIncr syntax. I have been asking the question to my
> set of MIB Doctors, and I am forwarding ideas/suggestions that
> come out of that group.
> 
> Maybe it was not clear from the email, but I was asking (in my
> last email to the Mib Doctors) if your current TC is so bad
> that we would want to force you to change it. I have not yet
> received a convincing answer that we should. So if you want
> to keep it... I think it will be fine (unless I hear serious
> concern over the next few days of my MIB doctors).
> 
> What the MIB doctors have been doing is passing issues/concerns
> that you might want to think about, and if they are applicable
> then they have made suggestion for alternatives.
> 
> Bert
> 
_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Kirk Friedman" <[email-masked]>
Date: Mon, 13 Jan 2003 11:25:24 -0800

Hi Bert,

     The idea is not for operational systems, but to check correct
implementation of the MIB automatically across all objects.

     I have no objections to making docsSubMgtCpeControlReset or
docsBpi2CmAuthReset TestAndIncr as long as CableLabs and other vendors
understand and agree.  It is simpler and more elegant than adding a
timestamp.

Thanks,

Kirk

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]]
Sent: Saturday, January 11, 2003 7:36 AM
To: Kirk Friedman; 'Wijnen, Bert (Bert)'; 'Eduardo Cardona'; 'Ipcdn
(E-mail)'

Inline.

Thanks,
Bert

Bert