Hi, > 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. > 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 Juergen Schoenwaelder wrote:
On Fri, Dec 29, 2006 at 03:51:14AM +0900, Glenn M. Keeni wrote: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 }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.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" }This object talks about "sending" messages. (Note that the DEFVAL is syntactically wrong.)::= { 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 }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.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 }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
_______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
