Subject: RE: [ipcdn] Cable Device MIB and Notifications

From: Rich Woundy <[email-masked]>
Date: Thu, 01 Mar 2001 10:58:57 -0500

At 01:20 PM 2/28/2001 -0500, Nakanishi, Greg wrote:
>In my opinion, it would be better to leave the notification details out of
>this document, since I presume this will be fully described in [24].  I'm
>alway wary of duplicating such information in more than one document and the
>problems of trying to keep the associated documents in synch.
>
>I would suggest that this document simple state that DOCSIS notifications
>are defined in [24].  The reader, if interested, would then go read [24].

Greg,

I agree with your rationale. Unfortunately, according to IETF 
standardization rules (cable device MIB is going for Draft Standard), I 
can't make a "normative reference" to [24]. I do think I can say the following:

"3.2.2.  Events and Notifications

"This MIB provides control facilities for reporting events through
syslog, notifications (traps and informs), and non-volatile logging.

"The conventions for event reporting are outside the scope of this
document.  The definition and coding of common DOCSIS notifications
can be found in [24]."

In the meantime, can someone comment about the following paragraph from RFC 
2669? Does it apply to [24], or any other similar rules?

"The last digit of the trap OID for enterprise-specific traps must match
docsDevEvId.  For SNMPv1-capable Network Management systems, this is
necessary to correlate the event type to the trap type.  Many Network
Management systems are only capable of trap filtering on an enterprise
and single-last-digit basis."

-- Rich

P.S. [24] reference is:

[24] Gao, J., and P. Siripunkaw, "Event Notification Management
      Information Base for DOCSIS 1.1 Compliant Cable Modems and
      Cable Modem Termination Systems", work in progress.

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

---

From: Patrick Michael-LZZ007 <[email-masked]>
Date: Thu, 1 Mar 2001 11:12:38 -0500

Rich,

Did you really mean the last decimal digit, e.g "3" of the oid 1.2.123,
or the last "component" of the OID, i.e. "123" in 1.2.123?  My understanding
is that the component, i.e. the last integer of the OID, is the key event
identifier,
not the last decimal digit of that integer.

-mike

-----Original Message-----
From: Rich Woundy [mailto:[email-masked]]
Sent: Wednesday, February 28, 2001 12:05 AM
To: [email-masked]
Subject: [ipcdn] Cable Device MIB and Notifications

Folks,

I am looking for feedback on the following substantially-rewritten section 
in the RFC 2669 update.

I aligned the vendor-specific notifications with the general format of the 
newly defined DOCSIS notifications. I am looking for confirmation that this 
is the correct approach, rather than sticking with the single 
"DisplayString" object in the "trap" definition.

If you have an opinion on this topic, please let me know by Thursday, since 
I have a Friday submission deadline. Thanks in advance.

-- Rich

3.2.2.  Events and Notifications

    This MIB provides control facilities for reporting events through
    syslog, notifications (traps and informs), and non-volatile logging.
    If events are reported through notifications, the specified
    conventions must be followed.  Other means of event reporting are
    outside the scope of this document.

    The definition and coding of common DOCSIS events can be found in
    [24]; in addition, a CM or CMTS may support events that are vendor-
    specific.  In deference to the network operator who must troubleshoot
    multi-vendor networks, the circumstances and meaning of each vendor-
    specific event should be reported as human-readable text.  Vendors
    SHOULD provide time-of-day clocks in CMs to provide useful
    timestamping of events.

    For each vendor-specific event that is reportable via trap or inform,
    the vendor must create an enterprise-specific notification
    definition.  Notification definitions MUST include:
    o    docsDevEvLevel (priority level)
    o    docsDevEvId (unique identification)
    o    docsDevEvText (text description)

    CM notification definitions SHOULD also include:
    o    docsIfDevDocsisCapability (DOCSIS version capability of CM)
    o    docsIfDevDocsisOperStatus (DOCSIS version running on CM)
    o    ifPhysAddress (physical address of CM RF MAC interface)
    o    docsIfCmCmtsAddress (physical address of CMTS RF MAC interface)

    CMTS notification definitions SHOULD also include:
    o     docsIfCmtsCmStatusDocsisVersion (DOCSIS version capability of CM)
    o     docsIfCmtsCmStatusMacAddress (physical address of CM)
    o     docsIfDevDocsisCapability (DOCSIS version running on CMTS)
    o     ifPhysAddress (physical address of CMTS RF MAC interface)

    In summary, vendor-specific notifications should be defined as:

    <cmNotificationName> NOTIFICATION-TYPE
            OBJECTS { docsDevEvLevel,
                      docsDevEvId,
                      docsDevEvText,
                      docsIfDevDocsisCapability,
                      docsIfDevDocsisOperStatus,
                      ifPhysAddress,
                      docsIfCmCmtsAddress,
                      <other useful objects> }
            STATUS  current
            DESCRIPTION
                "<CM-initiated notification description>"
            ::= <Object Id>

    <cmtsNotificationName> NOTIFICATION-TYPE
            OBJECTS { docsDevEvLevel,
                      docsDevEvId,
                      docsDevEvText,
                      docsIfCmtsCmStatusDocsisVersion,
                      docsIfCmtsCmStatusMacAddress,
                      docsIfDevDocsisCapability,
                      ifPhysAddress,
                      <other useful objects> }
            STATUS  current
            DESCRIPTION
                "<CMTS-initiated notification description>"
            ::= <Object Id>

    Examples of notifications and more information can be found in [24].

    The last digit of the trap OID for enterprise-specific traps must
    match docsDevEvId.  For SNMPv1-capable Network Management systems,
    this is necessary to correlate the event type to the trap type.  Many
    Network Management systems are only capable of trap filtering on an
    enterprise and single-last-digit basis.

...

---

From: Rich Woundy <[email-masked]>
Date: Thu, 01 Mar 2001 13:40:01 -0500

>not the last decimal digit of that integer.

I believe your interpretation is correct. Note that I cut and pasted that 
paragraph from RFC 2669.

This paragraph is now removed from the RFC 2669 update.

-- Rich