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