Re: docsis subscriber mib

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

This is what I get back (or what I see in terms of discussion
on their ipcdn mailing list).

Thanks,
Bert 

-----Original Message-----
From: Kirk Friedman [mailto:kfriedman@correlant.com]
Sent: donderdag 9 januari 2003 22:20
To: Wilson.Sawyer@arrisi.com; ipcdn@ietf.org
Cc: bert.wijnen@lucent.com
Subject: RE: [ipcdn] docsis subscriber management: adding timestamp
object to docsSubMgtCpeControlTable


Wilson,

     I don't have any objection to this.  But there are other MIBs in the
DOCSIS set that don't use a timestamp for setting a TruthValue, one of which
is an RFC.  Should this one be unique?  Examples:

From draft-ietf-ipcdn-bpiplus-mib-05.txt
   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 }

Same kind of setting for docsBpi2CmtsTEKReset.

Equivalent settings in BPI MIB RFC-3083

The Cable Device MIB (RFC 2669)also has docsDevResetNow though if set to
TRUE the system should reset, so a timestamp isn't really needed.

Thanks,

Kirk Friedman
Correlant Communications
15110 Avenue Of Science
San Diego, CA., 92128


-----Original Message-----
From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of
Wilson.Sawyer@arrisi.com
Sent: Thursday, January 09, 2003 12:22 PM
To: ipcdn@ietf.org
Cc: bert.wijnen@lucent.com
Subject: [ipcdn] docsis subscriber management: adding timestamp object
to docsSubMgtCpeControlTable


Bert has expressed reservations about

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 }

since there is no real way to tell whether the operation took place or not.
I'm considering adding (at his suggestion) a timestamp object:

docsSubMgtCpeControlLastReset OBJECT-TYPE
    SYNTAX  TimeStamp
    MAX-ACCESS read-only
    STATUS  current
    DESCRIPTION
        "The value of sysUpTime when docsSubMgtCpeControlReset was last
    set true. Zero if never reset."
    ::= { docsSubMgtCpeControlEntry 5 }

Does this make sense to everyone?

There was also a comment about the apparent uselessness of a TruthValue,
since only one value is meaningful. In defense of the TruthValue, I'd note
the SNMP test procedure called 'setwalk': it performs a get-next walk of
the mib, and for any R/W objects, attempts to 'set' them to their existing
value. The assumption** is that such a walk is harmless - setting something
to its existing value is assumed to have no side-effects. So a setwalk of
this object will change nothing, which is the desired behavior. If the
object were changed to have a single value, then the setwalk would have
side-effects.

** this assumption is flawed, but there's no need to add yet another
exception to its validity.

- Wilson

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn