Subject: RE: [ipcdn] draft-ietf-ipcdn-device-mibv2-03.txt

From: "Woundy, Richard" <[email-masked]>
Date: Thu, 19 Dec 2002 15:18:02 -0700

Bob,

With respect to the new DESCRIPTION of docsDevEvThrottleInhibited, I prefer
to act as a document editor, so I am open to suggestions as long as it leads
to a timely closure of approval of a defensible technical document.

I think most folks agree that the original docsDevEvThrottleInhibited
DESCRIPTION clause included too many cases in which the object value was
true: "If true(1), trap and syslog transmission is currently inhibited due
to thresholds and/or the current setting of docsDevEvThrottleAdminStatus. In
addition, this is set to true(1) if transmission is inhibited due to no
syslog (docsDevEvSyslog) or trap (docsDevNmAccessEntry) destinations having
been set." The issue so far is the second sentence, which (at a minimum)
references a table which is not accessible for the CM in SNMP Coexistence
Mode.

The intent of the current version of the Cable Device MIB draft is to
clarify the DESCRIPTION of docsDevEvThrottleInhibited along the lines of
DOCSIS ECx 2207/2208. My understanding as I was editing was that this change
is in accordance with RFC 2578 section 10.2, "(8)  Clarifications and
additional information may be included in the DESCRIPTION clause."

However, I think I understand your position that the new language changes
the semantics of the object, in which case the following language from RFC
2578 applies: "Otherwise, if the semantics of any previously defined object
are changed (i.e., if a non-editorial change is made to any clause other
than those specifically allowed above), then the OBJECT IDENTIFIER value
associated with that object must also be changed."

I am not opposed to deprecating the existing object, and defining a new
object.

In fact, let me offer my own suggestion about defining this new
greatly-simplified object:

   docsDevEvThrottleThresholdExceeded OBJECT-TYPE
           SYNTAX      TruthValue
           MAX-ACCESS  read-only
           STATUS      current
           DESCRIPTION
               "If true(1), trap and syslog transmission is currently
                inhibited due to exceeding the trap/syslog event
                threshold in the current interval."
           ::= { docsDevEvent 11 }

Note that an excessive number of trap/syslog messages would be reflected
only in docsDevEvThrottleThresholdExceeded, administrative throttling would
only be reflected in docsDevEvThrottleAdminStatus, and the lack of
syslog/trap targets would only be reflected in the respective MIBs, e.g.
docsDevEvSyslog, docsDevNmAccessEntry, snmpTargetAddress, and/or
snmpCommunityTable. All of these possible event throttling causes would not
be convoluted into a single amorphous MIB object.

What do folks think???

-- Rich

P.S. You can call me Rich or Richard.

>  -----Original Message-----
> From: 	Bob Webster [mailto:[email-masked]] 
> Sent:	Wednesday, December 18, 2002 1:26 PM
> To:	'Ipcdn List (E-mail)'
> Subject:	[ipcdn] draft-ietf-ipcdn-device-mibv2-03.txt
> 
> R. Woundy,
> I was investigating this draft and noticed the docsDevEvThrottleInhibited
change.
> I hope this is not going to be submitted as is.  I do not think the change
makes
> sense, I do not think the change is just a clarification of the behavior.
The MAY
> changes the behavior - I cannot imagine a MAY is acceptable within a Mib
> description were it leads, as this does, to a very ambiguous meaning to
the objects
> value.  
> I think the Mib draft should NOT be changed per ECx 2207/2208 as I believe
> discussion for a real meaningful change in light of SnmpV3 and other
notification
> filter mechanisms needs to take place such that the throttling mechanism
maintains
> value.  
> At the very least, the addition of MAY changes the objects meaning
sufficiently,
> in my mind, to require deprecation and generation of a new object with the

> new requirements.  
> Bob Webster
> Correlant Communications

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Bob Webster" <[email-masked]>
Date: Thu, 19 Dec 2002 15:07:11 -0800

Rich,

I like this proposed change, and your mib name is much better than
the one I suggested.  It makes the change cleanly and without ambiguity.

Bob Webster

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Woundy, Richard
Sent: Thursday, December 19, 2002 2:18 PM
To: 'Bob Webster'
Cc: IPCDN (E-mail); DOCSIS OSS (E-mail)
Subject: RE: [ipcdn] draft-ietf-ipcdn-device-mibv2-03.txt

Bob,

What do folks think???

-- Rich

change.
makes
The MAY
the objects
notification
maintains
sufficiently,