[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-00.txt

HI Mike,

On Tuesday, February 11, 2003, at 04:52 AM, C. M. Heard wrote:

On Fri, 7 Feb 2003, Harrie Hazewinkel wrote:
That is true, and it's the reason why Bert has insisted on including
the mailing list information as well (mailing lists usually survive
for a while after the WG concludes).  On the other hand, mailing lists
are sometimes rehosted while the WG is still active, and in those cases
having a pointer to the charter page (which has the mailing list
information, and well as other useful stuff) can be helpful to those
seeking answers to questions.
I see.  In all cases there is no final solution.

Add extra note that it is NOT advised to use this number when a product
of it is shipped. Although, this is not for reviewers, more for
If you don't mind too much, I'd rather not add that.  The document
is already too big, so I really don't want to stray off topic.
I understand.

You will notice that I do mention SnmpAdminString, which is the
"standard" UTF-8 replacement for DisplayString.

In separate comments, Bert Wijnen has asked me to remove mention here
of DisplayString and to point out in Appendix D that it is not to be
used in new MIB modules because it does not support i18n.  When I
put those changes into Appendix D I will state that SnmpAdminString
is the "approved" replacement because it supports UTF-8.

Will that take care of these concerns?

A side note, (note for this document) would it be allowed then
to replace TC representing UTF-8 with the SnmpAdminString TC??

4.7. Notification Definitions

One mechanism that has been widely used is to require
the notification generator to use throttling -- that is, to ensure
that no more than one notification is generated for each event source
in any given time interval of duration T. The throttling period T
MAY be configurable, in which case it would be specified in a MIB
object, or it MAY be fixed, in which case it would be specified in
the notification definition. Examples of the second technique can be
found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB

Why mentioning the first and referring to the second?? Does the
SNMP-REPEATER-MIB not use the time interval and thus the first
No, the SNMP-REPEATER-MIB is an example of the second approach, because
the interval is fixed (not configurable).  Each notification definition
in 2108 specifies that the throttling period must be at least five
seconds, and there is no MIB object to control it.
Hmm, I did not see the possibility of a configurable time interval
against a fixed time interval as different. The notification
initiation is simply time interval controlled.
What if there would be such a time interval control object and
is implemented read-only. You have the combination of both.
While rereading it, I even noticed that you already mention
the time interval MAY be configurable or MAY be fixed.

I would think a different approach would be notification throttling
based on amount of notifications. For instance, for each 100 traps
you only sent 1.

But since there are many solutions for throttling, I would think
that mentioning one is enough. If people need different throttling
techniques they will use it anyway. These are guidelines after all.

If you find the text confusing and would like for it to be cleaned up, it
would be helpful to me if you could propose specific changes to the text.
What about this:
   Examples of the second technique can be
   found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB

changes into

   Examples of the fixed time interval can be
   found in the SNMP-REPEATER-MIB [RFC2108] and in the ENTITY-MIB

Makes it more clear.

ciao, ciao,

Author of MOD-SNMP, enabling SNMP management of Apache HTTP server