Being not MIB-literate, I tend to agree that it does not add much complexity if there is a table which most often includes just a single element.
What is used in practice. It depends on your point of view. If you look at deployments, a single engine is the vast majority. If you look at number of different implementations, I am not so sure. In any case, I would vote for extensibility IF that does NOT add considerable complexity. I can not make an informed judgement on the later. Rainer > -----Original Message----- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 16, 2007 12:21 PM > To: [EMAIL PROTECTED] > Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus > > 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 > >>>>> [email protected] > >>>>> https://www1.ietf.org/mailman/listinfo/syslog > >>>>> > >>>> > >>>> _______________________________________________ > >>>> Syslog mailing list > >>>> [email protected] > >>>> https://www1.ietf.org/mailman/listinfo/syslog > >>> > >>> _______________________________________________ > >>> Syslog mailing list > >>> [email protected] > >>> https://www1.ietf.org/mailman/listinfo/syslog > >> > > > > > > _______________________________________________ > Syslog mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list [email protected] https://www1.ietf.org/mailman/listinfo/syslog
