[OPSAWG] FW: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 01 September 2009 12:21 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: opsawg@core3.amsl.com
Delivered-To: opsawg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E8628C6DD for <opsawg@core3.amsl.com>; Tue, 1 Sep 2009 05:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWOKXM+XhWKd for <opsawg@core3.amsl.com>; Tue, 1 Sep 2009 05:21:32 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 1E4402944BB for <opsawg@ietf.org>; Tue, 1 Sep 2009 05:11:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,311,1249272000"; d="scan'208";a="181865209"
Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Sep 2009 08:11:41 -0400
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 01 Sep 2009 08:11:41 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 01 Sep 2009 14:11:20 +0200
Message-ID: <EDC652A26FB23C4EB6384A4584434A04019CB283@307622ANEX5.global.avaya.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard
Thread-Index: AcoqYAaCI3biZjSyTMC+IsPtVRqJZwAnUKUQ
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: opsawg@ietf.org
Subject: [OPSAWG] FW: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 12:21:33 -0000

Congratulations to the editors, chairs and the whole WG for the approval
of this document. 

Regards,

Dan 

-----Original Message-----
From: ietf-announce-bounces@ietf.org
[mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
Sent: Monday, August 31, 2009 8:25 PM
To: IETF-Announce
Cc: Internet Architecture Board; RFC Editor
Subject: Protocol Action: 'Alarms in SYSLOG' to Proposed Standard

The IESG has approved the following document:

- 'Alarms in SYSLOG '
   <draft-ietf-opsawg-syslog-alarm-02.txt> as a Proposed Standard


This document is the product of the Operations and Management Area
Working Group. 

The IESG contact persons are Dan Romascanu and Ron Bonica.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsawg-syslog-alarm-02.tx
t

Technical Summary

   This document describes how to send alarm information in syslog.  It
   includes the mapping of ITU perceived severities onto syslog message
   fields and a number of alarm-specific SD-PARAM definitions from X.733
   and the IETF Alarm MIB.

Working Group Summary

   The document was revised based on WG feedback & the result meets
   the issues that were raised.

Document Quality

   SYSLOG is widely implemented and deployed, and the ITU severities are

   used by a number of protocols and alarm models including the IETF 
   Alarm MIB. 

Personnel

   Scott Bradner is the Document Shepherd for this document.  Dan 
   Romascanu is the Responsible Area Director.

RFC Editor Note

Please insert the following edits in the published version: 

1. In section 1, 

Old:Alarm related terminology is defined in [RFC3877].


New:Alarm related terminology is defined in [RFC3877].

SD-ID, SD-PARM and other syslog related terms are defined in [RFC5424] 


2. In section 3

Old: the SD-PARARMS are mandatory.

New: the SD-PARAMS are mandatory.

 

3. In section 3.6

Old: [RFC1738] and its updates.  In the case of an SNMP resource, the

New: [RFC3986] and its updates.  In the case of an SNMP resource, the

 

4. In section 4

Old: In this example, extended from [Syslog], the VERSION is 1 and the
New: In this example, extended from [RFC5424], the VERSION is 1 and the

OLD: 'APP-NAME is "su"'
NEW: 'APP-NAME is "evntslog"'

OLD: 'exampleSDID@0' 
NEW: 'exampleSDID@32473'

OLD: 'resourceURI =' 
NEW: 'resourceURI='

5. In section 6

Old: IANA is requested to register the SD-IDs

New: IANA is requested to register the syslog Structured Data ID Values

6. In section 8.1

Old:    [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill,
"Uniform
              Resource Locators (URL)", RFC 1738, December 1994.

New:    [RFC3986]  Berners-Lee, T., Fielding, R., and Masinter, L.,
"Uniform Resource Identifier (URI): Generic Syntax", RFC RFC3986,
January 2005.

7. In Section 3.1: 

OLD:  If the "alarm" SD-ID is supported, the "resource" SD-PARAM MUST be
   supported. 

NEW:  If the "alarm" SD-ID is included, the "resource" SD-PARAM MUST be
   included. 

8. In Section 3.2: 

OLD: If the "alarm" SD-ID is supported, the "probableCause" SD-PARAM
MUST


   be supported.

NEW: If the "alarm" SD-ID is included, the "probableCause" SD-PARAM MUST
   be included.

9. In Section 3.3: 

OLD: If the "alarm" SD-ID is supported, the "perceivedSeverity" SD-PARAM
   MUST be supported.

NEW: If the "alarm" SD-ID is included, the "perceivedSeverity" SD-PARAM
   MUST be included.

10. In Section 3.4:

OLD: If the "alarm" SD-ID is supported, the "eventType" SD-PARAM SHOULD
be supported. 

NEW: If the "alarm" SD-ID is included, the "eventType" SD-PARAM SHOULD
be included. 

11. In Section 3.5: 

OLD: If the "alarm" SD-ID is supported, the "trendIndication" SD-PARAM
   SHOULD be supported. 

NEW: If the "alarm" SD-ID is included, the "trendIndication" SD-PARAM
   SHOULD be included. 

12. In Section 3.6: 

OLD: If the "alarm" SD-ID is supported, the "resourceURI" SD-PARAM
SHOULD


   be supported.

NEW: If the "alarm" SD-ID is included, the "resourceURI" SD-PARAM SHOULD
   be included.

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce