[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Syslog] Alarm MIB in syslog-protocol
----- Original Message -----
From: "Chris Lonvick" <clonvick@cisco.com>
To: "Sharon Chisholm" <schishol@nortel.com>
Cc: <syslog@ietf.org>
Sent: Friday, November 03, 2006 9:37 PM
Subject: RE: [Syslog] Alarm MIB in syslog-protocol
>
> On Fri, 3 Nov 2006, Sharon Chisholm wrote:
>
> > 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?
>
> Chris
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
>
> >
> > 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:clonvick@cisco.com]
> > Sent: Friday, November 03, 2006 1:26 PM
> > To: Chisholm, Sharon (CAR:ZZ00)
> > Cc: syslog@ietf.org
> > 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:clonvick@cisco.com]
> >> Sent: Friday, November 03, 2006 12:34 PM
> >> To: syslog@ietf.org
> >> 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