Although these comments are a response to Glenn, I would appreciate others on the list reading and commenting on pp3-4 of the syslog-mib which describes syslog (nothing MIBby, honest) in terms I am struggling with, if only to say 'yes, that is exactly how I see syslog being used'.
Recall that IESG tends to require a MIB to allow protocols to advance so unless we agree on a MIB, we may not have a syslog-protocol:-( Glenn Ok so far but ...:-) you talk of 'receiving and forwarding syslog messages', that is of relay and collector in syslog-protocol terms; what about sender? Do you envisage any use of this MIB for an entity that is only involved in sending packets conforming to syslog-protocol? And when the document talks of receiving messages, are these messages ones that conform to syslog-protocol or does it include messages in a proprietary format that may or may not be emitted as syslog-protocol messages? And when this document talks of this being used to manage a group of syslog devices, what makes this a group? Are they all running under the same instance of an operating system (allowing sysplex as a single operating system)? If not, what makes it a group? Tom Petch ----- Original Message ----- From: "Glenn Mansfield Keeni" <[EMAIL PROTECTED]> To: "Tom Petch" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, January 19, 2006 3:36 AM Subject: Re: [Syslog] draft-ietf-syslog-device-mib-07.txt > Tom, > Apologies for the delay in responding. > > I have had a look at the syslog MIB, and am confused, at a fairly fundamental > > level, about the relationship of the MIB to the other documents, RFC3164 and > > syslog-protocol. The last two have a common framework/architecture, spelt out > > at the beginning of each, with a common terminology of device, relay, collector, > > server. The MIB is different. > > > > Thus, it is a device MIB (not a protocol MIB) (quoting) 'to monitor a group of > > syslog devices' and 'One or more syslog devices which may be on the same host'. > > '"facilities" generate messages indicating their own status or the occurance of > > events. These messages are handled by what has come to be known as the syslog > > process or device' > I agree with you that the definition of "syslog device" is NOT consistent with > RFC3164 and syslog-protocol-17. I will fix this in the next draft. Thanks for > pointing that out. > As far as management is concerned the syslog daemon [receiver/relay] is an > application ( doing a specific task viz. receiving and forwarding syslog messages). > There may be several syslog daemons on a host. That has been provisioned for in the > MIB. > > Which leaves me with the impression of a loosely-coupled system of hosts > > communicating via proprietary protocols with multiple instances of a syslog > > daemon per host forwarding messages onward. Really? > There is nothing that prohibits one from using multiple syslog daemons. > > could be but I think I am> lost here and that the introduction should be recast > > in the language of RFC3164/syslog-protocol (even if it is intending to convey the > > above). > Right. I will find a better name for the entity that we intend to manage using the > MIB and of course must not conflict with the terms used in 3164/syslog-protocol. In > the absence of a better name I may use the term "entity" itself. It receives, stores > and forwards syslog messages. Let me know if I have missed out something. > > Cheers > > Glenn > > > > > Tom Petch > > > > > > _______________________________________________ > > Syslog mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/syslog > > > -- > +----------------------------------------------------------+ > Cyber Solutions Inc. Phone 022-303-4012 > 6-6-3, Minami Yoshinari Fax 022-303-4015 > Aoba-ku, Sendai, Japan 989-3204 e-mail [EMAIL PROTECTED] > +----------------------------------------------------------+ > > _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
