Rainer

Using this as a  convenient peg on which to hang an answer.

You asked about software architecture.  I think that for all its commercial
success, Windows is not, in some key respects, an operating system in that it
does not provide the infrastructure that applications deserve.  You point out
that it does not have an SNMP engine or a syslog engine.  Other operating
systems do, so that an application wishing to use those services can invoke them
(API, inter-process call, 127.0.0.n via a socket ....) at a level that is
suitable for the application.

Windows does have a number of excellent third-party SNMP engines, so I expect to
see one of those installed - but only one - with a load of fourth party
applications hooking into the services that the snmp-engine provides.

For the other software you mention, I do not see them as providing a service for
multiple other software to use ie I only have the one web browser, e-mail
server/client etc and often that limitaton is hard-coded into proper operating
systems as well (Windows purports to support multiple web browsers - 'do you
want this to be your default?' - but my attempts to run them have been a
disaster).

You comment that Windows has no syslog engine to serve multiple applications, so
each application does it itself, with the consequences we are now discussing.

As to how much gets modelled in a MIB module, there is a standards based Host
Resources MIB module (RFC2790) which models processes and expects all of them to
have certain common attributes - I have used this on Linux but have not seen it
on Windows.

On the other hand, most operating system vendors do have large quantities of
proprietary MIB modules that do model the software architecture of their
particular operating system so my bias is towards, if Microsoft want to model
this, let them do it themselves:-)

Tom Petch

----- Original Message -----
From: "Rainer Gerhards" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 16, 2007 12:30 PM
Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus


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
> >>>>> 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

_______________________________________________
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

Reply via email to