[Syslog] Protocol Action: 'Alarms in SYSLOG' to Proposed Standard (fwd)

Hi Folks,

Many thanks to the people who helped put this together and get it through 
the process.

Regards,
Chris

---------- Forwarded message ----------
Date: Mon, 31 Aug 2009 10:24:31 -0700 (PDT)
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
     RFC Editor <rfc-editor@rfc-editor.org>
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.txt

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