headers
Wijnen, Bert (Bert | 9 Oct 2006 13:01
Picon
Favicon

Syslog Protocol document and Alarm MIB

Since the Alarm MIB was done in this WG, you may want to
take a look at section 6.2.1.1 of document 
   draft-ietf-syslog-protocol-17.txt

It says:

   6.2.1.1.  Relation to Alarm MIB

   The Alarm MIB RFC3877 [11] defines ITU perceived severities which are
   useful to be able to relate to the syslog severities, particularly in
   the case where alarms are being logged.  The ITUPerceivedSeverity
   corresponds to a syslog Severity as shown in table 2 below.

              ITU Perceived Severity      syslog SEVERITY
              Critical                    Alert
              Major                       Critical
              Minor                       Error
              Warning                     Warning
              Indeterminate               Notice
              Cleared                     Notice

           Table 3. ITUPerceivedSeverity to syslog SEVERITY mapping.

I think this is OK. But wanted to make sure we have all had a chance to
look at it and make a comment if you think it is not OK. Probably best to
then also copy such comment to the syslog <at> ietf.org mailing list.

Bert
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sharon Chisholm | 9 Oct 2006 19:19
Favicon

RE: Syslog Protocol document and Alarm MIB

Hi

I actually drafted the initial version of text for this section, but of
course, it would be good to get the views of the working group itself to
ensure it makes sense. After my initial mapping, there was some working
syslog working group discussion and some modifications were make. The
problem is that a perfect mapping can't be made and so you have to
decide which part of the mapping you are willing to less then ideal.

Sharon 

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com] 
Sent: Monday, October 09, 2006 7:02 AM
To: Disman (E-mail) (E-mail)
Subject: [Disman] Syslog Protocol document and Alarm MIB

Since the Alarm MIB was done in this WG, you may want to take a look at
section 6.2.1.1 of document 
   draft-ietf-syslog-protocol-17.txt

It says:

   6.2.1.1.  Relation to Alarm MIB

   The Alarm MIB RFC3877 [11] defines ITU perceived severities which are
   useful to be able to relate to the syslog severities, particularly in
   the case where alarms are being logged.  The ITUPerceivedSeverity
   corresponds to a syslog Severity as shown in table 2 below.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Romascanu, Dan (Dan | 15 Oct 2006 19:43
Favicon

RE: Syslog Protocol document and Alarm MIB

I personally find a lot of value in the path taken by the syslog
protocol document. Our implementation experience is that a consistent
definition of alarm severities transported by various management
protocols is important in real life deployments, and the ITU perceived
severity as defined in the IETF by the Alarm MIB TC is useful and usable
for most practical purposes. 

Dan

> -----Original Message-----
> From: Sharon Chisholm [mailto:schishol <at> nortel.com] 
> Sent: Monday, October 09, 2006 7:20 PM
> To: Wijnen, Bert (Bert); Disman (E-mail) (E-mail)
> Subject: RE: [Disman] Syslog Protocol document and Alarm MIB
> 
> Hi
> 
> I actually drafted the initial version of text for this 
> section, but of course, it would be good to get the views of 
> the working group itself to ensure it makes sense. After my 
> initial mapping, there was some working syslog working group 
> discussion and some modifications were make. The problem is 
> that a perfect mapping can't be made and so you have to 
> decide which part of the mapping you are willing to less then ideal.
> 
> Sharon 
> 
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen <at> lucent.com]
> Sent: Monday, October 09, 2006 7:02 AM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 27 Oct 2006 21:11
Picon

DISMAN-PING-MIB questions: default address type, message interval and pingCtlDSField


I'm implementing a manager that uses the DISMAN-PING-MIB, and
have three questions.

1. RFC 4560 says:
          A single SNMP PDU can be used to create and start a remote
   ping test.  Within the PDU, pingCtlTargetAddress should be set to the
   target host's address (pingCtlTargetAddressType will default to
   ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to
   createAndGo(4).
However, the DEFVAL of pingCtlTargetAddressType is unknown, and
that's the value that the agent I'm testing against uses when you
don't specify it.  It seems that the agent is right, based on the
MIB, and the text that says that the addresstype has a default of
ipv4(1) is wrong?

2. There's no object that explicitly talks about the interval between
probes when the probe is successful.  If I set pingCtlProbeCount=15 and
leave pingCtlTimeOut=3, I naively assumed that when the probe response
was received, it would wait less time (I assumed 1 second, since that's
what UNIX ping defaults to) to send the next probe.  I thought that
partly because of the wording in section 3.1.2:

   Using the maximum value for the parameters defined within a pingEntry
   can result in a single remote ping test's taking at most 15 minutes
   (pingCtlTimeOut times pingCtlProbeCount), plus whatever time it takes
   to send the ping request and to receive its response over the network
   from the target host.

If the probes are always spaced pingCtlTimeOut (plus RTT) apart, then
(Continue reading)

Permalink | Reply | 3 comments |
headers
Randy Presuhn | 27 Oct 2006 22:30
Picon

Re: DISMAN-PING-MIB questions: default address type, message interval and pingCtlDSField

Hi -

> From: "Bill Fenner" <fenner <at> research.att.com>
> To: <disman <at> ietf.org>
> Sent: Friday, October 27, 2006 12:11 PM
> Subject: [Disman] DISMAN-PING-MIB questions: default address type,message interval and pingCtlDSField
>
>
> I'm implementing a manager that uses the DISMAN-PING-MIB, and
> have three questions.
>
> 1. RFC 4560 says:
>           A single SNMP PDU can be used to create and start a remote
>    ping test.  Within the PDU, pingCtlTargetAddress should be set to the
>    target host's address (pingCtlTargetAddressType will default to
>    ipv4(1)), pingCtlAdminStatus to enabled(1), and pingCtlRowStatus to
>    createAndGo(4).
> However, the DEFVAL of pingCtlTargetAddressType is unknown, and
> that's the value that the agent I'm testing against uses when you
> don't specify it.  It seems that the agent is right, based on the
> MIB, and the text that says that the addresstype has a default of
> ipv4(1) is wrong?

It looks like this is a long-standing error in the document.  The same
problem exists in RFC 2925.  The error was introduced in the changes
from draft-ietf-disman-remops-mib-07.txt to produce the draft
draft-ietf-disman-remops-mib-08.txt. in August / Spetember of 2000.
The only relevant discussion I could find is in Ken White's
message of August 28, 1999 (see ftp://ftp.ietf.org/ietf-mail-archive/disman/)
and that doesn't explain why the change was made to the DEFVAL.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Fenner | 28 Oct 2006 06:19
Picon

Re: DISMAN-PING-MIB questions: default address type, message interval and pingCtlDSField


Thanks for the answers, Randy.

[DEFVAL for pingCtlTargetAddressType]
>I can see two ways to correct this.  Either would result in an erratum:
>  a) fix the DEFVAL, since the change wasn't agreed in the WG
>      as far as I can tell (please correct me if I'm wrong and just
>      couldn't find or remember the discussion).
>  b) fix the single-PDU text.  someone will need to count the bytes
>      to see if the additional varbind would take us over the limit.

I only have experience with one implementation, but it uses the DEFVAL
specified in the MIB, which seems like an eminently reasonable thing
to do - so to avoid making reasonable implementations non-compliant,
I think option b might be better.  I don't know what the limit is, but
an SNMPv2c set with the following
varbinds:

DISMAN-PING-MIB::pingCtlTargetAddressType."12345678901234567890123456789012"."12345678901234567890123456789012"
= INTEGER:
ipv4(1)
DISMAN-PING-MIB::pingCtlTargetAddress."12345678901234567890123456789012"."12345678901234567890123456789012"
= Hex-STRING: 04 02 02
02
DISMAN-PING-MIB::pingCtlAdminStatus."12345678901234567890123456789012"."12345678901234567890123456789012"
= INTEGER:
enabled(1)
DISMAN-PING-MIB::pingCtlRowStatus."12345678901234567890123456789012"."12345678901234567890123456789012"
= INTEGER: createAndGo(4)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bill Fenner | 29 Oct 2006 22:37
Picon

Re: DISMAN-PING-MIB questions: default address type, message interval and pingCtlDSField


I wrote:
>I'm reading "Using the maximum values, you can expect the test
>to take at most 15 minutes plus...".

And if I wasn't being so stubborn, I would have realized that was
true.  If the final probe succeeds, it will take 14 minutes plus...;
if it times out it will take 15 minutes plus...

I apologize for being dense.  It takes some work to switch from
the UNIX ping model of "send a packet every second and collect
the results asynchronously".

  Bill
Permalink | Reply | 0 comments |

Gmane