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

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Mon, 2 Aug 2004 19:05:21 -0700

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: Junming Gao <[email-masked]>
Date: Tue, 03 Aug 2004 14:57:22 -0400

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.
>
>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
>
>Cc: 'Jean-Francois Mule'; Raftus, David; 
>Comcast"<[email-masked]>, <[email-masked]>, 
><[email-masked]>, <[email-masked]>"@az33exr01.mot.com
>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.
>
>Cc: 'Jean-Francois Mule'; [email-masked]; Raftus, David; 
>Richard Woundy @ Comcast; [email-masked]; Azlina Ahmad \(E-mail\)
>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. As a design choice it is wise to add wording in the descriptive text 
>of the RFC. Otherwise would have similar remarks I presume.
>
> >
> >
> >