RE: review question

["Michael MacFaden" <mrm@kazeon.com>]

Hi Dave,

Sure designing the notifications correctly to reduce redundancy is
probably the best solution. 
But say that can't be done for some non-technical reason. 
So what other methods would help reduce redundancy in DESCRIPTION?

Not that this matters but I've come across more than on notification
(trap) receivers 
that mux off the notification oid or for v1 the trap specific identifier

only without ever examining the varbinds. 

Mike


-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com] 
Sent: Saturday, June 05, 2004 1:27 PM
To: Michael MacFaden; Harrie Hazewinkel; Mreview (E-mail)
Subject: RE: review question

HI,

First, using "trap" in the descriptor and the text of the DESCRIPTION
clause is sooo 1980's. 

Secondly, if all of the notifications contain the same variables, then
another way to define them is to have a single notification with one
variable specifying the event. Using the two notifications below, it
would have values:
   initTLVUnknown, and
   dynServReqFail

PS I don't believe that using an OBJECT-IDENTITY definition is
   appropriate in this situation.

At 12:58 PM 6/5/2004 -0700, Michael MacFaden wrote:
>Hi Harrie,
>
>I would not write a mib module that way and would most likely duplicate

>the text in the DESCRITPION since the number of replications is < 
>my-personal-pain-threshold.
>
>But what are the other possible solutions to limit duplication?
>The first one that came to me (but not tried) was use of a 
>OBJECT-IDENTITY to describe the common text then point the DESCRIPTION 
>to it.
>
>Regards
>Mike MacFaden
>
>
>-----Original Message-----
>From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org] On

>Behalf Of Harrie Hazewinkel
>Sent: Saturday, June 05, 2004 4:55 AM
>To: Mreview (E-mail)
>Cc: Harrie Hazewinkel
>Subject: review question
>
>HI,
>
>
>I have been reviewing the draft-ietf-ipcdn-docsisevent-mib-03.txt.
>In there the following approach is used.
>
>All notifications contain a set of objects/varbinds that are common to 
>all and some are type specific. Some definitions are below.
>In the DESCRIPTION-clause of only the first one is the complete 
>semantics/description given for the common varbinds. All others do 
>'assume; it is there. Do we consider this a good approach.
>
>Personally, I do not think so, but directly saying the description must

>always be repeated I am not sure if people would like that.
>I would like to know what others believe is best.
>
>
>regards,
>Harrie
>
>    docsDevCmInitTLVUnknownTrap NOTIFICATION-TYPE
>        OBJECTS {
>            docsDevEvLevel,
>            docsDevEvId,
>            docsDevEvText,
>            ifPhysAddress,
>            docsIfCmCmtsAddress,
>            docsIfDocsisBaseCapability,
>            docsIfCmStatusDocsisOperMode,
>            docsIfCmStatusModulationType
>        }
>        STATUS current
>        DESCRIPTION
>            "Event due to detection of unknown TLV during
>             the TLV parsing process.
>
>             The values of docsDevEvLevel, docsDevId, and
>             docsDevEvText are from the entry which logs this event
>             in the docsDevEventTable. The docsIfDocsisBaseCapability
>             indicates the DOCSIS version information. The
>             docsIfCmStatusDocsisOperMode indicates the QOS level of
>             the CM, while the docsIfCmStatusModulationType indicates
>             the upstream modulation methodology used by the CM.
>             The ifPhysAddress value is the MAC address of the cable
>             interface of this cable modem.
>             The docsIfCmCmtsAddress specifies the MAC address
>             of the CMTS to which the CM is connected to(if there is a 
>cable
>             card/ interface in the CMTS, then it is actually the MAC 
>address
>             of the cable interface which connected to the CM).
>             This part of information is uniformed across all CM traps.
>            "
>        ::= { docsDevCmTraps 1 }
>
>    docsDevCmDynServReqFailTrap NOTIFICATION-TYPE
>        OBJECTS {
>            docsDevEvLevel,
>            docsDevEvId,
>            docsDevEvText,
>            ifPhysAddress,
>            docsIfCmCmtsAddress,
>            docsIfDocsisBaseCapability,
>            docsIfCmStatusDocsisOperMode,
>            docsIfCmStatusModulationType
>        }
>        STATUS current
>        DESCRIPTION
>            "An event to report the failure of a dynamic service
>             request happened during the dynamic services process.
>            "
>        ::= { docsDevCmTraps 2 }
Regards,
/david t. perkins