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

Comment from Denny on this issue.
 
greg
 
-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Tuesday, August 03, 2004 12:43 PM
To: Greg Nakanishi; [email protected]; [email protected]
Cc: [email protected]
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 protected] 
[mailto:[email protected] <mailto:[email protected]> ]On Behalf Of Nakanishi 
Greg-MGI8179 
Sent: Monday, August 02, 2004 7: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] <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] <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 <https://www1.ietf.org/mailman/listinfo/ipcdn>  

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

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