Hi, [speaking as a contributor]
Thank you Rainer for such a clear response. I recommend that text similar to Rainer's response be included in the DESCRIPTION clause for the syslogEntityControlTable, to explain why multiple syslog entities are modeled in the MIB module. I recommend capturing the discussion within the MIB module definition rather than in the document introductory sections, because MIB modules are often distributed already-extracted from the surrounding document, and NMS help screens are often fashioned from the DESCRIPTION clauses. So putting this info in the table description clause will get the explanation to the users. I would not object to **also** having it discussed in the introductory text sections. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: Rainer Gerhards [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 14, 2006 9:52 AM > To: David Harrington > Cc: [EMAIL PROTECTED] > Subject: RE: [Syslog] Syslog-mib-11 > > David, > > Sorry for the late reply. > > In my experience: it depends... > > Under Linux/Unix, it is most common to have a single instance of the > syslog process running. All other processes communicate with that > process via local IPC, but the ultimate sender is the single > instance of > syslogd running. I have seen some deployments where multiple syslogd's > run on a single machine. This is rare and, if so, almost > always because > of different security domains (e.g. have a different process listen to > locally generated messages vs. Network received messages). > > From a design perspective, it might be a choice to have multiple > processes make up for the syslog subsystem. A real-world > example is SDSC > syslogd, which runs different stacks in different processes. Rsyslog > also has the RFC 3195 receiver separated. AFAIK these processes do not > share internal information. It is questionable if such can always be > assumed. > > Under Windows, it is common to have different syslog sender processes, > but typically only one receiver is running. This stems back > to the fact > that there is no syslog subsystem is available on Windows so every > vendor brings in its own. The key difference to *nix is that here each > program is itself a syslog sender, while under *nix each > program formats > the MSG part of the message, passes that to an API and the > syslogd picks > and sends it from there (effectively relaying the message). > > I hope this information is useful. > > Rainer > > > -----Original Message----- > > From: David Harrington [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 12, 2006 9:36 PM > > To: [EMAIL PROTECTED] > > Subject: [Syslog] Syslog-mib-11 > > > > Hi, > > > > In my latest review of syslog-mib-11, I have started to believe that > > Tom was right when he questioned the MIB module design, which models > > multiple syslog entities in a table, so one SNMP engine deals with > > multiple syslog senders, relays, and/or recievers on the same host. > > > > This adds complexity in the MIB design that I am not convinced is > > necessary. As the terminology in the MIB document has > gotten closer to > > other WG documents, this has become somewhat clearer to me. > > > > Tom recommended that the MIB module only model a single > syslog entity. > > Different instantations of the MIB module can be represented as > > existing in different contexts (e.g. in different > communities), so one > > SNMP engine can still deal with multiple syslog senders, relays, > > and/or receivers on the same host, but the MIB module itself becomes > > simpler. > > > > We should be sure the MIB module reflects real world requirements. I > > do not have much operational experience, so I need your input. > > > > In real deployments, is it **typical** to have multiple > syslog stacks > > running on the same host, each with a different bind > address and port > > number and config file? or is it more common for most > applications to > > share one syslog process (e.g., daemon) that operates via one > > address/port? > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > 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
