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 PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] co-chair, Syslog WG > -----Original Message----- > From: Juergen Schoenwaelder [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 28, 2006 3:30 PM > To: Glenn M. Keeni > Cc: Wijnen, Bert (Bert); [EMAIL PROTECTED] > Subject: Re: [Syslog] TransportDomain issue > > 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 > > -- > Juergen Schoenwaelder {International|Jacobs} > University Bremen > <http://www.eecs.iu-bremen.de/> P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Syslog mailing list > Syslog@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
