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

Thanks everyone that provided comments on the DOCSIS Event MIB draft.  Based on everyone's mailing list comments and discussions held during the IPCDN meeting, we have a consensus.

The consensus is to send all three varbindings in the notification - event id, event level, and event text.  This closes the last issue on this document.

Thanks, greg

-----Original Message-----
From: Junming Gao [mailto:[email protected]] 
Sent: Tuesday, August 03, 2004 11:57 AM
To: Nakanishi Greg-MGI8179
Cc: [email protected]; DOCSIS OSS Majordomo List; [email protected]
Subject: Re: FW: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie tf-ipcdn-doc sisevent-mib-03


In my opinion, since all vendors have already implemented option one, there is not much benefit to change now.

The savings in a few bytes does not count much.
I think the help to a snmp manager is real.

Junming


At 07:05 PM 8/2/2004 -0700, Nakanishi Greg-MGI8179 wrote:
>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