Subject: [Syslog] TransportDomain issue

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

Hi,
   After some discussion on the list and explanations
from Juergen I porpose the following MIB description
of the syslog transport. Let me have your comments.

   Cheers

   Glenn

+-----------------------------------------------------------+

SyslogEncapsulation  ::=  TEXTUAL-CONVENTION
     STATUS  current
     DESCRIPTION
         "This textual convention enumerates the encapsulations
          of the syslog message that is used between syslog
          application endpoints.
         "
     REFERENCE
         "TBD.
         "
     SYNTAX  INTEGER
          {
            other           (0),
            none            (1),  -- RFCUDPX  (no encapsulation)
            tls             (2),  -- RFCTLS
            beep            (3),  -- RFCBEEP
            sign            (4)   -- RFCSIGN
          }

syslogDefaultEncapsulation OBJECT-TYPE
     SYNTAX      SyslogEncapsulation
     MAX-ACCESS  read-write
     STATUS      current
     DESCRIPTION
         "The default encapsulation that the syslog
          entity will use to send syslog messages.

          The value of this object SHOULD remain unchanged
          across reboots of the managed entity.
         "
     REFERENCE
         "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN
         "
     DEFVAL  { "1" }
     ::= { syslogSystem 5 }

SyslogEntityControlEntry ::=
     SEQUENCE {
         -----
         -----
         syslogEntityControlBindAddrType
              InetAddressType,
         syslogEntityControlBindAddr
              InetAddress,
         syslogEntityControlService
              SyslogService,
         syslogEntityControlEncapsulation
              SyslogEncapsulation,
         -----
         -----
    }

syslogEntityControlBindAddrType OBJECT-TYPE
     SYNTAX      InetAddressType
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The type of Internet address which follows
          in syslogEntityControlBindAddr.
          If this syslog entity is not a syslog receiver,
          the value of this object will be 'unknown' (0)."
         "
     ::= { syslogEntityControlEntry 3 }

.ne 10
syslogEntityControlBindAddr OBJECT-TYPE
     SYNTAX      InetAddress
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The specific address the syslog receiver 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.
          If this syslog entity is not a syslog receiver, the value
          of this object will be a zero-length string."
         "
     ::= { syslogEntityControlEntry 4 }
syslogEntityControlService OBJECT-TYPE
     SYNTAX      SyslogService
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The service name or port number that this syslog receiver
          will be listening on for syslog messages.

          If this syslog entity is not a syslog receiver the value
          of this object will be zero.

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

syslogEntityControlEncapsulation OBJECT-TYPE
     SYNTAX      SyslogEncapsulation,
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The encapsulation that will be used for syslog messages.

          If no value is specified, the syslog entity will use the
          encapsulation specified in syslogDefaultEncapsulation.
         "
     ::= { syslogEntityControlEntry 7 }

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Dec 2006 21:29:36 +0100

> of the syslog transport. Let me have your comments.

My understanding is that signed syslog messages can be shipped over
different transports. The signed syslog ID says:

   This specification is independent of the actual transport protocol
   selected.  The mechanism is especially suitable for use with the
   syslog protocol as defined in RFC xxxx [14] because it utilizes the
   STRUCTURED-DATA elements defined in that document.  It may also be
   used with syslog packets over traditional UDP [4] as described in RFC
   3164 [10].  It may also be used with the Reliable Delivery of syslog
   as described in RFC 3195 [11], and it may be used with other message
   delivery mechanisms.  Designers of other efforts to define event
   notification mechanisms are encouraged to consider this specification
   in their design.

In other words, I think sign(4) does not make sense as an
encapsulation mechanism.
 
>         "RFCUDPX, RFCTLS, RFCBEEP, RFCSIGN

This object talks about "sending" messages. (Note that the DEFVAL is
syntactically wrong.)

>     ::= { syslogEntityControlEntry 6 }

These three objects are for the syslog receiver endpoint. I still
question the usefulness of the service name (since it has local
significance) and suggest to use an InetPortNumber instead and to
rename this to syslogEntityControlBindPort.

>     ::= { syslogEntityControlEntry 7 }

This object now again talks about sending syslog messages. I am still
confused. Before we beat this further, it might be useful to agree
what the purpose and usage of these objects is going to be.

/js

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

---

From: "David Harrington" <[email-masked]>
Date: Thu, 28 Dec 2006 16:34:45 -0500

Hi 

[speaking as co-chair]

As this discussion continues, and based on the updated description
clauses, it appears more and more obvious that some objects are only
important for receivers or for senders or for relays:

syslogEntityControlBindAddrType = receiver
syslogEntityControlBindAddr = receiver
syslogEntityControlBind(Port) = receiver
syslogEntityControlService  = receiver
syslogEntityControlMaxMessageSize = receiver
syslogEntityOperationsMsgsIgnored = receiver (exceeds max message
size)
syslogEntityOperationsMsgsReceived = reciever
syslogEntityOperationsMsgsIllFormed = receiver
syslogEntityOperationsLastMsgRecdTime = receiver (or for internal
debugging?)

syslogEntityControlEncapsulation = sender
syslogEntityOperationsMsgsDropped = sender (internal debugging
information?)
syslogEntityOperationsLastMsgRecdTime = sender (internal debugging?)
syslogEntityOperationsLastMsgTransmittedTime = sender, relay

syslogDefaultFacility = relay
syslogDefaultSeverity = relay
syslogEntityOperationsMsgsRelayed = relay
syslogEntityOperationsLastMsgTransmittedTime = sender, relay

syslogEntityControlConfFileName = entity

So let's take the tables, break them out according to role and
document what is needed for each role. After that exercise, we may
reach the conclusion that much of the info could be modeled for a
generic syslog entity, but at this point I am far from convinced that
is true.

So far, the members of this WG have stayed out of the mib discussions,
so the overall design (scalar versus tabular) comes down to Tom versus
Glenn, and that does not denote consensus. We have seen one approach,
but not the other, so let's design an alternate mib that has the
information broken out by sender/receiver/relay, and is scalar with
different instances represented in different SNMP contexts. This may
simplify the design considerably and help us to understand what needs
to be in the official mib module.

Who wants to design an alternate mib module for the WG? It doesn't
have to be perfect from a MIB standpoint; it needs to do a reasonably
good job of showing what needs to be modeled for 1) a syslog receiver,
2) a syslog sender, and 3) a syslog relay. Glenn? Tom? Others?

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Thursday, December 28, 2006 3:30 PM
> To: Glenn M. Keeni
> Cc: Wijnen, Bert (Bert); [email-masked]
> Subject: Re: [Syslog] TransportDomain issue
>

---

From: "tom.petch" <[email-masked]>
Date: Fri, 29 Dec 2006 11:32:24 +0100

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>; "'Glenn M. Keeni'" <[email-masked]>
Cc: "'Wijnen, Bert (Bert)'" <[email-masked]>; <[email-masked]>
Sent: Thursday, December 28, 2006 10:34 PM
Subject: RE: [Syslog] TransportDomain issue

> important for receivers or for senders or for relays:

Agreed although I disagree with some of your characterisations.

More fundamentally, who is going to implement a MIB module where?

Not I (sadly) but the one I want to see is in the managed network device, the
sender, not relay/collector/receiver ( hosts which are likely to have plenty of
non-MIB ways of doing things) so that is my prejudice.  But for this work to
have value, someone needs to be likely to implement this and I do not know who
that might be; it is their views that I think matter most and I do not know what
those views are - it may be that all potential implementors only want to
implement on Windows platforms:-) which would in turn affect what should be in a
MIB module.

Whatever, my list of desirable objects is slightly different, as follows (I have
shortened the object names to make them easier to read and write, the additional
words can always go back later).  Also, I see a relay as a sender+receiver so
with one exception, I see no object as particular to a relay.

syslogAddrType / syslogAddr / syslogPort
 endpoint on which a receiver (relay) listens
 endpoint to which a sender (relay) sends

syslogService
 do not understand this except as a port, for which use syslogPort

syslogMaxMessageSize
 maximum message size a receiver (relay) will accept
syslogMsgsTooLarge
 messages received and discarded as too large by receiver (relay)
syslogMsgsReceived
 total messages received valid and invalid by receiver (relay)
syslogMsgsIllFormed
 messages received and discarded incorrect format by receiver (relay)
syslogMsgsLastRecdTime
 sysUpTime of last message received by receiver (relay)

syslogEncapsulation
 receiver (relay) formats supported (BEEP RAW, BEEP COOKED, TLS, SIGN ...)
 sender (relay) formats supported
syslogMsgsSent
 total messages sent successfully by sender (relay)
syslogMsgsDropped
 messages that could not be sent by sender (relay)
syslogMsgsLastSentTime
 sysUpTime of last message sent by sender (relay)

syslogCapability
 sending, receiving (probably as enumerated bits so both = relay)
syslogDefaultSeverity
 unclear of the role of this

syslogMsgsRelayed
 messages received and relayed (excludes messages originating in this process)

syslogConfFileName
 configuration file  - all

plus perhaps, at least for sender,

syslogHostname
syslogAppName
syslogProcId

Tom Petch

<snip>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 29 Dec 2006 22:12:01 +0900

Hi,
 > what the purpose and usage of these objects is going to be.
The objects are for monitoring. The Manager/NMS will be able
to find the configuration of the syslog receiver(s) on a host.
E.g. there may be a syslog-tls receiver, and multiple syslog-udp
receivers on a host. In one scenario the table will look like

Type  Address   Port Encapsulation   MsgsReceived  MsgsDropped
  V4   1.1.1.1    11    TLS              R1             D1
  v6   v6address  22    None             R2             D2
  v4   3.3.3.3    33    None             R3             D3

Now, I am not sure whether the same receiver can have multiple
endpoints. The present MIB does not allow for multiple end-points.

Glenn

---

From: "Wijnen, Bert \(Bert\)" <[email-masked]>
Date: Fri, 29 Dec 2006 15:47:24 +0100

Quick comment: I thought/think that the MIB doctors in general
advise/prefer to start enumartions at 1 and not at zero.

Bert 

> From: Glenn M. Keeni [mailto:[email-masked]] 
> Sent: donderdag 28 december 2006 19:51
> To: [email-masked]; Wijnen, Bert (Bert)
> Subject: TransportDomain issue
> 
> Hi,
>    After some discussion on the list and explanations from 
> Juergen I porpose the following MIB description of the syslog 
> transport. Let me have your comments.
> 
>    Cheers
> 
>    Glenn
>