Subject: [Syslog] Submission of draft-ietf-syslog-device-mib-12.txt

From: "Glenn M. Keeni" <[email-masked]>
Date: Thu, 21 Dec 2006 14:49:53 +0900

Hi,
    Attached please find the updated ID
          draft-ietf-syslog-device-mib-12.txt
This is a work of the ietf-syslog-wg.
I will appreciate it very much if you can
post this to the archives.

     Thanks.

     Glenn

Syslog Working Group                               Glenn Mansfield Keeni
INTERNET-DRAFT                                      Cyber Solutions Inc.
Intended Status: Proposed Standard
Expires: June 17, 2007                                 December 18, 2006

                   Syslog Management Information Base
                 <draft-ietf-syslog-device-mib-12.txt>

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This document is a product of the syslog Working Group. Comments
   should be addressed to the authors or the mailing list at
   [email-masked]

   This Internet-Draft will expire on June 17, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2006).

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 1]


Internet Draft                  syslogMIB                  December 2006

Abstract

   This memo defines a portion of the Management Information Base (MIB),
   the Syslog MIB, for use with network management protocols
   in the Internet community. In particular, the Syslog MIB will be
   used to monitor and control syslog entities.

Table of Contents

        1. The Internet-Standard Management Framework ....  3
        2. Background ....................................  3
        3. The MIB Design ................................  4
        4. The Syslog MIB ................................  6
        5. Security Considerations ....................... 32
        6. IANA Considerations ........................... 34
        7. References .................................... 34
        8  Acknowledgments ............................... 35
        9. Author's Addresses ............................ 36
       10. Full Copyright Statement ...................... 37
           Appendix ...................................... 39

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 2]


Internet Draft                  syslogMIB                  December 2006

1. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC 3410 [RFC3410].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).

   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2. Background

   Operating systems, processes and applications, collectively termed
   "facilities" in the following, generate messages indicating their own
   status or the occurrence of events. These messages are handled by
   what has come to be known as the syslog application[RFCPROT] or
   device [RFC3164]. In this document we refer to a syslog application
   or device as a syslog entity. A syslog entity sends and/or receives
   syslog messages. The reader is referred to [RFCPROT] for a
   description of the various roles of a syslog entity viz. "sender",
   "receiver", "relay" and "collector". The discussion in this document
   in general refers to a syslog entity. For exceptional cases the
   specific role of the syslog application will be mentioned.  [RFCUDPX]
   describes the UDP transport for the syslog protocol.

   This document defines a set of managed objects (MOs) that can be used
   to monitor a group of syslog entities.

   The SYSLOG-MIB can be used in conjunction with other MIB modules - in
   particular the Host Resources MIB[RFC2790]. The generic process
   related matters e.g. control and monitoring for status, resource
   usage etc. can be serviced by the corresponding entries in the Host
   Resources MIB.

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 3]


Internet Draft                  syslogMIB                  December 2006

                          +------+
                          | Ent1 |
                         /+------+
        Facility-1-->|  /
                  -->| /  +------+ /
        Facility-N-->|+---| Ent2 |------> Ent4
                  -->| \  +------+ \
      SyslogHost-N-->|  \
                         \+------+ /
                          | Ent3 |------> Ent5
                          +------+ \
                                    \

           facility-i: Facility originating the message (locally)
         Ent1,..,Ent5: Syslog entity
                       The syslog entities may be on the same host
                       or on different hosts.

                   Fig.1 Syslog Application Model

   The group of syslog entities modeled by the SYSLOG-MIB is shown in
   Fig.1.  One or more syslog entities which may be on the same host
   receive syslog messages from local facilities and from other syslog
   entities which may be on other hosts. The syslog entity receives the
   message and processes it. The processing will depend on internal
   configuration and may involve relaying the message to a syslog entity
   which may be on another host.

3. The MIB Design.

   The purpose of the SYSLOG-MIB is to allow the monitoring of a group
   of syslog entities. This requires managed objects representing the
   following elements.

   o  The default configuration parameters for the group of
      syslog entities e.g. maximum message size, type of
      transport, port numbers on which the entity will listen
      for messages, etc.
   o  The configuration and status related details of each
      syslog entity.
   o  The statistics on syslog messages received, processed
      locally, relayed by each syslog entity.

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 4]


Internet Draft                  syslogMIB                  December 2006

   The MIB contains four subtrees.
   o  The syslogSystem subtree services the default configuration
      parameters.
   o  The syslogEntity subtree consists of the following tables.
      - SyslogEntityControlTable deals with the configuration and
        control information for a syslog entity.
      - SyslogEntityOperationsTable deals with operations and
        statistical information about messages processed by a
        syslog entity.
   o  The syslogNotifications subtree defines the set of
      notifications that will be used to asynchronously report
      the status of a syslog entity.
   o  The conformance subtree defines the compliance statements.

   The SYSLOG-MIB module uses textual conventions defined in INET-
   ADDRESS-MIB[RFC4001], TRANSPORT-ADDRESS-MIB[RFC3419] and SNMP-
   FRAMEWORK-MIB[RFC3411].

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 5]


Internet Draft                  syslogMIB                  December 2006

4.  The Syslog MIB

   SYSLOG-MIB DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-TYPE,
                 Unsigned32, Counter32, Integer32, mib-2,
                 zeroDotZero, NOTIFICATION-TYPE
                 FROM SNMPv2-SMI
       RowStatus, StorageType,
       TEXTUAL-CONVENTION, TimeStamp
                 FROM SNMPv2-TC
       InetAddressType, InetAddress
                 FROM INET-ADDRESS-MIB
       transportDomainUdpIpv4, TransportDomain
                 FROM TRANSPORT-ADDRESS-MIB
       MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
                 FROM SNMPv2-CONF
       SnmpAdminString
                 FROM SNMP-FRAMEWORK-MIB;

   syslogMIB  MODULE-IDENTITY
       LAST-UPDATED "200610230000Z"  -- 23th October, 2006
       ORGANIZATION "IETF Syslog Working Group"
       CONTACT-INFO
       "                      Glenn Mansfield Keeni
                      Postal: Cyber Solutions Inc.
                              6-6-3, Minami Yoshinari
                              Aoba-ku, Sendai, Japan 989-3204.
                         Tel: +81-22-303-4012
                         Fax: +81-22-303-4015
                      E-mail: [email-masked]

        Support Group E-mail: [email-masked]
        "

       DESCRIPTION
           "The MIB module for monitoring syslog entities.

            In this MIB we refer to a syslog application
            or device as a syslog entity. A syslog entity sends
            and/or receives syslog messages. The reader is referred
            to [RFCPROT] for a description of the various roles
            of a syslog entity viz. ''sender'', ''receiver'',

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 6]


Internet Draft                  syslogMIB                  December 2006

            ''relay'' and ''collector''. The discussion in this
            document in general refers to a syslog entity. For
            exceptional cases the specific role of the syslog
            application will be mentioned.

            Copyright (C) The Internet Trust (2006). This version of
            this MIB module is part of RFC XXXX; see the RFC itself for
            full legal notices.
           "
      -- RFC Ed.: replace XXXX with the actual RFC number & remove this
      -- note

       REVISION "200610230000Z"  --  23rd October, 2006
       DESCRIPTION
           "The initial version, published as RFC XXXX."

      -- RFC Ed.: replace XXXX with the actual RFC number & remove this
      -- note

       ::= { mib-2 YYYY }     -- Will be assigned by IANA

      -- IANA Reg.: Please assign a value for "YYYY" under the
      -- 'mib-2' subtree and record the assignment in the SMI
      -- Numbers registry.

      -- RFC Ed.: When the above assignment has been made, please
      --     remove the above note
      --     replace "YYYY" here with the assigned value and
      --     remove this note.

   -- -------------------------------------------------------------
   -- Textual Conventions
   -- -------------------------------------------------------------

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 7]


Internet Draft                  syslogMIB                  December 2006

   SyslogFacility  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This textual convention enumerates the facilities
            that originate syslog messages.
            The value noMap(99) indicates that the appropriate
            facility will be provided by the application on the
            managed entity.
            If this option is not available on a particular entity,
            attempts to set the facility to this value will fail
            with an error-status of wrongValue.
           "
       REFERENCE
           "The Syslog Protocol [RFCPROT] sec. 6.2.1 (Table 1).
           "
       SYNTAX  INTEGER
            {
              kernel          (0), -- kernel messages
              user            (1), -- user-level messages
              mail            (2), -- mail system messages
              daemon          (3), -- system daemons' messages
              auth1           (4), -- security/authorization messages
              syslog          (5), -- messages generated internally by
                                   -- syslogd
              lpr             (6), -- line printer subsystem messages
              news            (7), -- network news subsystem messages
              uucp            (8), -- UUCP subsystem messages
              cron1           (9), -- clock daemon messages
              auth2           (10),-- security/authorization messages
              ftp             (11),-- ftp daemon messages
              ntp             (12),-- NTP subsystem messages
              logAudit        (13),-- log audit messages
              logAlert        (14),-- log alert messages
              cron2           (15),-- clock daemon messages
              local0          (16),
              local1          (17),
              local2          (18),
              local3          (19),
              local4          (20),
              local5          (21),
              local6          (22),
              local7          (23),
              noMap           (99)
            }

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 8]


Internet Draft                  syslogMIB                  December 2006

   SyslogSeverity  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "This textual convention enumerates the severity levels
            of syslog messages.
           "
       REFERENCE
           "The Syslog Protocol RFCPROT sec. 6.2.1 (Table 2)
           "
       SYNTAX  INTEGER
            {
              emergency       (0),  -- system is unusable
              alert           (1),  -- action must be taken immediately
              critical        (2),  -- critical condition
              error           (3),  -- error condition
              warning         (4),  -- warning condition
              notice          (5),  -- normal but significant condition
              info            (6),  -- informational message
              debug           (7)   -- debug-level messages
            }

   SyslogService  ::=  TEXTUAL-CONVENTION
       STATUS  current
       DESCRIPTION
           "The service name or port number that will be used to
            send and/or receive messages.
            The service name must resolve to a port number on the
            local host.
           "
       SYNTAX OCTET STRING (SIZE (0..255))

   -- -------------------------------------------------------------
   -- syslogMIB - the main groups
   -- -------------------------------------------------------------

   syslogNotifications       OBJECT IDENTIFIER
                         ::= { syslogMIB 0 }

   syslogObjects             OBJECT IDENTIFIER
                         ::= { syslogMIB 1 }

   syslogConformance         OBJECT IDENTIFIER
                         ::= { syslogMIB 3 }

Glenn M. Keeni.          Expires: June 17, 2007                 [Page 9]


Internet Draft                  syslogMIB                  December 2006

   syslogSystem              OBJECT IDENTIFIER
                         ::= { syslogObjects 1 }

   syslogEntity              OBJECT IDENTIFIER
                         ::= { syslogObjects 2 }

   -- -------------------------------------------------------------
   -- syslogSystem
   -- -------------------------------------------------------------

   -- The default parameters

   syslogDefaultTransportDomain OBJECT-TYPE
       SYNTAX      TransportDomain
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
          "The default transportDomain for the address which the
           syslog entity will use to receive and transmit messages.

           Typical values will be one of (not all inclusive) list:

              transportDomainUdpIpv4  (from TRANSPORT-ADDRESS-MIB)
              transportDomainUdpIpv6  (from TRANSPORT-ADDRESS-MIB)
           The default transport that a syslog entity will use
           to send syslog messages.

           The value of this object SHOULD remain unchanged
           across reboots of the managed entity.

          "
       REFERENCE
           "The Syslog Protocol [RFCPROT] Sec. 5.
           "
       DEFVAL  {transportDomainUdpIpv4}
       ::= { syslogSystem 1 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 10]


Internet Draft                  syslogMIB                  December 2006

   syslogDefaultService OBJECT-TYPE
       SYNTAX      SyslogService
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default service name or port number that a syslog
            entity will use to send syslog messages.

            The value of this object SHOULD remain unchanged
            across reboots of the managed entity.
           "
       REFERENCE
           "Transmission of syslog messages over UDP
            RFCUDPX Sec. 3.3.
           "
       DEFVAL  { "514" }
       ::= { syslogSystem 2 }

   syslogDefaultFacility OBJECT-TYPE
       SYNTAX      SyslogFacility
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default syslog facility will be used to
            compute the syslog priority that will be added
            to syslog messages when the message needs to be
            relayed and does not have facility specified.

            The value of this object SHOULD remain unchanged
            across reboots of the managed entity.
           "
       ::= { syslogSystem 3 }

   syslogDefaultSeverity OBJECT-TYPE
       SYNTAX      SyslogSeverity
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
           "The default syslog severity will be used to
            compute the syslog priority that will be added
            to syslog messages when the message needs to be
            relayed and does not have priority specified.

            The value of this object SHOULD remain unchanged
            across reboots of the managed entity.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 11]


Internet Draft                  syslogMIB                  December 2006

           "
       ::= { syslogSystem 4 }

   -- -------------------------------------------------------------
   -- syslog entity configuration info table
   -- -------------------------------------------------------------
   syslogEntityControlTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogEntityControlEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing the configuration parameters
            pertaining to the syslog entities serviced by an
            SNMP agent.
           "
       ::= { syslogEntity 1 }

   syslogEntityControlEntry OBJECT-TYPE
       SYNTAX      SyslogEntityControlEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The configuration parameters pertaining to a syslog
            entity.
           "
       INDEX  { syslogEntityControlIndex }
       ::= { syslogEntityControlTable 1 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 12]


Internet Draft                  syslogMIB                  December 2006

   SyslogEntityControlEntry ::=
       SEQUENCE {
           syslogEntityControlIndex
                Unsigned32,
           syslogEntityControlDescr
                SnmpAdminString,
           syslogEntityControlBindAddrType
                InetAddressType,
           syslogEntityControlBindAddr
                InetAddress,
           syslogEntityControlTransportDomain
                TransportDomain,
           syslogEntityControlService
                SyslogService,
           syslogEntityControlMaxMessageSize
                Unsigned32,
           syslogEntityControlConfFileName
                SnmpAdminString,
           syslogEntityControlStatus
                INTEGER,
           syslogEntityControlStorageType
                StorageType,
           syslogEntityControlRowStatus
                RowStatus
        }

   syslogEntityControlIndex OBJECT-TYPE
       SYNTAX      Unsigned32 (1..2147483647)
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The Index that uniquely identifies the syslog entity in
            the syslogEntityControlTable.
            The value of the index for a syslog entity may not be
            the same across system reboots. Users and Applications
            will need to determine the index of a syslog entity after
            system reboots.
           "
       ::= { syslogEntityControlEntry 1 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 13]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityControlDescr OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "A user definable description of the syslog entity.
            This description could be used by syslog management
            applications e.g. in reports or in user interfaces.
           "
       ::= { syslogEntityControlEntry 2 }

   syslogEntityControlBindAddrType OBJECT-TYPE
       SYNTAX      InetAddressType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The type of Internet address which follows
            in syslogEntityControlBindAddr.
           "
       ::= { syslogEntityControlEntry 3 }

   syslogEntityControlBindAddr OBJECT-TYPE
       SYNTAX      InetAddress
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The specific address the syslog entity will bind to.
            The format of the address is specified by the
            corresponding syslogEntityControlBindAddrType object.
            If the address is specified in the DNS domain name format
            [syslogEntityControlBindAddrType = 'dns'], the
            corresponding IPv4 or IPv6 address obtained at the time
            of the binding operation by the syslog entity, will be
            used.
           "
       ::= { syslogEntityControlEntry 4 }

   syslogEntityControlTransportDomain OBJECT-TYPE
       SYNTAX      TransportDomain
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The transport that a syslog entity will use
            to send syslog messages.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 14]


Internet Draft                  syslogMIB                  December 2006

            The value 'zeroDotZero' indicates the syslog entity will
            use the transport specified in syslogDefaultTransportDomain.
           "
       DEFVAL  {zeroDotZero}
       ::= { syslogEntityControlEntry 5 }

   syslogEntityControlService OBJECT-TYPE
       SYNTAX      SyslogService
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The service name or port number that this syslog
            entity will use to send syslog messages.

            If no value is specified, the syslog entity will use the
            service name or port number specified in
            syslogDefaultService.
           "
       ::= { syslogEntityControlEntry 6 }

   syslogEntityControlMaxMessageSize OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The maximum size of the syslog messages in bytes
            for this syslog entity.

            A syslog entity may reject or truncate messages larger
            than the specified maximum syslog message size.
           "
       ::= { syslogEntityControlEntry 7 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 15]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityControlConfFileName OBJECT-TYPE
       SYNTAX       SnmpAdminString
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
         "The fullpath name of the configuration file where the
          syslog entity's message selection and corresponding
          action rules will be read from.
          If the system does not support the specification of a
          configuration file, this field will be a zero-length
          string.
         "
       DEFVAL { "/etc/syslog.conf" }
       ::= { syslogEntityControlEntry 8 }

   syslogEntityControlStatus OBJECT-TYPE
       SYNTAX       INTEGER  {
                         unknown  (1),
                         started  (2),
                         suspended(3),
                         stopped  (4)
                       }
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION
           "The status of the syslog entity.
           "
       DEFVAL      { unknown }
       ::= { syslogEntityControlEntry 9 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 16]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityControlStorageType OBJECT-TYPE
       SYNTAX       StorageType
       MAX-ACCESS   read-create
       STATUS       current
       DESCRIPTION
           "This object defines whether the parameters defined in
            this row are kept in volatile storage and lost upon
            reboot or are backed up by non-volatile or permanent
            storage.
            Conceptual rows having the value 'permanent' need not
            allow write-access to any columnar objects in the row.
           "
       DEFVAL      { nonVolatile }
       ::= { syslogEntityControlEntry 10 }

   syslogEntityControlRowStatus OBJECT-TYPE
       SYNTAX      RowStatus
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object is used to create, modify and delete rows in
            the syslogEntityControlTable.
            The value of syslogEntityControlDescr can be changed
            when this object is in state ''active'' or in
            ''notInService''.
            The other objects in a row can be modified only when the
            value of this object in the corresponding conceptual row
            is not ''active''. Thus to modify one or more of the
            objects in this conceptual row,
              a. change the row status to ''notInService'',
              b. change the values of the row
              c. change the row status to ''active''
            The syslogEntityControlRowStatus may be changed to
            ''active'' if all the managed objects in the conceptual
            row have been assigned valid values.
           "
       ::= { syslogEntityControlEntry 11 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 17]


Internet Draft                  syslogMIB                  December 2006

   -- -------------------------------------------------------------
   -- syslogEntityOperations
   -- -------------------------------------------------------------
   syslogEntityOperationsTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF SyslogEntityOperationsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A table containing operations information about
            the syslog entities serviced by an SNMP agent.
            This table complements the (configuration) information
            in syslogEntityControlTable .
           "
       ::= { syslogEntity 2 }

   syslogEntityOperationsEntry OBJECT-TYPE
       SYNTAX      SyslogEntityOperationsEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The operations information pertaining to a syslog
            entity.
           "
       AUGMENTS  { syslogEntityControlEntry }
       ::= { syslogEntityOperationsTable 1 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 18]


Internet Draft                  syslogMIB                  December 2006

   SyslogEntityOperationsEntry ::=
       SEQUENCE {
           syslogEntityOperationsMsgsReceived
                Counter32,
           syslogEntityOperationsMsgsRelayed
                Counter32,
           syslogEntityOperationsMsgsDropped
                Counter32,
           syslogEntityOperationsMsgsIllFormed
                Counter32,
           syslogEntityOperationsMsgsIgnored
                Counter32,
           syslogEntityOperationsLastMsgRecdTime
                TimeStamp,
           syslogEntityOperationsLastMsgTransmittedTime
                TimeStamp,
           syslogEntityOperationsStartTime
                TimeStamp,
           syslogEntityOperationsLastError
                SnmpAdminString,
           syslogEntityOperationsLastErrorTime
                TimeStamp,
           syslogEntityOperationsReference
                Integer32,
           syslogEntityOperationsCounterDiscontinuityTime
                TimeStamp
       }

   syslogEntityOperationsMsgsReceived OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages received by the syslog
            entity. This includes messages that were ignored.
            Discontinuities in the value of this counter can
            occur at re-initialization of the management system,
            and at other times as indicated by the value of
            syslogEntityOperationsCounterDiscontinuityTime.
           "
       ::= { syslogEntityOperationsEntry 1 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 19]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityOperationsMsgsRelayed OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages relayed by the syslog
            entity to other syslog entities.
            Discontinuities in the value of this counter can
            occur at re-initialization of the management system,
            and at other times as indicated by the value of
            syslogEntityOperationsCounterDiscontinuityTime.
           "
       ::= { syslogEntityOperationsEntry 2 }

   syslogEntityOperationsMsgsDropped OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that could not be queued
            for transmission by the syslog entity.
            Discontinuities in the value of this counter can
            occur at re-initialization of the management system,
            and at other times as indicated by the value of
            syslogEntityOperationsCounterDiscontinuityTime.
           "
       ::= { syslogEntityOperationsEntry 3 }

   syslogEntityOperationsMsgsIllFormed OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were rejected by the
            syslog entity because these were not well-formed.
            Discontinuities in the value of this counter can
            occur at re-initialization of the management system,
            and at other times as indicated by the value of
            syslogEntityOperationsCounterDiscontinuityTime.
           "
       ::= { syslogEntityOperationsEntry 4 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 20]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityOperationsMsgsIgnored OBJECT-TYPE
       SYNTAX      Counter32
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The number of messages that were not processed by the
            syslog entity because the messages did not meet
            the allowed specifications. This will include
            messages that are not accepted as the message size was
            greater than the system's maximum message size and will
            exclude messages that are rejected because they are
            malformed.
            Discontinuities in the value of this counter can
            occur at re-initialization of the management system,
            and at other times as indicated by the value of
            syslogEntityOperationsCounterDiscontinuityTime.
           "
       ::= { syslogEntityOperationsEntry 5 }

   syslogEntityOperationsLastMsgRecdTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was received
            by the syslog entity locally or from a remote
            syslog entity.
           "
       ::= { syslogEntityOperationsEntry 6 }

   syslogEntityOperationsLastMsgTransmittedTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last message was transmitted
            by the syslog entity.
           "
       ::= { syslogEntityOperationsEntry 7 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 21]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityOperationsStartTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when this entity was started.
           "
       ::= { syslogEntityOperationsEntry 8 }

   syslogEntityOperationsLastError OBJECT-TYPE
       SYNTAX      SnmpAdminString
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "A description of the last error related to sending,
            receiving or processing a syslog message that was
            encountered by this syslog entity.
           "
       ::= { syslogEntityOperationsEntry 9 }

   syslogEntityOperationsLastErrorTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The local time when the last error was encountered.
           "
       ::= { syslogEntityOperationsEntry 10 }

   syslogEntityOperationsReference OBJECT-TYPE
       SYNTAX      Integer32 (0..2147483647)
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "If the Host resource MIB is instantiated on the
            host then this entry will have the value of the
            hrSWRunIndex of the corresponding entry in the
            hrSWRunTable.
            Note that the hrSWRunIndex is not persistent
            across system reboots or software restarts. The
            value of syslogEntityOperationsReference SHOULD
            reference the latest value of the hrSWRunIndex
            of the corresponding entry in the hrSWRunTable.

            The special value of zero indicates that the Host

Glenn M. Keeni.          Expires: June 17, 2007                [Page 22]


Internet Draft                  syslogMIB                  December 2006

            resource MIB is not instantiated.
           "
       ::= { syslogEntityOperationsEntry 11 }

   syslogEntityOperationsCounterDiscontinuityTime OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
            "The value of sysUpTime on the most recent occasion
             at which any one or more of this syslog entity's
             counters, viz., counters with OID prefix
             'syslogEntityOperationsMsgsReceived' or
             'syslogEntityOperationsMsgsRelayed' or
             'syslogEntityOperationsMsgsDropped' or
             'syslogEntityOperationsMsgsIllFormed' or
             'syslogEntityOperationsMsgsIgnored' suffered a
             discontinuity.
             If no such discontinuities have occurred since the
             last re-initialization of the local management
             subsystem, then this object will have a zero value.
            "
       ::= { syslogEntityOperationsEntry 12 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 23]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityStatusChanged NOTIFICATION-TYPE
       OBJECTS   {
                    syslogEntityControlStatus,
                    syslogEntityControlDescr,
                    syslogEntityControlBindAddrType,
                    syslogEntityControlBindAddr,
                    syslogEntityControlTransportDomain,
                    syslogEntityControlService,
                    syslogEntityControlConfFileName
                 }
       STATUS    current
       DESCRIPTION
               "This notification is sent when a syslog entity
                changes state. For example when the syslog entity
                starts [syslogEntityControlStatus is ''started'' ]
                or the syslog entity stops [syslogEntityControlStatus
                is ''suspended'' or ''stopped''].
                The syslog entity corresponding to the notification
                will be identified by the syslogEntityOperationsIndex
                instance identifier of the objects in the notification.
               "
       ::= { syslogNotifications 1 }

   -- -------------------------------------------------------------
   -- Conformance Information
   -- -------------------------------------------------------------

   syslogGroups OBJECT IDENTIFIER
                             ::= { syslogConformance 1 }

   syslogCompliances OBJECT IDENTIFIER
                             ::= { syslogConformance 2 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 24]


Internet Draft                  syslogMIB                  December 2006

   -- -------------------------------------------------------------
   -- units of conformance
   -- -------------------------------------------------------------

   syslogDefaultGroup OBJECT-GROUP
       OBJECTS {
                syslogDefaultTransportDomain,
                syslogDefaultService,
                syslogDefaultFacility,
                syslogDefaultSeverity
       }
       STATUS  current
       DESCRIPTION
           "A collection of objects providing default
            parameters for syslog entities
           "
       ::= { syslogGroups 1}

   syslogEntityOperationsGroup OBJECT-GROUP
       OBJECTS {
               --  syslogEntityOperationsIndex,
                   syslogEntityOperationsMsgsReceived,
                   syslogEntityOperationsMsgsRelayed,
                   syslogEntityOperationsMsgsDropped,
                   syslogEntityOperationsMsgsIllFormed,
                   syslogEntityOperationsMsgsIgnored,
                   syslogEntityOperationsLastMsgRecdTime,
                   syslogEntityOperationsLastMsgTransmittedTime,
                   syslogEntityOperationsStartTime,
                   syslogEntityOperationsLastError,
                   syslogEntityOperationsLastErrorTime,
                   syslogEntityOperationsReference,
                   syslogEntityOperationsCounterDiscontinuityTime
               }
       STATUS  current
       DESCRIPTION
           "A collection of objects providing message related
            statistics."
       ::= { syslogGroups 2}

Glenn M. Keeni.          Expires: June 17, 2007                [Page 25]


Internet Draft                  syslogMIB                  December 2006

   syslogEntityControlGroup OBJECT-GROUP
       OBJECTS {
                   syslogEntityControlDescr,
                   syslogEntityControlBindAddrType,
                   syslogEntityControlBindAddr,
                   syslogEntityControlTransportDomain,
                   syslogEntityControlService,
                   syslogEntityControlMaxMessageSize,
                   syslogEntityControlConfFileName,
                   syslogEntityControlStatus,
                   syslogEntityControlStorageType,
                   syslogEntityControlRowStatus
               }
       STATUS  current
       DESCRIPTION
           "A collection of objects representing the run time parameters
            for the syslog entities.
           "
       ::= { syslogGroups 3}

   syslogNotificationGroup NOTIFICATION-GROUP
       NOTIFICATIONS {
                   syslogEntityStatusChanged
               }
       STATUS  current
       DESCRIPTION
           "A collection of notifications about the operational
            state of a syslog entity.
           "
       ::= { syslogGroups 4}

Glenn M. Keeni.          Expires: June 17, 2007                [Page 26]


Internet Draft                  syslogMIB                  December 2006

   -- -------------------------------------------------------------
   -- compliance statements
   -- -------------------------------------------------------------

   syslogFullCompliance1 MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities which
            implement the SYSLOG-MIB with support for writable
            objects and notifications. Such an implementation can
            be both monitored and configured via SNMP. It can
            also send notifications about change in the
            operational status of the syslog entity.
           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogNotificationGroup,
           syslogDefaultGroup,
           syslogEntityOperationsGroup,
           syslogEntityControlGroup
       }

       ::= { syslogCompliances 1 }

   syslogFullCompliance2 MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities which
            implement the SYSLOG-MIB with support for writable
            objects. Such an implementation can
            be both monitored and configured via SNMP.
           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogDefaultGroup,
           syslogEntityOperationsGroup,
           syslogEntityControlGroup
       }

       ::= { syslogCompliances 2 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 27]


Internet Draft                  syslogMIB                  December 2006

   syslogReadOnlyCompliance1 MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities which
            implement the syslog MIB without support
            for read-write (i.e. in read-only mode). It can
            also send notifications about change in the
            operational status of the syslog entity.

           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogNotificationGroup,
           syslogDefaultGroup,
           syslogEntityOperationsGroup,
           syslogEntityControlGroup
       }

       OBJECT  syslogEntityControlDescr
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlBindAddrType
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlBindAddr
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlTransportDomain
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlService
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "

Glenn M. Keeni.          Expires: June 17, 2007                [Page 28]


Internet Draft                  syslogMIB                  December 2006

       OBJECT  syslogEntityControlMaxMessageSize
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlConfFileName
       MIN-ACCESS   read-only
       DESCRIPTION
         "Write access is not required.
         "
       OBJECT  syslogEntityControlStorageType
       MIN-ACCESS   read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlRowStatus
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       ::= { syslogCompliances 3 }

   syslogReadOnlyCompliance2 MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities which
            implement the syslog MIB without support
            for read-write (i.e. in read-only mode).
           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogDefaultGroup,
           syslogEntityOperationsGroup,
           syslogEntityControlGroup
       }

       OBJECT  syslogEntityControlDescr
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "

Glenn M. Keeni.          Expires: June 17, 2007                [Page 29]


Internet Draft                  syslogMIB                  December 2006

       OBJECT  syslogEntityControlBindAddrType
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlBindAddr
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlTransportDomain
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlService
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlMaxMessageSize
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlConfFileName
       MIN-ACCESS   read-only
       DESCRIPTION
         "Write access is not required.
         "
       OBJECT  syslogEntityControlStorageType
       MIN-ACCESS   read-only
       DESCRIPTION
           "Write access is not required.
           "
       OBJECT  syslogEntityControlRowStatus
       MIN-ACCESS  read-only
       DESCRIPTION
           "Write access is not required.
           "
       ::= { syslogCompliances 4 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 30]


Internet Draft                  syslogMIB                  December 2006

   syslogNotificationCompliance MODULE-COMPLIANCE
       STATUS  current
       DESCRIPTION
           "The compliance statement for SNMP entities
            which implement the SYSLOG-MIB and support
            only notifications about change in the
            operational status of a syslog entity.
           "
       MODULE -- this module
       MANDATORY-GROUPS {
           syslogNotificationGroup
       }

       ::= { syslogCompliances 5 }

   END

Glenn M. Keeni.          Expires: June 17, 2007                [Page 31]


Internet Draft                  syslogMIB                  December 2006

5. Security Considerations

   Syslog plays a very important role in the computer and network
   security of an organization. SYSLOG-MIB defines several managed
   objects that may be used to monitor, configure and control syslog
   entities. As such improper manipulation of the objects represented by
   this MIB may lead to an attack on an important component of the
   computer and network security infrastructure. The objects in
   syslogEntityControlTable may be misconfigured to cause syslog
   messages to be diverted or lost.

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

            o  syslogEntityControlTable: The objects in this table
               describe the configuration of the syslog entities.
               It may be misconfigured to start up a very large
               number of syslog entities (processes) and deny the
               system of its resources.
            o  syslogEntityControlBindAddr: This object may be
               misconfigured to bind syslog entity to the wrong
               address. This will cause messages to be lost.
            o  syslogEntityControlTransportDomain : This object may be
               misconfigured to specify a wrong transport for the
               syslog entity. This will cause messages to be lost.
            o  syslogEntityControlService : This object may be
               misconfigured to bind syslog entity to the wrong
               service (port). This will cause messages to be lost.
            o  syslogEntityControlMaxMessageSize: This message may be
               misconfigured to set the wrong MaxMessageSize for the
               syslog entity. It may cause syslog messages to be lost.
            o  syslogEntityControlConfFileName: This object may be
               misconfigured to start the syslog entity with the
               wrong (rogue) configuration.
            o  syslogEntityControlStorageType: This object may be
               misconfigured to set the wrong storage type. That may
               cause confusion, operational errors and/or loss of
               information.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 32]


Internet Draft                  syslogMIB                  December 2006

   Some of the readable objects in this MIB module (i.e., objects with a
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments.  It is thus important to
   control even GET and/or NOTIFY access to these objects and possibly
   to even encrypt the values of these objects when sending them over
   the network via SNMP.  These are the tables and objects and their
   sensitivity/vulnerability:

           o  syslogEntityOperationsTable: Objects in this table carry
              sensitive information. The counters may reveal
              information about the deployment and effectiveness of
              the relevant security systems. The counters may be
              analyzed to tell whether the security systems are able
              to detect an event or not.

           o  syslogEntityOperationsLastError: This object may contain
              sensitive information e.g. user-id, password etc.
              depending on the implementation of the syslog entity.
              It may reveal details about the syslog implementation
              itself, e.g. version, OS etc.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   even then, there is no control as to who on the secure network is
   allowed to access and GET/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 33]


Internet Draft                  syslogMIB                  December 2006

6.  IANA Considerations

   The MIB modules in this document use the following IANA-assigned
   OBJECT IDENTIFIER values recorded in the SMI Numbers registry:

   Descriptor        OBJECT IDENTIFIER value
   ----------        -----------------------

   syslogMIB         { mib-2 YYYY }

   IANA Reg.: Please assign a value under the 'mib-2' subtree
              for the 'syslogMIB' MODULE-IDENTITY  and record
              the assignment in the SMI Numbers registry.

   RFC Ed.: When the above assignments have been made, please
              - remove the above note
              - replace "YYYY" here with the assigned values and
              - remove this note.

7.  References

7.1 Normative References

[RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirements Levels", BCP 14, RFC 2119, March 1997.

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578,
            April 1999

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Textual Conventions for
            SMIv2", STD 58, RFC 2579, April 1999

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999

[RFC3411]   Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
            for Describing Simple Network Management Protocol (SNMP)
            Management Frameworks", STD 62, RFC 3411, December 2002.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 34]


Internet Draft                  syslogMIB                  December 2006

[RFC3419]   Daniele, M., and Schoenwaelder, J., "Textual Conventions for
            Transport Addresses", RFC 3419, December 2002.

[RFC4001]   Daniele, M., Haberman, B., Routhier, S., and Schoenwaelder,
            J., "Textual Conventions for Internet Network Addresses",
            RFC 4001,  February 2005.

[RFCPROT]   Gerhards, R., "The syslog Protocol",
            draft-ietf-syslog-protocol-17.txt, work in progress,
            June, 2006.

[RFCUDPX]   Okmianski, A., "Transmission of syslog messages over UDP",
            draft-ietf-syslog-transport-udp-07.txt work in progress,
            May, 2006.

7.2  Informative References

[RFC3164]   Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
            August 2001.

[RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
           "Introduction and Applicability Statements for the
            Internet-Standard Management Framework", RFC 3410,
            December 2002.

[RFC2790]   Waldbusser, S., and Grillo, P., "Host Resources MIB",
            RFC 2790, March 2000.

8.  Acknowledgments
   The initial draft of this document was authored by Bruno Pape.
   The authors would like to thank David Harrington, Mark Ellison,
   Mike MacFaden, Dave T Perkins and members of the WIDE-netman
   group for their comments and suggestions.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 35]


Internet Draft                  syslogMIB                  December 2006

9.  Author's Addresses

   Glenn Mansfield Keeni
   Cyber Solutions Inc.
   6-6-3 Minami Yoshinari
   Aoba-ku, Sendai 989-3204
   Japan

   Phone: +81-22-303-4012
   EMail: [email-masked]

Glenn M. Keeni.          Expires: June 17, 2007                [Page 36]


Internet Draft                  syslogMIB                  December 2006

10.  Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
   RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 37]


Internet Draft                  syslogMIB                  December 2006

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology
   described in this document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.  Information on the procedures with respect to
   rights in RFC documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention
   any copyrights, patents or patent applications, or other
   proprietary rights that may cover technology that may be required
   to implement this standard.  Please address the information to the
   IETF at [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Glenn M. Keeni.          Expires: June 17, 2007                [Page 38]


Internet Draft                  syslogMIB                  December 2006

                                APPENDIX

This section documents the development of the draft. It will be
deleted when the draft becomes an RFC.

Revision History:
Changes from draft-ietf-syslog-device-mib-11.txt
          to draft-ietf-syslog-device-mib-12.txt

1. Added text in introduction and in the DESCRIPTION of the MIB
   module to explain the terminology used in the document.
   Ref. Comment 1.1, 1.2, 1.3, 1.4.
2. Changed "group" to "subtree" in Section 3 (The MIB Design).
   Ref. Comment 1.5
3. Removed enumeration "other" from the enumeration for
   SyslogSeverity. This case does not arise.
   Ref. Comment 1.6

4. Revised DESCRIPTION of syslogEntityControlStorageType
   Ref. comment 2.3
5. Revised DESCRIPTION of syslogEntityStatusChanged
   Ref. Comment 2.4
6. Updated the boilerplate for the Copyright notice.
   Ref. Comment 2.7

7. Changed "should" to "SHOULD" in DESCRIPTION of
   syslogEntityOperationsReference
   Ref. Comment 3.2
8. Changed RFCPROT to "[RFCPROT]" in REFERENCE of
   syslogDefaultTransportDomain

Changes from draft-ietf-syslog-device-mib-9.txt
          to draft-ietf-syslog-device-mib-11.txt
[Note: The changes to the mib-9.txt and mib-10.txt are
       consolidated below.]
1. Namings changed:
   Page-8.
   changed the duplicate instances of auth and cron to
               auth1, auth2, cron1, cron2
   changed: SyslDevOpsEntry     -> SyslogEntityOperationsEntry
            syslEntOpsEntry     -> syslogEntityOperationsEntry
            SyslDevCtlEntry     -> SyslogEntityControlEntry
            syslEntCtlEntry     -> syslogEntityControlEntry
            syslEntOpsTable     -> syslogEntityOperationsTable

Glenn M. Keeni.          Expires: June 17, 2007                [Page 39]


Internet Draft                  syslogMIB                  December 2006

            syslogDevice        -> syslogDevice
            syslEntCtlProcDescr -> syslogEntityControlDescr
            syslEntOpsLastMsgDeliveredTime ->
                      syslogEntityOperationsLastMsgTransmittedTime.
            syslDevOpsGroup     -> syslogEntityOperationsGroup

2. Added TRANSPORT-ADDRESS-MIB[RFC3419] to the text on section 3
      (and 7.1 Normative References).

3. MIB.
   Fixed MIB nits.

4. Added text about the expected persistency behaviour of the
  read-write objects in the corresponding DESCRIPTION clauses.
        syslogDefaultTransport
        syslogDefaultService
        syslogDefaultFacility
        syslogDefaultSeverity

5. Replaced
      syslogDefaultTransport OBJECT-TYPE
          SYNTAX      TransportAddressType
    and
      syslEntCtlTransport OBJECT-TYPE
          SYNTAX      TransportAddressType
   by
      syslogDefaultTransportDomain OBJECT-TYPE
          SYNTAX      TransportDomain
      syslogEntityControlTransportDomain OBJECT-TYPE
          SYNTAX      TransportDomain

6. Changed the ordering of
      syslEntOpsTable ::= { syslogDevice 1 }
      syslEntCtlTable ::= { syslogDevice 2 }
   to
      syslogEntityControlTable ::= { syslogEntity 1 }
      syslogEntityOperationsTable ::= { syslogEntity 2 }

7. The tree structure is changed
   from

      syslogSystem              OBJECT IDENTIFIER
                      ::= { syslogMIB 1 }

Glenn M. Keeni.          Expires: June 17, 2007                [Page 40]


Internet Draft                  syslogMIB                  December 2006

      syslogDevice              OBJECT IDENTIFIER
                      ::= { syslogMIB 2 }

   to,
     syslogObjects             OBJECT IDENTIFIER
                      ::= { syslogMIB 1 }

     syslogSystem              OBJECT IDENTIFIER
                      ::= { syslogObjects 1 }

     syslogEntity              OBJECT IDENTIFIER
                      ::= { syslogObjects 2 }

8. syslogEntityOperationsEntry AUGMENTS  { syslogEntityControlEntry }

9. Added
       syslogEntityOperationsCounterDiscontinuityTime OBJECT-TYPE

   to indicate whether
          'syslogEntityOperationsMsgsReceived' or
          'syslogEntityOperationsMsgsRelayed' or
          'syslogEntityOperationsMsgsDropped' or
          'syslogEntityOperationsMsgsIllFormed' or
          'syslogEntityOperationsMsgsIgnored' suffered a
          discontinuity.

   Revised the DESCRIPTION of the above Objects.

10. Changed all references of "syslog process", "syslog device" to
    "syslog entity".

11. Changed syntax of syslogEntityOperationsReference from
        syslEntOpsReference OBJECT-TYPE
              SYNTAX      Integer32
    to
        syslogEntityOperationsReference OBJECT-TYPE
              SYNTAX      Integer32 (0..2147483647)
12. Revised the DESCRIPTION clauses of
        syslogEntityControlTable
        syslogEntityOperationsReference
        syslogEntityControlBindAddrType
        syslogEntityControlBindAddr
        syslogEntityControlTransportDomain
        syslogEntityControlService
        syslogEntityControlConfFileName

Glenn M. Keeni.          Expires: June 17, 2007                [Page 41]


Internet Draft                  syslogMIB                  December 2006

        syslogEntityControlStatus
        syslogEntityControlRowStatus
        syslogEntityOperationsTable
        syslogEntityControlTable
        syslogEntityOperationsMsgsDropped
        syslogEntityOperationsReference
        syslogEntityControlEntry

13.  Added   DEFVAL { nonVolatile } to syslogEntityControlStorageType

14.  Merged the NOTIFICATIONs
            syslEntStarted
            syslEntStopped
     into syslogEntityStatusChanged

15. Overhauled the syslogCompliance tree

16. idnits fixed.

17. IANA considerations section revised.

17. Labels and Captions in figure 1 are revised.

18. Revised DESCRIPTION clauses of
            SyslogSeverity
            syslogDefaultFacility
            syslogDefaultSeverity

19. syslogDefaultMaxMessageSize is deleted
    revised the DESCRIPTION of syslogEntityControlMaxMessageSize

20. editorial fixes

The changes upto draft-ietf-syslog-device-mib-9.txt are documented
below in the form of MIB Revision clauses.
    REVISION "200609040000Z"  --  9th September 2006
    DESCRIPTION
        "
        o The draft has been aligned with the current
          standards track documents syslog-protocol-17.txt
          and syslog-transport-udp-07.txt: the REFERNCE
          clauses have changed.
        o The TEXTUAL-CONVENTION SyslogTransport has been
          replaced by the TransportAddressType.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 42]


Internet Draft                  syslogMIB                  December 2006

        o The TEXTUAL-CONVENTION SyslogFacility and
          SyslogSeverity have been aligned with
          syslog-protocol-17.txt
        o A paragraph has been added to list the related
          MIBs from which MOS and TEXTUAL-CONVENTIONs have
          been imported.
        o The target of this MIB is now called a syslog
          entity. [ Earlier it was referred to as a syslog
          device.] The prefix syslDev has been changed to
          syslEnt
        o The DEFVALS have been aligned with the reference
          documents.
        o The REFERENCE section has been updated.
        o The OID for syslogConformance has been changed
          from 4 to 3.
        "

    REVISION "200607250000Z"  -- 25th July 2006
    DESCRIPTION
        "the internet draft's version number has
         been changed (7->8).
        "

    REVISION "200511250000Z"  -- 25th November 2005
    DESCRIPTION
        "A near complete overhaul of the MIB and the document.
         The BSD-syslog flavor has been abandoned in favor of a
         more generic syslog-protocol document that is under
         preparation.
         TBD. The reference clauses need to be redone once the
              new syslog document is ready.

         List of authors changed. Original draft author Bruno
         Pape is acknowledged in the Acknowledgments section.

         Editorial nits fixed.
        "

    REVISION "200406160000Z"  -- Mon Feb       16 00:00 GMT 2004
    DESCRIPTION
        "Major change.
             The configuration parts have been removed.

         Updated the description clauses.

Glenn M. Keeni.          Expires: June 17, 2007                [Page 43]


Internet Draft                  syslogMIB                  December 2006

         Editorial nits fixed.
        "

    REVISION "200306250000Z"  -- Wed June      25 00:00 GMT 2003
    DESCRIPTION
        "Changed the type of
             syslogProcLastError            SnmpAdminString,
             from Integer32.

         DEFVAL { 0 ] is added to syslogAllowedHostsMaskLen

         MO name changed from
         syslogCtlSelectionHostname to syslogCtlSelectionHostName

         Updated the description clauses.

         Fixed nits pointed out in Bert's mails of 20030319 and
         revised the document wrt the guidelines in
         draft-ietf-ops-mib-review-guidelines-01.txt

         Editorial nits fixed.
        "

    REVISION "200303030000Z"  -- Mon March     03 00:00 GMT 2003
    DESCRIPTION
        "Fixing of nits in descriptions, addition of references,
         addition of the following MOs
             syslogProcMsgsIllFormed        Counter32,
             syslogProcStartTime            TimeStamp,
             syslogProcLastError            Integer32,
             syslogProcLastErrorTime        TimeStamp,
             syslDevCtlStorageType        StorageType,
             syslogCtlFwdActionSrcAddrType  InetAddressType,
             syslogCtlFwdActionSrcAddr      InetAddress,
         added enumeration ''suspended(2)'' to
             syslDevCtlStatus.
        "

    REVISION "200212252343Z"  -- Wed December  25 23:43 GMT 2002
    DESCRIPTION
        "Radical revision of the MIB structure and design."

    REVISION "200206061841Z"  -- Thu Jun  6 18:41 GMT 2002
    DESCRIPTION
        "The initial version of this MIB module."

Glenn M. Keeni.          Expires: June 17, 2007                [Page 44]


Internet Draft                  syslogMIB                  December 2006

Glenn M. Keeni.          Expires: June 17, 2007                [Page 45]


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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Dec 2006 15:38:08 +0100

>          draft-ietf-syslog-device-mib-12.txt

The combination of 

  syslogEntityControlBindAddrType	InetAddressType
  syslogEntityControlBindAddr		InetAddress
  syslogEntityControlTransportDomain	TransportDomain
  syslogEntityControlService		SyslogService

looks a bit crazy to me. 

- Why have both InetAddressType and TransportDomain?

- Why not simply use (InetAddressType,InetAddress,InetPortNumber) or
  (TansportAddressType,TransportAddress)?

- What is the value of saying the service name is "xyz", which has
  only local significance?

- How do I find out which encapsulations are supported (plain, beep,
  tls, ...)?

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 22 Dec 2006 11:24:10 +0900

Juergen,
>   syslogEntityControlService		SyslogService
I seemed to have missed something here. It will help if you can tell
> - Why have both InetAddressType and TransportDomain?
We will not have this.
>   (TansportAddressType,TransportAddress)?
We got started with InetAddressType,InetAddress,InetPortNumber. But
then we realized that we will have problems representing transport
over TLS etc.
We can not use TransportAddressType,TransportAddress as there is no
transport type specified for
     (syslog) Transport over TLS
> - What is the value of saying the service name is "xyz", which has
Is this referring to syslogEntityControlService?
We will probably not need this.
> - How do I find out which encapsulations are supported (plain, beep,
That is the problem we are trying to solve.
Can that be done by defining appropriate domains for
     syslog transport over TLS
     syslog transport over beep etc. ?

Glenn

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Dec 2006 10:34:09 +0100

>     syslog transport over beep etc. ?

Option a):

  You use a four tuple consisting of:

  (InetAddressType, InetAddress, InetPortNumer, SyslogEncapsulation)

Option b):

  You use a three tuple consisting of:

  (TransportAddressType, TransportAddress, SyslogEncapsulation)

In both cases, you need to define a TC SyslogEncapsulation which
enumerates the syslog encapsulations (or transport mappings) such as {
other(0), plain(1), tls(2), beep(3), ... }.

InetAddress identifies Internet network layer endpoints while
TransportAddress identifies Internet transport layer endpoints, no
more no less. If you want to move to a two tuple, the only option in
principle is:

Option c):

  You use a two tuple consisting of

  (SyslogAddressType, SyslogAddress)

  where SyslogAddressType combines the address type with the
  encapsulation (this is essentially what a TDomain does for SNMP)

/js

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 Dec 2006 19:17:18 +0100

I am not convinced that the proposed solutions match the underlying problem.

Syslog:
 - can be -protocol or RFC3164 (or RFC3164bis or ...)
 - may be signed.
 - may be secured with TLS (or SSH or DTLS or  ...)
 - could run over UDP or TCP (or SCTP or ..)

What we have then done is to bind -protocol to TLS to TCP in a package and asked
IANA for a port number less that 1024 for that combination

So I think that trying to analyse it in terms of, eg, InetAddressType,
InetAddress, InetPortNumber and SyslogEncapsulation won't work.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Glenn M. Keeni" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>; <[email-masked]>
Sent: Friday, December 22, 2006 10:34 AM
Subject: Re: TransportDomain. Was: Re: [Syslog] Submission
ofdraft-ietf-syslog-device-mib-12.txt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 22 Dec 2006 20:44:29 +0100

On Fri, Dec 22, 2006 at 07:17:18PM +0100, tom.petch wrote:

> What we have then done is to bind -protocol to TLS to TCP in a
> package and asked IANA for a port number less that 1024 for that
> combination
> 

I don't get your message - can you enlighten us please?

/js

---

From: "tom.petch" <[email-masked]>
Date: Sun, 24 Dec 2006 20:08:12 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Glenn M. Keeni" <[email-masked]>; <[email-masked]>
Sent: Friday, December 22, 2006 8:44 PM
Subject: Re: TransportDomain. Was: Re: [Syslog] Submission

> I don't get your message - can you enlighten us please?
My pleasure :-)

My sense is that your analysis of the protocols is
  syslog
  encapsulation
  transport
somewhat RFC3411-like so we might have an enumeration for encapsulation, one (or
more) for transport and problem solved.  I am saying that the structure
(architecture/layers) is not like that (no dbh:-), that we
have 'tls/tcp/IANA port' all tied up in a bundle together, take it or leave it.
Were we ever to do anything different in future, most likely it would be a
another package, perhaps SSH/TCP/different IANA port or TCP per se, so the
decomposition you imply does not make sense to me.

Also, there is more than one flavour of syslog (-protocol, RFC3164) and perhaps
we need that specifying more than we need to specify what lies underneath.  So
option c) is the closest but may not be enough.

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Dec 2006 12:40:00 +0100

On Sun, Dec 24, 2006 at 08:08:12PM +0100, tom.petch wrote:
> somewhat RFC3411-like so we might have an enumeration for
> encapsulation, one (or more) for transport and problem solved.  I am
> saying that the structure (architecture/layers) is not like that (no
> dbh:-), that we have 'tls/tcp/IANA port' all tied up in a bundle
> together, take it or leave it.

I tried to clarify in a constructive way the purpose of InetAddress
and friends and TransportAddress and friends. You seem to suggest to
use some syslog specific SyslogDomain/SyslogAddress (but you don't
spell things out so you leave me guessing).

> Were we ever to do anything different in future, most likely it
> would be a another package, perhaps SSH/TCP/different IANA port or
> TCP per se, so the decomposition you imply does not make sense to
> me.

There is a transport endpoint involved in SSH/TCP and some sort of
encapsulation - so I do not really see what breaks.

/js

---

From: "David Harrington" <[email-masked]>
Date: Wed, 27 Dec 2006 18:26:30 -0500

Hi Tom,

Juergen's explanation has nothing to do with RFC3411. The fact that
syslog can be 3164 or -protocol or signed is really immaterial to this
discussion, since these happen above the addressing level.

This discussion has to do with choosing from three standard mechanisms
for representing addresses in SMIv2 MIB modules. There are advantages
and disadvantages to each of the three standard approaches to
representing address formats, and these should be understood to make
the proper choice. (Juergen is well versed in the intracacies of the
advantages and disadvantages, and is trying to provide some advice).

The three standards are: 

1) TDomain (RFC3417) - which defines a mechanism to represent
snmp-specific addresses (at layer7). This was defined explicitly for
use in the MIB modules that are part of SNMPv3, and are designed only
for managing SNMP, and the addresses defined (e.g.
SnmpUDPDomain/SnmpUDPAddress) can not be easily reused to represent
addresses used by other protocols.
   snmpUDPDomain  OBJECT-IDENTITY
       STATUS     current
       DESCRIPTION
               "The SNMP over UDP over IPv4 transport domain.
               The corresponding transport address is of type
               SnmpUDPAddress."
       ::= { snmpDomains 1 }
   SnmpUDPAddress ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1d.1d.1d.1d/2d"
       STATUS       current
       DESCRIPTION
               "Represents a UDP over IPv4 address:

                  octets   contents        encoding
                   1-4     IP-address      network-byte order
                   5-6     UDP-port        network-byte order
               "
       SYNTAX       OCTET STRING (SIZE (6))

	Tdomain includes definitions for snmp-specific addresses. For
syslog to use TDomain will require us to develop hardcoded OID
assignments for a syslogUDPDomain and syslogUDPAddress,
syslogTCPDomain, syslogTCPAddress, syslogTLSDomain, syslogTLSAddress,
and so on. Those hardcoded values can then be used in TDomain/TAddress
fields in MIB modules. 
	To provide an SSH transport extension would require publishing
a new MIB module to define the new hardcoded values syslogSSHDomain,
syslogSSHAddress.
	The SNMP community realized it is really undesirable to have
to write a whole new MIB module just to say what the address domain
would be and what the address would look like.
	The suggestion that a syslog address is always
syslog/tls/tcp/IANAport might lead one to select the TDomain approach,
but this is not really required. One ting to point out is that IANA
assigns a requested "default" port, but operators can often change
what port is actually used.

2) TransportDomain - which defines a mechanism that represents
(layer4) transport addresses, independent of the application. This
better permitted showing the transport addresses of non-snmp-things in
MIB modules.

  transportDomainUdpIpv4 OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "The UDP over IPv4 transport domain.  The corresponding
         transport address is of type TransportAddressIPv4 for
         global IPv4 addresses."
    ::= { transportDomains 1 }

TransportAddressIPv4 ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d:2d"
    STATUS      current
    DESCRIPTION
        "Represents a transport address consisting of an IPv4
         address and a port number (as used for example by UDP,
         TCP and SCTP):

          octets       contents         encoding
           1-4         IPv4 address     network-byte order
           5-6         port number      network-byte order

         This textual convention SHOULD NOT be used directly in object
         definitions since it restricts addresses to a specific
format.
         However, if it is used, it MAY be used either on its own or
         in conjunction with TransportAddressType or TransportDomain
         as a pair."
    SYNTAX      OCTET STRING (SIZE (6))

To use this in a MIB module, you define a pair of fields: a
transportDomain field identifies the type of address being used, and a
corresponding field of transportAddress with the actual address value.
The corresponding address value MUST be of the type defined in
TransportDomain.

Syslog could use this approach, BUT - there are no existing
definitions for a TLS/TCP transport address, so if we want to use
this, we need to define such a transportDomain and corresponding
transportAddress. The current syslog mib document does not provide
such an update.

There is an additional complication. RFC3419 provides an enumeration
to select a transportDomain; this is done so a transportDomain can be
used as a field in an index without having the whole OID of a
transportDomain be part of the INDEX; you can use an integer
identifier.

In order to add a new transportDomain therefore requires updating
RFC3419 to keep the enumeration in sync with the possible values of
transportDomain.

So while using trasportDomain would require us to make fewer hardcoded
defintiions than Tdomain, the IETF process involved in doing the
updates to support TLS is harder.

3) InetAddressType (RFC4001) defines a mechanism that represents
internet (layer 3) addresses, and can supplement that with a
PortNumber. This address is independent of the application using it,
and is suitable for showing layer 3 addresses in MIB modules. It was
motivated by the need to represent IP addresses in MIB modules so that
either an IPv4 or an IPv6 or a DNS address could be used in the same
managed object.

Juergen, if I got any of this wrong, please feel free to correct me.
--
Now to the problem at hand:

The syslog MIB module uses a combination of types, without explanation
for why each type is used where it is.

The transportDomain is used without discussing how/where/when a TLS
transportDomain will be defined so the syslog/TLS transport can be
represented.

Some current usages in the syslog mib appear to be incorrect. You need
to think of these domain/address pairings as being discriminated
unions - the first field identifies the format of the second field;
you cannot use one part of the pair without the other. In the syslog
mib module, the type field declares what the format of the next field
is, but the address value field then describes a format that is NOT
one of the address formats supported. 

This problem is exarcerbated by mib module decriptions that are
unclear, partly because the WG members are not reviewing this document
and helping the author write clear descriptions.

This problem is also exacerbated by replies from the author that do
not answer **the questions being asked** by the MIB experts so they
can provide advice.
For example:

> We will not have this.

We ALREADY have this; We are using both InetAddress and
TransportDomain standards for representing addresses in the syslog mib
module. Why do we need to use BOTH standards rather than using ONE
standard to represent addresses?

dbh

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Sunday, December 24, 2006 2:08 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: TransportDomain. Was: Re: [Syslog] 
> Submissionofdraft-ietf-syslog-device-mib-12.txt
> 
> encapsulation, one (or

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Dec 2006 10:51:27 +0100

> transportAddress. The current syslog mib document does not provide

And I would say that TLS/TCP is actually out of scope for RFC 3419.
 
> updates to support TLS is harder.

RFC 3419 was born since we figured out that we need IPv6 definitions
for SNMP but also other protocols that represent transport layer
endpoints in MIB modules. So we tried a general approach to such
transport layer endpoints.

> either an IPv4 or an IPv6 or a DNS address could be used in the same

Yes. Other definitions (among them InetPortNumber) were later added
since MIB modules needed such definitions and the INET-ADDRESS-MIB was
a convenient place to put them.

/js

PS: I am using transport layer in this message in the more traditional
    and restrictive sense. I know that sometimes application protocols
    consider soemthing they run over as a transport layer (e.g. BEEP,
    TLS, SSH, ...) but I am not using this definition here.

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 Dec 2006 12:39:50 +0100

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Glenn M. Keeni" <[email-masked]>; <[email-masked]>
Sent: Wednesday, December 27, 2006 12:40 PM
Subject: Re: TransportDomain. Was: Re: [Syslog] Submission

> spell things out so you leave me guessing).
You did indeed clarify the purpose of InetAddress and TransportAddress and that
leaves me thinking that they do not fit very well here:-(  Rather we have a
choice of
 RFC3164 over UDP
-protocol over UDP
-protocol over TLS/TCP
RFC3195 over BEEP
(some of which can be signed) to enumerate

Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Dec 2006 14:56:05 +0100

On Thu, Dec 28, 2006 at 12:39:50PM +0100, tom.petch wrote:

> You did indeed clarify the purpose of InetAddress and
> TransportAddress and that leaves me thinking that they do not fit
> very well here:-( Rather we have a choice of
>  RFC3164 over UDP
> -protocol over UDP
> -protocol over TLS/TCP
> RFC3195 over BEEP

This is nothing new. It would help us more if you could tell us _how_
you think this should be done and why your approach will be superior
to those already put on the table here.

Thanks,

/js

---

From: "tom.petch" <[email-masked]>
Date: Thu, 28 Dec 2006 16:43:44 +0100

Dbh

Yes, another lucid explanation of a tricky subject.

The issue I wish I had never raised :-) was a response to Juergen saying

> - How do I find out which encapsulations are supported (plain, beep, tls,
...)?
> /js

which mostly I agree with.

But I think that there is no answer to finding out which encapsulations are
supported because I do not think that the way in which syslog is put together
has the concept of encapsulation; rather we have packages, bundles, like

RFC3164/-sign/UDP
RFC3195/BEEP RAW/TCP
-protocol/TLS/TCP

So by all means ask the editor of -mib to change it to use
InetAddressType/InetAddress/InetPortNumber
but I do not expect to see an answer there as to which encapsulations are
supported.

Tom Petch.

<snip>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 29 Dec 2006 03:45:18 +0900

Juergen,
        Thanks. That was helpful. I think that things do
fall into place now. I will choose option (a) below. I
will be ready to reconsider if there are some cases that
cannot be handled with this.

        Glenn