Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

From: "Sumanth Channabasappa" <[email-masked]>
Date: Fri, 7 Oct 2005 15:20:59 -0600

Greg, Randy, Eugene,

Thanks for the comments. A few clarifications inline:

#1:
- The description makes mention of throttling events using SNMP and
Syslog.  What about the local log?  Are events written to the local log
not subject to throttling?  
[s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle'
was to limit the throttling of events to the network (esp. in
power-up-after-a-blackout scenario), not locally.

Regarding local logging of events:
- the MTAs are currently required to store 2^31 events (in the local
log) and if we have questions regarding the size we should change the
index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?)

- Further, if we want to throttle local logging, we should probably
define a new MIB Object for local events only (since the throttling
conditions would vary between network and local storage) - thoughts?

#2:
- pktcDevEventDescrText and pktcDevEventDescrClass - These objects are
read-write.  It seems odd to me that these objects would be writable.
Is it really intended that these are writable objects?
[s] Yes, this is intended since an operator could change the
'Description of an event' to better suit 'Operational specific values'
(via SNMP or by using the configuration file at bootstrapping time).
E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP
response to the MTA due to XYZ' into a shortened string such as
'TFTP-ERR:XYZ'.

>>> FYI <<<
I am working on a couple of other comments, but the following (mostly
from Greg and some internal) have been incorporated as-is:

There are a number of places in the document that makes reference to
"PacketCable device".  Shouldn't this be "PacketCable or IPCablecom
device"?  Or more simply "MTA device".

The naming convention we've been using on other MIB modules in IPCDN
adds "-IETF-" to the module name to distinguish it from the
corresponding MIB module being developed in CableLabs.  So, it this
case, the MIB module name should be something like
"PKTC-IETF-EVENT-MIB".

I think the ORGANIZATION clause should be IPCDN rather than CableLabs.

The DESCRIPTION clause is missing the mandatory copyright notice.

pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause
states "... Defined by PacketCable by default."  Should this just
PacketCable or PacketCable and IPCablecom.

pktcDevEvThrottleAdminStatus
- "A value of stopAtThreshold(3) causes event message transmission to
cease at the threshold, and not resume until directed to do so." How is
the device directed to resume sending event messages?

pktcDevEvThrottleInterval  - The DEFVAL clause should be on a separate
line for readability.

pktcDevEventDescrTable - Should the reference to "PacketCable" be
"PacketCable/IPCablecom"?

pktcDevEventDescrId - "The event identifier can either be PacketCable
defined or vendor-specific." Would be good to provide a reference to the
PacketCable spec where the events are defined.

pktcDevEventDescrReporting - Should define what each one of the bit
values mean.

pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]"  Reference [3]
doesn't exist in the references section.

pktcDevEvLogCorrelationId
     "This MIB Object contains the correlation ID 
     generated by the MTA during the initiation of the
     last provisioning flow, within or following which
     the event occurred. 
     For information on the generation of correlation ids,
     refer to the corresponding PacketCable/IPCableCom
     Device Provisioning specifications."

[PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable"

Reference section - There are number of reference in the body of the
text that do not exist in the references section.  Need to make sure all
reference are cited.  The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA,
PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119.

Security Considerations - Per the MIB Guidelines, need to explicit
discuss all MIB objects, even if to only state that there are no
security issues with the object.

- There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have
MIB Objects for 2 and 4)

- The Reference in the description of the MIB Object
'pktcDevEvLogCorrelationId' seems to be out of place.

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

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Tue, 18 Oct 2005 18:59:37 -0700

Sumanth,

Regarding item #1...

Are MTAs really required to store 2^31 events?  That seems like a lot.  I'd be surprised that an MTA has that much memory. 

If it can store 2^31 events, I suppose throttling isn't as important.  Otherwise, assuming memory is much more limited, I would think the ability to throttle is desirable.  Having a separate object to control local throttling seems OK to me.

greg  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Tuesday, October 18, 2005 2:59 PM
To: [email-masked]
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Folks,

I haven't received any comments on the clarifications requested (dated 10/07, enclosed in this email). Can I assume acceptance (status quo) on
#1 and #2? 

Other than the clarifications, I am planning to check with the co-authors (and others in IPCDN) about Greg's comments regarding the MIB structure not conforming to the recommendations of RFC4181. The rest I believe, have been addressed as recommended.

Pending any other last minute comments, I plan to submit draft-05 by the end of this work-week (to meet the deadline).

- S

-----Original Message-----
From: Sumanth Channabasappa
Sent: Friday, October 07, 2005 3:21 PM
To: Eugene Nechamkin; Randy Presuhn; [email-masked]
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Greg, Randy, Eugene,

#1:
- The description makes mention of throttling events using SNMP and Syslog.  What about the local log?  Are events written to the local log not subject to throttling?  
[s] The objective of the MIB Objects belonging to 'pktcDevEventThrottle'
was to limit the throttling of events to the network (esp. in power-up-after-a-blackout scenario), not locally.

Regarding local logging of events:
- the MTAs are currently required to store 2^31 events (in the local
log) and if we have questions regarding the size we should change the index value 'pktcDevEvLogIndex' (suggestions anyone, MTA vendors?)

- Further, if we want to throttle local logging, we should probably define a new MIB Object for local events only (since the throttling conditions would vary between network and local storage) - thoughts?

#2:
- pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write.  It seems odd to me that these objects would be writable.
Is it really intended that these are writable objects?
[s] Yes, this is intended since an operator could change the 'Description of an event' to better suit 'Operational specific values'
(via SNMP or by using the configuration file at bootstrapping time).
E.g. MSO XYZ could change a lengthy description such as 'Error in TFTP response to the MTA due to XYZ' into a shortened string such as 'TFTP-ERR:XYZ'.

>>> FYI <<<
I am working on a couple of other comments, but the following (mostly from Greg and some internal) have been incorporated as-is:

There are a number of places in the document that makes reference to "PacketCable device".  Shouldn't this be "PacketCable or IPCablecom device"?  Or more simply "MTA device".

The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs.  So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB".

pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default."  Should this just PacketCable or PacketCable and IPCablecom.

pktcDevEvThrottleAdminStatus
- "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages?

pktcDevEvThrottleInterval  - The DEFVAL clause should be on a separate line for readability.

pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"?

pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined.

pktcDevEventDescrReporting - Should define what each one of the bit values mean.

pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]"  Reference [3] doesn't exist in the references section.

Reference section - There are number of reference in the body of the text that do not exist in the references section.  Need to make sure all reference are cited.  The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119.

Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object.

- There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4)

- The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place.

---

From: "Eduardo Cardona" <[email-masked]>
Date: Wed, 19 Oct 2005 11:21:47 -0600

That is probably a problem inherited from RFC 2669 where those objects
were derived

   docsDevEvThrottleAdminStatus OBJECT-TYPE
           SYNTAX INTEGER {
               unconstrained(1),
               maintainBelowThreshold(2),
               stopAtThreshold(3),
               inhibited(4)
           }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION
               "Controls the transmission of traps and syslog messages
                with respect to the trap pacing threshold. 

....

I believe an event is throttle by the rate of events the system is
handling not the manifestation of them as outputs (I think this is
Randy's point) 

Then, the dispatch flag (AND/OR local/syslog/snmp notif)  is applied to
whatever target protocols are intended after the event rate throttling

In other words, throttling only regulates the rate of events to be
handled over dispatchers, the manifestation of "events on the wire"
depends on how targets are configured. As an example in SNMPv3 a
notification may match in the snmpNotifyTable n targets as traps and/or
informs:

Some figures: 
If you wan to throttle one event per minute and you have a match of
2 trap targets and 1 Inform target (receiver off) with 3 retries

You can see up to 5 notifications on the wire per minute. ( not the 1
per minute you have though it will)
 
Unfortunately RFC 2669 had a monolithic perception of things and was
before SNMPv3 multiple targets were adopted. We didn't mentioned in
DOCSIS what happen with local log explicitly probably following the
rationale of the Throttle MIB objects, but I believe that is
inappropriate. There is no MUST requirements that says local-log events
MUST not be throttle.
  , so that's probably the rationale of leave local-log throttle as
vendor dependent (?) 

Or just normalize explicitly the requirement for local-log also be
throttled ( I can think on that option as my preference, others may have
a different perception)

Eduardo

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2005 8:36 PM
To: [email-masked]
Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Hi -

> From: "Sumanth Channabasappa" <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, October 18, 2005 2:58 PM
...
> I haven't received any comments on the clarifications requested (dated
> 10/07, enclosed in this email). Can I assume acceptance (status quo)
on
> #1 and #2? 

You must have missed my response from two months ago:

|From: [email-masked] [mailto:[email-masked]] On Behalf
Of
|Randy Presuhn
|Sent: Thursday, August 18, 2005 3:59 PM
|To: [email-masked]
|Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt
|
|Hi -
|
|> From: "Sumanth Channabasappa" <[email-masked]>
|> To: "Jean-Francois Mule" <[email-masked]>; "Nakanishi 
|> Greg-MGI8179" <[email-masked]>; <[email-masked]>
|> Sent: Thursday, August 18, 2005 11:46 AM
|> Subject: RE: [ipcdn] Comments on 
|> draft-ietf-ipcdn-pktc-eventmess-04.txt
|...
|> 8) pktcDevEvThrottleAdminStatus
|> - The description makes mention of throttling events using SNMP and 
|> Syslog.  What about the local log?  Are events written to the local 
|> log not subject to throttling?
|...
|
|I'd suggest that if we don't leave it up to the implementation, that it
would
|be best for throttling to affect all destinations equally.  Swamped
logs are
|the same kind of problem, whether on the local system or a remote one.
|
|Randy

The code issuing a notification, which is where the DESCRIPTION clause
would lead implementors to put the throttling logic, would in a
reasonably
modular environment have no knowledge of whether it is going to a local
log, delivery over some protocol, or whatever.

Randy

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Wed, 19 Oct 2005 14:17:00 -0600

Randy,

Thanks and no, I did not miss your response. However, the MIB is geared
towards 'management events' (and their management) and the resulting
'notifications' are only a reporting feature. Thus, MTAs are required
to:
- store all relevant event information in the logs (storage allowing)
- send only critical (or desired) notifications, created upon event
generation to the external systems (syslog, SNMP)

Now, implementations could, as you suggested, have notifications
generated agnostic of the destination. 
However, in this case, the 'event generation and storage' is required
(it may overwrite earlier events, but current events are always stored),
with an option to convert them into 'notifications', if configured. 

Further, given the disparity between the Service Provider Network
elements (few) and the clients on which this MIB will be
implemented(many), the throttling requirements for 'notifications sent
to the network' were imposed. Currently, there has been no intention or
requirement to throttle events that can be stored locally.

Thanks for the pointer on RFC3014 - I shall take a look at it and see if
we can borrow any concepts.

Greg,
Barring the max size discussion (I should have clarified further, thanks
Eduardo), do we really see a need for throttling local events (would it
serve any purpose if the latest events are always stored)?

- S

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2005 8:36 PM
To: [email-masked]
Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Hi -

...

|Of Randy Presuhn

|would be best for throttling to affect all destinations equally.  
|Swamped logs are the same kind of problem, whether on the local system
or a remote one.
|
|Randy

The code issuing a notification, which is where the DESCRIPTION clause
would lead implementors to put the throttling logic, would in a
reasonably modular environment have no knowledge of whether it is going
to a local log, delivery over some protocol, or whatever.

Randy

---

From: Nakanishi Greg-MGI8179 <[email-masked]>
Date: Wed, 19 Oct 2005 14:18:07 -0700

Sumanth,

My opinion is that throttling should to be supported for the local log.  If the local log is small, there is a potential for the log to get filled up with a flood of events and earlier events that may be important for analysis gets overwritten.  

That being said, I can see that historically (in DOCSIS and PacketCable) local log throttling was not specified.  I don't have particularly strong feelings about this, but I think local log throttling would be a desirable feature.

greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sumanth Channabasappa
Sent: Wednesday, October 19, 2005 1:17 PM
To: [email-masked]
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Randy,

Thanks and no, I did not miss your response. However, the MIB is geared towards 'management events' (and their management) and the resulting 'notifications' are only a reporting feature. Thus, MTAs are required
to:
- store all relevant event information in the logs (storage allowing)
- send only critical (or desired) notifications, created upon event generation to the external systems (syslog, SNMP)

Now, implementations could, as you suggested, have notifications generated agnostic of the destination. 
However, in this case, the 'event generation and storage' is required (it may overwrite earlier events, but current events are always stored), with an option to convert them into 'notifications', if configured. 

Further, given the disparity between the Service Provider Network elements (few) and the clients on which this MIB will be implemented(many), the throttling requirements for 'notifications sent to the network' were imposed. Currently, there has been no intention or requirement to throttle events that can be stored locally.

Thanks for the pointer on RFC3014 - I shall take a look at it and see if we can borrow any concepts.

Greg,
Barring the max size discussion (I should have clarified further, thanks Eduardo), do we really see a need for throttling local events (would it serve any purpose if the latest events are always stored)?

- S

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Tuesday, October 18, 2005 8:36 PM
To: [email-masked]
Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Hi -

...

The code issuing a notification, which is where the DESCRIPTION clause would lead implementors to put the throttling logic, would in a reasonably modular environment have no knowledge of whether it is going to a local log, delivery over some protocol, or whatever.

Randy

---

From: "Sumanth Channabasappa" <[email-masked]>
Date: Thu, 20 Oct 2005 16:13:27 -0600

Greg,

Thanks for the thoughts and unless vendors/implementors feel strongly
about local throttling, I would be inclined to leave it out scope for
now (akin to other IPCDN MIBs - as you rightly indicated). 

- S 

-----Original Message-----
From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2005 3:18 PM
To: Sumanth Channabasappa; [email-masked]
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Sumanth,

My opinion is that throttling should to be supported for the local log.
If the local log is small, there is a potential for the log to get
filled up with a flood of events and earlier events that may be
important for analysis gets overwritten.  

That being said, I can see that historically (in DOCSIS and PacketCable)
local log throttling was not specified.  I don't have particularly
strong feelings about this, but I think local log throttling would be a
desirable feature.

greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sumanth Channabasappa
Sent: Wednesday, October 19, 2005 1:17 PM
To: [email-masked]
Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Randy,

Greg,

- S

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]]
Sent: Tuesday, October 18, 2005 8:36 PM
To: [email-masked]
Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt

Hi -

...

Randy