Subject: [Syslog] Alarm MIB in syslog-protocol

From: Chris Lonvick <[email-masked]>
Date: Fri, 3 Nov 2006 09:33:42 -0800 (PST)

Hi,

In David Harrington's review of syslog-protocol-17
   http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html
he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877).  We 
discussed this a while ago and it doesn't seem that there is a good fit 
between the historical syslog severities and the Alarm MIBs.  I've asked 
Rainer to remove this.  Anyone interested is hereby encouraged to write a 
document that specifies how to display the Alarm MIBs as Structured Data.

Thanks,
Chris

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

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 3 Nov 2006 12:43:08 -0500

Hi

This is an important section (and no, I'm not just saying that because I
co-authored RFC 3877). It provides the mapping between severities in
alarms sent via SNMP and those logged in syslog. Removing it means that
implementations will all have different mappings.

Sharon

-----Original Message-----
From: Chris Lonvick [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 12:34 PM
To: [email-masked]
Subject: [Syslog] Alarm MIB in syslog-protocol

Hi,

In David Harrington's review of syslog-protocol-17
   http://www1.ietf.org/mail-archive/web/syslog/current/msg01145.html
he asked about the Alarm MIB - Section 6.2.1.1 (from RFC3877).  We
discussed this a while ago and it doesn't seem that there is a good fit
between the historical syslog severities and the Alarm MIBs.  I've asked
Rainer to remove this.  Anyone interested is hereby encouraged to write
a document that specifies how to display the Alarm MIBs as Structured
Data.

Thanks,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 3 Nov 2006 10:25:36 -0800 (PST)

Hi Sharon,

It's an important concept but I feel that it is underspecified and 
ambiguous in the current document.  The recipent of a message with the 
Severity of Notice would not be able to tell if the sender intended for it 
to be the ITU alarm of Indeterminate or Cleared.  I believe that this part 
was specified before the concept of Structured Data was included in 
syslog-protocol.  Using Structured Data would disambiguate the intention.

Thanks,
Chris

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 3 Nov 2006 14:32:58 -0500

Hi

Actually, no structured data was already in the draft when this was
added. 

At the time, the working group discussed the lossy nature of the
mapping, determined it was inevitable, looked at the various ways the
mapping could be constructed and settled on the one which lost the least
important bit of information.

Perhaps a note indicating that this mapping is lossy and that
implementations that want to be able to do a fully reversible mapping
should consider also sending the alarm/ITU severity within the syslog
message. I don't believe we need to indicate how in this document. Just
indicate that we recognize the issue and hint at how to solve it. Sort
of like a security considerations section.

Even if people have some extra field, they still need to know what to do
with the severity field syslog. I view this as no different then the
mapping to ifAdmin and ifOper status we did when we did the Entity State
MIB.
	http://www.ietf.org/rfc/rfc4268.txt?number=4268

Sharon 

-----Original Message-----
From: Chris Lonvick [mailto:[email-masked]] 
Sent: Friday, November 03, 2006 1:26 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: RE: [Syslog] Alarm MIB in syslog-protocol

Hi Sharon,

It's an important concept but I feel that it is underspecified and
ambiguous in the current document.  The recipent of a message with the
Severity of Notice would not be able to tell if the sender intended for
it to be the ITU alarm of Indeterminate or Cleared.  I believe that this
part was specified before the concept of Structured Data was included in
syslog-protocol.  Using Structured Data would disambiguate the
intention.

Thanks,
Chris

On Fri, 3 Nov 2006, Sharon Chisholm wrote:

> Hi
>
> This is an important section (and no, I'm not just saying that because

> I co-authored RFC 3877). It provides the mapping between severities in

> alarms sent via SNMP and those logged in syslog. Removing it means 
> that implementations will all have different mappings.
>
> Sharon
>
> discussed this a while ago and it doesn't seem that there is a good 
> fit between the historical syslog severities and the Alarm MIBs.  I've

> asked Rainer to remove this.  Anyone interested is hereby encouraged 
> to write a document that specifies how to display the Alarm MIBs as 
> Structured Data.
>
> Thanks,
> Chris
>

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 3 Nov 2006 12:37:31 -0800 (PST)

Hi Sharon,

> of like a security considerations section.

We have a mechanism defined to address the issue properly.  Why would we 
want to underspecify this standard (syslog-protocol) by just giving a hint 
of how to do it right?  If it is going to be done, then it needs to be 
done properly and completely, which means fully specifying how to indicate 
the true ITU severity within structured data.  However, I don't want to 
delay this document by doing it here at this time.

What's wrong with putting this in a separate document?

Thanks,
Chris

---

From: "tom.petch" <[email-masked]>
Date: Wed, 8 Nov 2006 12:31:36 +0100

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "Sharon Chisholm" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, November 03, 2006 9:37 PM
Subject: RE: [Syslog] Alarm MIB in syslog-protocol

> What's wrong with putting this in a separate document?

I am with Sharon with this.  The information is not perfect but it is the best
we can do and, for me, it is near enough right to be worth including, perhaps
with a caveat that the nature of syslog and the nature of the ITU-T means that
the mapping cannot be perfect.

Tom Petch