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

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 protected]] 
Sent: Monday, August 02, 2004 10:05 PM
To: [email protected]; DOCSIS OSS Majordomo List
Cc: [email protected]
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 protected] [mailto:[email protected]] 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 protected]>, <[email protected]>,
<[email protected]>, <[email protected]>"@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 protected] [mailto:[email protected]] On Behalf
Of Harrie Hazewinkel
Sent: Friday, July 09, 2004 1:47 AM
To: Nakanishi Greg-MGI8179
Cc: 'Jean-Francois Mule'; [email protected]; Raftus, David;
Richard Woundy @ Comcast; [email protected]; 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 protected]
https://www1.ietf.org/mailman/listinfo/ipcdn

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