Tom, > Which technique is best depends on whether the occurrence of > multiple instances is the norm, which should be modelled and > supported. I think that this is not the case for syslog and > so the additional complexity is not justified. I imagine you > think otherwise. The syslogMIB leaves it to the users to choose how they want to manage their syslog entities. I do not see the problem with that. About complexity- there is hardly any added complexity worth mention in the MIB design, implementation, and corresponding NMS development.
Glenn > tom.petch wrote: > ----- Original Message ----- > From: "Glenn M. Keeni" <[EMAIL PROTECTED]> > To: "tom.petch" <[EMAIL PROTECTED]> > Cc: "David Harrington" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Sunday, January 14, 2007 5:12 PM > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > >> tom.petch wrote: >>> I do not believe that the MIB should be modelled to support multiple > instances >>> of a syslog device as an SNMP table. >>> >>> Where multiple instances do exist in a single machine, and there is a >>> requirement to manage more than one with SNMP, then I believe that the usual >>> SNMP techniques are adequate to support this and each can be modelled within > the >>> MIB module with scalar objects, thereby simplifying the MIB module and > making >>> more likely to be implemented. > >> Using Tables is the standard SNMP technique for managing multiple >> instances. That is exactly what is done in the current MIB. > > Glenn > > Well, no. If you have two routers within a single box, served by a single > agent, there is no table in any MIB module that has ever existed that allows > you > to have both router FIBs etc as part of a single object tree starting at > 1.3.6.1.2.1. > > Some specific MIB modules have taken the view that multiple instances should > be > so supported and so have made tables of (almost) every object pertaining to > the > instance, as you have chosen to do with syslog. Most creators of MIB modules > have not done this and have relied on other standard SNMP techniques to allow > for the support of multiple instances of the router, hub, bridge, host etc > etc > etc by SNMP. > > Which technique is best depends on whether the occurrence of multiple > instances > is the norm, which should be modelled and supported. I think that this is not > the case for syslog and so the additional complexity is not justified. I > imagine you think otherwise. > > Tom Petch > > >> Glenn >>> ----- Original Message ----- >>> From: "David Harrington" <[EMAIL PROTECTED]> >>> To: <[EMAIL PROTECTED]> >>> Sent: Friday, January 12, 2007 7:31 PM >>> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus >>> >>> >>>> Hi, >>>> >>>> [speaking as co-chair] >>>> >>>> Finally, we are getting discussion of the issues of what needs to be >>>> modeled by more than two people with opposing ideas. >>>> >>>> I would like to reach consensus on this question: >>>> >>>> Is it acceptable practice to have more than one syslog application >>>> (sender, receiver, relay) running on a server/host/system >>>> simultaneously? >>>> >>>> At this point, based on Glenn's suggestion of having an experimental >>>> and a production syslogd running at the same time, and Rainer's >>>> description of syslog in a Windows environment, I think that having >>>> more than one active syslog application (sender/receiver/rerlay) is a >>>> reasonably common scenario in some environments and not in others. >>>> >>>> The current MIB interface is designed to support multiple syslog >>>> sender or receivers on the same server/host. I believe this is a valid >>>> requirement. >>>> >>>> If you agree with this, please say so. >>>> If you disagree with this, please say so. >>>> >>>> The chairs will make a determination of consensus, and this issue will >>>> be closed. >>>> >>>> David Harrington >>>> [EMAIL PROTECTED] >>>> [EMAIL PROTECTED] >>>> [EMAIL PROTECTED] >>>> co-chair, Syslog WG >>>> >>>> >>>>> -----Original Message----- >>>>> From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] >>>>> Sent: Friday, January 12, 2007 3:30 AM >>>>> To: [EMAIL PROTECTED] >>>>> Subject: [Syslog] The SIMPLE SyslogMIB >>>>> >>>>> Hi, >>>>> I will try to address David's concern about the complexity >>>>> and utility of the MIB. >>>>> The basic design principle has been to keep the MIB simple. >>>>> It has gone through several iterations, each one making it >>>>> simpler than the earlier version :-) >>>>> At present the MIB basically allows the NMS to manage the >>>>> syslog entity (sender, receiver, relay) by looking at its >>>>> (a) status ( up/down/suspended/unknown) >>>>> (b) configuration >>>>> (c) macro statistics >>>>> total number of messages (sent, received, relayed) >>>>> total number of exceptions >>>>> ( drops, discards, malforms) >>>>> The notifications will tell the NMS about change in the >>>>> syslog entity's status. >>>>> That in a nutshell is what one will want to or need to do >>>>> for basic monitoring/management. >>>>> >>>>> The MIB can provide information on multiple syslog entities. >>>>> [Scenario: two syslogd's are running on a syslog server - one >>>>> for experiments one for regular operations.] >>>>> >>>>> So if we want we may get a table like the following from the MIB. >>>>> >>>>> Syslog Status and Statistics Summary >>>>> ==================================== >>>>> >>>>> +-----+-----+--------------+------+-----+-----+---------+ >>>>> |Index|Type | Description |Status| Messages | >>>>> | |rsR* | | |Sent | Recd| Dropped | >>>>> +-----+-----+--------------+------+-----+-----+---------+ >>>>> | 1 |r-- | SecuritySys | Up | - | 120| - | >>>>> | 2 |r-- | Operations | Up | - | 1234| - | >>>>> | 3 |r-- | Experiment-1 | Up | - | 9890| - | >>>>> | 4 |-s- | SenderExpt-1 | Up | 99| - | 0 | >>>>> | 4 |rsR | Experiment-2 | Down | 1200| 2345| 0 | >>>>> +-----+-----+--------------+------+-----+-----+---------+ >>>>> * r: Receiver , s: Sender, R: relay >>>>> >>>>> Note that this is a sample. Several other columns are possible. >>>>> In a similar manner the address and port of the syslog receiver, >>>>> the number of malformed messages received etc. can be obtained. >>>>> >>>>> In more advanced usage, a syslog entity can be started [on a >>>>> specific address and port, if it is receiver] or an existing >>>>> syslog entity can be stopped or suspended. [I will not try to >>>>> explain how that can be done.] >>>>> >>>>> I think that is simple as it can be. Let me know if >>>>> a. it can be made simpler. >>>>> b. it is too simple and more detailed information is necessary. >>>>> e.g. facility wise statistics as follows. >>>>> >>>>> Facility-wise Syslog Statistics Summary >>>>> ======================================= >>>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>>> |Index|Facility|Type | Description |Status| Messages | >>>>> | | |rsR* | | |Sent | Recd| malformd| >>>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>>> | 1 | 51 |r-- | SecuritySys | Up | - | 123| - | >>>>> | 1 | 52 |r-- | SecuritySys | Up | - | 45| 45 | >>>>> | 1 | 53 |r-- | SecuritySys | Up | - | 6| - | >>>>> | 2 | 51 |r-- | Operations | Up | - | 789| - | >>>>> | 2 | 52 |r-- | Operations | Up | - | 10| 10 | >>>>> +-----+--------+-----+--------------+------+-----+-----+---------+ >>>>> >>>>> * r: Receiver , s: Sender, R: relay >>>>> >>>>> I will not recommend tables for >>>>> - facility-wise and severity-wise statistics >>>>> - facility-wise, severity-wise and host-wise statistics. >>>>> for details like that one should probably use custom applications. >>>>> >>>>> Now, talking of MIB complexity. The present MIB is simple and its >>>>> implementation is simple. ( Yes. I have implemented it.) We need to >>>>> hear - something like "I want to do 'XYZ' - how do I do it with >>>>> the MIB?". >>>>> >>>>> Glenn >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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
