Hi Sharon,
On Fri, 3 Nov 2006, Sharon Chisholm wrote:
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.
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
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 PROTECTED]
Sent: Friday, November 03, 2006 1:26 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [EMAIL PROTECTED]
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
-----Original Message-----
From: Chris Lonvick [mailto:[EMAIL PROTECTED]
Sent: Friday, November 03, 2006 12:34 PM
To: [EMAIL PROTECTED]
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
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
