Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie tf-ipcdn-doc sisevent-mib-03

From: "Fred Oko" <[email-masked]>
Date: Tue, 3 Aug 2004 01:42:29 -0400

Well, it probably helps to just walk down the possible use cases that
fall under the umbrella of 'application'.

I see two points of arguments to consider that are driving the need to
get consensus on this topic:
1) sending event text and level will make the PDU bigger
2) sending two OIDs nobody will ever use is a waste

For point1, we are talking at most 100 extra bytes, and on average
closer to 50 -- fairly insignificant in the grand scheme of things
unless we would send a ton of these notifications which should not be
common. But admittedly a large % inefficiency when considering the
entire PDU w/o event text is not much more than 100 bytes.

For point2, clearly without these OIDs one cannot have a truly simple
application (receive TRAP, show TRAP) that provides sufficient
information to manage any field system.

Now let's look at the likely applications (it is agreed that in all
cases it is necessary to have knowledge of the specific error code's
specific meaning, else troubleshooting is weak and the definition of
extra codes wasted):
1) custom software that has lookup table (but not necessarily for
looking up event level or text if only a subset were mapped for support)
as it has actions associated with each eventid and must know what it
means  -- uses only eventid
2) NMS with custom lookup that uses only event id for filtering and
description -- uses only eventid
3) simple-NMS filter rule that recognizes the TRAP OID, uses event level
to highlight critical issues, and shows the event text since the NMS has
no lookup facilities not available from the MIB (hopefully also has some
simple aggregation/correlation else unwieldy in all but small/issue-free
systems) -- uses all three data elements

One can argue that building the lookup table is tedious, yet clearly
every CM and CMTS vendor has already done this to support eventlog and
syslog in their devices. Yet I would be surprised if either 1) or 2)
were the common cases, albeit most desirable of an intelligent system as
3) still requires you to understand the event text to the point of
making it actionable (this step requiring a lookup for all but the most
experienced user which if by either software of human would use
eventid). So removing event level and event text precludes the ability
to have application3 while gaining little more than a slightly more
efficient PDU. But if application3 is a difficult-to-manage choice ...
one could definitely argue that designing an interface where you must
conjecture at the requirements is non-optimal -- preclude by design or
cater to all. Despite any direction of my comments, I'd cater to all and
move on for the simple reason that eventlog and syslog are sufficient on
their own so make TRAPs be just a consistent, alternative data channel
even if it is more likely that software acts upon a TRAP.

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Monday, August 02, 2004 10:05 PM
To: [email-masked]; DOCSIS OSS Majordomo List
Cc: [email-masked]
Subject: FW: [ipcdn] Re: [psg.com #471] Expert review comments on
draft-ie tf-ipcdn-doc sisevent-mib-03

Hi,

I posted the following open issue to the IPCDN mailing list a few weeks
ago and haven't received any feedback.  So, I'm reposting it and also
cross-posting it to the DOCSIS OSSI reflector.

There is one issue remaining to be resolved for the IETF draft
submission of the Event Notification MIB document.  

I'd like to request that all interested persons review the open issue
(see below e-mail) and express their position. We're very close to
completing the IETF IPCDN Event Notification MIB document and need to
close this issue to proceed. We'd like to close this issue in the next
week or so, so I'd appreciate it if you could provide your feedback
ASAP.

For people reading this on the OSSI reflector, please also respond to
the IPCDN mailing list.  If you're not a member of the IPCDN mailing
list, I'll forward your response for you.

Thanks, greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Nakanishi Greg-MGI8179
Sent: Friday, July 09, 2004 2:20 PM
To: 'Harrie Hazewinkel'
Cc: 'Jean-Francois Mule'; Raftus, David;
Comcast"<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>"@az33exr01.mot.com
Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on
draft-ie tf-ipcdn-doc sisevent-mib-03

Harrie,

Thanks for the response.  

I think we have consensus on all but one item.  Specifically, the issue
on whether to include just the event id instead of (event id, event
level, and event text) in the varbinding list.

I'd like to solicit comments from the working group on this issue get a
consensus on which way to go. There are two options to consider:

1) Send event id, event level, and event text in the notification.  The
application   gets required info from the notification, no lookup table
is needed.  The message size is larger than option 2.

2) Send just the event id in the notification.  The application uses
some type of lookup table to determine the event level and event text.
The message size is smaller than option 1.  

I've extracted the comments on this issue so people don't have to scroll
through all the other comments.

>> [AA, GN] docsDevId is sufficient to identify the event.  One could
>> determine docsDevEvLevel and docsDevEvText from the id.  But, the 
>> application would need some type of lookup table to do this.  So, I 
>> think the intent was have the agent provide all the info so that a 
>> lookup table wouldn't be needed.
>
> One can do indeed this, how about the manager needs to collect this 
> table sepeartely and can cache it. I presume this information will not

> change over the life time of the device. That would require once the 
> collection of the table and no repeating data in the notification.
>
> NOTE: I am note sure how big this table can be.

greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Harrie Hazewinkel
Sent: Friday, July 09, 2004 1:47 AM
To: Nakanishi Greg-MGI8179
Cc: 'Jean-Francois Mule'; [email-masked]; Raftus, David;
Richard Woundy @ Comcast; [email-masked]; Azlina Ahmad \(E-mail\)
Subject: [ipcdn] Re: [psg.com #471] Expert review comments on
draft-ietf-ipcdn-doc sisevent-mib-03

HI,

SOrry for a late response, but cleaning up todo list for
a wek vacation. -))

Some comments needed or agreements below.
(no agreement of agreements :-)

Harrie

Nakanishi Greg-MGI8179 wrote:
> 
> I presume you the 2 above stated terms are attempted to be described
> briefly. I am not getting any of it. 'A term referring to the DOCSIS 
> for enabling....'
> 1) I already know it is a term. :-)
> 2) Without the reference it looses all info.
> 
> Upon rereading, they are the same, with a different explaination. :-)
> 
> [AA,GN] How about the following words:
> 
> 2.1 BPI - Baseline Privacy Interface
> 
> A mechanism for providing data privacy over the HFC network in DOCSIS
> 1.0 systems.
> 
> 2.2 BPI - Baseline Privacy Plus Interface
> A mechanism that extend the Baseline Privacy Interface with the
> addition of CM authentication over the HFC network in DOCSIS1.1/2.0 
> system and beyond.

OK.

>>2.12 Upstream
>>
>>   The direction from the subscriber towards the head-end.
> 
> 
> 
> 
> SUBJECTIVE:
> Is the term subscriber not needed as definition?
> 
> Quit clear, but to be complete.
> 
> [AA,GN] How about "The direction from the CM to the CMTS" ?  We need
> to change the definition of 'downstream' to match, as well.

OK

>>   available. This notification MIB in conjunction with [10] and [11]
>>   provide a minimum set of standard DOCSIS Traps that DOCSIS devices
> 
> 
> OLD:
> DOCSIS Traps
> 
> NEW:
> SNMP Notifications
> 
> [AA,GN] OK
> 
> NOTE: The notifications are DOCSIS related, but are SNMP.

Agreed, it is where you put the impartance maybe.

> [AA,GN] I think this is mainly historical.  Other DOCSIS related MIBs
> are named similarly.  E.g. RFC 2669, RFC 26670, RFC 3083.  I believe 
> the thinking was, rather than using DOCSIS, to use DOCS which stands 
> for "Data-Over-Cable Service" and drop the IS ("Interface 
> Specification") since it's a MIB module not an Interface 
> Specification.  At this point we prefer to keep the name consistent 
> with the other DOCSIS MIBs.

OK.

> 
> 
>>   Two groups of SNMP notification objects are defined in this
document.
>>   One group defines notifications for cable modem events, and the
other
>>   group defines notifications for cable modem termination system
>>   events.
>>
>>   Common to all CM notification objects (traps) is that in their
>>   OBJECTS statements, a CM trap contains information about the event
>>   priority, the event Id, the event message body, the CM DOCSIS
> 
> 
> 
> 
> I have some difficulty to understand what you mean by the event
> message body. Would that be some kind of description? If so, I would 
> suggest adjusting the naming.
> 
> [AA,GN] How about replacing 'the event message body' with 'a textual
> description of the event' ?  Same wording is used (in two places) in 
> the MIB module description and would need to be changed there as well.

agreed.

> 
>>                address.
>>
>>                These objects are docsDevEvLevel, docsDevId,
> 
> 
> 
> 
> Where does 'These objects are' refer to?
> 
> [AA,GN]   How about "Common objects returned in the varbinding list of
> CMTS notifications are docsDevEvLevel, docsDevId," ?  Similar text is
> also used in the CM notification description and also in Module 
> description and should be updated as well.

Agreed.

> 
>>          "
>>      DEFVAL { {} }
>>      ::= { docsDevTrapControl 1 }
> 
> 
>>   docsDevCmInitTLVUnknownTrap NOTIFICATION-TYPE
>>       OBJECTS {
>>           docsDevEvLevel,
>>           docsDevEvId,
> 
> 
> 
> Why is this object added? Is this value not retrieved from the OID
> used for the docsDevEvLevel and docsDevEvText. In that case one can 
> omit it.
> 
> [AA,GN] docsDevEvId is a numeric identifier for an the event that
> occurred for which there are hundreds defined by DOCSIS.  These events

> are categorized and allocated to a specific notification.  
> docsDevEvLevel is the priority level of the event, docsDevEvText is a 
> textual description of the event.

OK.

> 
>>            The values of docsDevEvLevel, docsDevId, and
>>            docsDevEvText are from the entry which logs this event
>>            in the docsDevEventTable.
> 
> 
> 
> 
> Are these 3 values uniquely identifying the event? If so, please
> indicate that.
> 
> [AA, GN] docsDevId is sufficient to identify the event.  One could
> determine docsDevEvLevel and docsDevEvText from the id.  But, the 
> application would need some type of lookup table to do this.  So, I 
> think the intent was have the agent provide all the info so that a 
> lookup table wouldn't be needed.

One can do indeed this, how about the manager needs to collect this
table sepeartely and can cache it. I presume this information will not
change over the life time of the device. That would require once the
collection of the table and no repeating data in the notification.

NOTE: I am note sure how big this table can be.

> 
> 
>> The docsIfDocsisBaseCapability
>>            indicates the DOCSIS version information.
> 
> 
> 
> The DOCSIS version information of what?
> 
> [AA,GN] Will replace with: "indicates the highest version of the
> DOCSIS specification (1.0, 1.1, or 2.0) that the device is capable of 
> supporting."

OK

> 
> What is ment by 'uniform accross all CM traps'?
> 
> [AA,GN]I think the intent here was to say that the objects previously
> described are also used in the subsequent CM notifications.  This 
> sentence will be deleted, since we'll repeat the description in each 
> notification definition.

OK

> DESIGN-CHOICE

[snip]

> 
> [AA,GN] OK, we'll repeat the description of the objects (and describe
> it
> better) in each notification.
> 
> We prefer not to merge all the notifications even if the same objects
> are returned in many of these notifications.  Essentially, each 
> notification definition serves as a category for a set of events.  
> DOCSIS defines hundreds of events which are categorized and mapped to 
> a particular notification for reporting the event.  This enables the 
> NMS to more easily find events associated with a particular category.

OK. As a design choice it is wise to add wording in the descriptive text
of the RFC. Otherwise would have similar remarks I presume.

> 
> 
> 
>>   docsDevCmSwUpgradeInitTrap NOTIFICATION-TYPE
>>       OBJECTS {
>>           docsDevEvLevel,
>>           docsDevEvId,
>>           docsDevEvText,
>>           ifPhysAddress,
>>           docsIfCmCmtsAddress,
>>           docsDevSwFilename,
>>           docsDevSwServer,
>>           docsIfDocsisBaseCapability,
>>           docsIfCmStatusDocsisOperMode,
>>           docsIfCmStatusModulationType
>>       }
>>       STATUS current
>>       DESCRIPTION
>>           "An event to report a software upgrade initiated
>>            event.
> 
> 
> 
> 
> Weird sentence.
> 
> [AA,GN] Will change to: "A notification to indicate that a software
> upgrade has been intiated on the device"

OK

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

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

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

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 3 Aug 2004 08:01:47 -0700

Forwarding comments from Eduardo on Event Notif MIB issue.

greg

-----Original Message-----
From: Eduardo Cardona [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 2:50 AM
To: Nakanishi Greg-MGI8179; Matthew Schmitt; Greg White
Cc: Jean-Francois Mule
Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie tf-ipcdn-doc sisevent-mib-03

Greg, 

The Event messaging structure in DOCSIS rely in EvText for the case of local-log and syslog messages. 
In general EvText is variable depending upon the parameters <Pn> defined in OSSI spec, not without notice that the Parameters <Pn> are already vardinds from the NOTIFICATION-TYPE definition It means that from the surface there is no loss of information by suppressing the EvText varbind. 
- Vendors have the option to add extra text to EvText, which will be lost for the case of Notifications, 
Perhaps an ammend text to Annex D will be required to indicate its usefulnes "Additional vendor specific text MAY be added to the end of the event text." that is only propagated to local-log and syslog messages.

In the case of EventId, It is also redundant if the lookup table is present in the application but I believe that a mechanism for notification filtering at the application is well suitable by using Notification OID and EventLevel, without the need of other elements like look-up tables

My preference will be to remove just the EvText with the clarification in OSSI spec as mentioned above and leave EvId and EvLevel as part of the notification definition.

Thanks

Eduardo

<-- deleted e-mail trail -->

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 3 Aug 2004 12:20:56 -0600

> entire PDU w/o event text is not much more than 100 bytes.

Thank you for your input. Do you or anybody have any actual counts of the number of such messages we typically get at the node/network level in 1 hour?

Based on the issues raised for simple NMS apps, trap exploders and alike using event level to properly route those msgs, I would really like to have a sense of whether this is a theoritical argument or whether we better be concerned about the verbose msgs.

Jean-François

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 3 Aug 2004 13:16:25 -0700

Comment from Denny on this issue.
 
greg
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 12:43 PM
To: Greg Nakanishi; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie tf-ipcdn-doc sisevent-mib-03

Hi Greg, 

I am not in the IPCDN list. 

Although Option 2) has some merits for performance, short messages, it would be a major burden to have to change the implementation for the many Traps specified by DOCSIS.

Regards, 

Denny Landaveri 
Terayon Communications Inc. 

-----Original Message----- 
From: [email-masked] 
[mailto:[email-masked] <mailto:[email-masked]> ]On Behalf Of Nakanishi 
Greg-MGI8179 
Sent: Monday, August 02, 2004 7:05 PM 
To: [email-masked]; DOCSIS OSS Majordomo List 
Cc: [email-masked] 
Subject: FW: [ipcdn] Re: [psg.com #471] Expert review comments on 
draft-ie tf-ipcdn-doc sisevent-mib-03 

Hi, 

I posted the following open issue to the IPCDN mailing list a few weeks ago and haven't received any feedback.  So, I'm reposting it and also cross-posting it to the DOCSIS OSSI reflector.

There is one issue remaining to be resolved for the IETF draft submission of the Event Notification MIB document.  

I'd like to request that all interested persons review the open issue (see below e-mail) and express their position. We're very close to completing the IETF IPCDN Event Notification MIB document and need to close this issue to proceed. We'd like to close this issue in the next week or so, so I'd appreciate it if you could provide your feedback ASAP.

For people reading this on the OSSI reflector, please also respond to the IPCDN mailing list.  If you're not a member of the IPCDN mailing list, I'll forward your response for you.

Thanks, greg 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Nakanishi Greg-MGI8179 
Sent: Friday, July 09, 2004 2:20 PM 
To: 'Harrie Hazewinkel' 
Cc: 'Jean-Francois Mule'; Raftus, David; Comcast"<[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>"@az33exr01.mot.com

Harrie, 

Thanks for the response.  

I think we have consensus on all but one item.  Specifically, the issue on whether to include just the event id instead of (event id, event level, and event text) in the varbinding list.

I'd like to solicit comments from the working group on this issue get a consensus on which way to go. There are two options to consider:

1) Send event id, event level, and event text in the notification.  The application   gets required info from the notification, no lookup table is needed.  The message size is larger than option 2.

2) Send just the event id in the notification.  The application uses some type of lookup table to determine the event level and event text. The message size is smaller than option 1.  

I've extracted the comments on this issue so people don't have to scroll through all the other comments. 

greg 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Harrie Hazewinkel 
Sent: Friday, July 09, 2004 1:47 AM 
To: Nakanishi Greg-MGI8179 
Cc: 'Jean-Francois Mule'; [email-masked]; Raftus, David; Richard Woundy @ Comcast; [email-masked]; Azlina Ahmad \(E-mail\)

Subject: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03 

HI, 

Harrie 

OK. 

OK 

OK. 

> 
> 
>>   Two groups of SNMP notification objects are defined in this document. 
>>   One group defines notifications for cable modem events, and the other 

agreed. 

Agreed. 

OK. 

> lookup table wouldn't be needed. 

One can do indeed this, how about the manager needs to collect this table sepeartely and can cache it. I presume this information will not change over the life time of the device. That would require once the collection of the table and no repeating data in the notification.

OK 

OK 

[snip] 

> NMS to more easily find events associated with a particular category. 

OK. As a design choice it is wise to add wording in the descriptive text of the RFC. Otherwise would have similar remarks I presume.

OK 

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

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

---

From: [email-masked]
Date: Tue, 3 Aug 2004 12:42:52 -0700

Hi Greg,

Although Option 2) has some merits for performance, short messages, it would
be a major burden to have to change the implementation for the many Traps
specified by DOCSIS.

Regards,

Denny Landaveri

-----Original Message-----
[mailto:[email-masked]]On Behalf Of Nakanishi

Hi,

I posted the following open issue to the IPCDN mailing list a few weeks ago
and haven't received any feedback.  So, I'm reposting it and also
cross-posting it to the DOCSIS OSSI reflector.

There is one issue remaining to be resolved for the IETF draft submission of
the Event Notification MIB document.  

I'd like to request that all interested persons review the open issue (see
below e-mail) and express their position. We're very close to completing the
IETF IPCDN Event Notification MIB document and need to close this issue to
proceed. We'd like to close this issue in the next week or so, so I'd
appreciate it if you could provide your feedback ASAP.

For people reading this on the OSSI reflector, please also respond to the
IPCDN mailing list.  If you're not a member of the IPCDN mailing list, I'll
forward your response for you.

Thanks, greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Nakanishi Greg-MGI8179
Sent: Friday, July 09, 2004 2:20 PM
To: 'Harrie Hazewinkel'
Cc: 'Jean-Francois Mule'; Raftus, David;
Comcast"<[email-masked]>, <[email-masked]>,
<[email-masked]>, <[email-masked]>"@az33exr01.mot.com
Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie
tf-ipcdn-doc sisevent-mib-03

Harrie,

Thanks for the response.  

I think we have consensus on all but one item.  Specifically, the issue on
whether to include just the event id instead of (event id, event level, and
event text) in the varbinding list.

1) Send event id, event level, and event text in the notification.  The
application   gets required info from the notification, no lookup table is
needed.  The message size is larger than option 2.

2) Send just the event id in the notification.  The application uses some
type of lookup table to determine the event level and event text. The
message size is smaller than option 1.  

greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harrie Hazewinkel
Sent: Friday, July 09, 2004 1:47 AM
To: Nakanishi Greg-MGI8179
Cc: 'Jean-Francois Mule'; [email-masked]; Raftus, David; Richard
Woundy @ Comcast; [email-masked]; Azlina Ahmad \(E-mail\)
Subject: [ipcdn] Re: [psg.com #471] Expert review comments on
draft-ietf-ipcdn-doc sisevent-mib-03

HI,

Harrie

OK.

OK

OK.

agreed.

Agreed.

OK.

> lookup table wouldn't be needed.

One can do indeed this, how about the manager needs to collect this table
sepeartely and can cache it. I presume this information will not change over
the life time of the device. That would require once the collection of the
table and no repeating data in the notification.

OK

OK

[snip]

> NMS to more easily find events associated with a particular category.

OK. As a design choice it is wise to add wording in the descriptive text of
the RFC. Otherwise would have similar remarks I presume.

OK

---

From: "Fred Oko" <[email-masked]>
Date: Fri, 6 Aug 2004 21:25:31 -0400

First off, I am not aware of anyone actually using the bulk of the defined events at the moment. This could be for a number of reasons from the fact that a large percentage of these events should be for rare events but when backend services break or a large percent of your CM footprint is running firmware of poor interoperability, you don't really want to get a flood of events from CMs to tell you such. Oddly, for all the events defined, the only CM event I am aware of in active consideration is CM de-range (offline or flapping) which is kindly provided as an enterprise TRAP from most CMTS vendors but MSOs have been historically reluctant to enable it. If I am mistaken, I would obviously be interested to know otherwise.

Mind you, there is recognition of the desirability of the timeliness of notification with these events so I would expect usage of the defined events to increase on a per-task basis -- e.g load-balancing will drive usage of the DCC events; software upgrade applications may already consider upgrade events. 

So my argument on events being rare is conjecture, but based on the nature that the bulk of the events should only fire in anomalous/rare situations in a healthy system or in bulk in an unhealthy system (the case I ignored for the poor fit of the granular event model to such a case without an aggregating agent in the CMTS or as part of the NMS).

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 2:21 PM
To: Fred Oko; Nakanishi Greg-MGI8179; [email-masked]; DOCSIS OSS Majordomo List
Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie tf-ipcdn-doc sisevent-mib-03

Jean-François