Subject: [Syslog] The SIMPLE SyslogMIB

From: "Glenn M. Keeni" <[email-masked]>
Date: Fri, 12 Jan 2007 17:30:16 +0900

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-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 12 Jan 2007 11:19:50 +0100

Glenn,

thanks for the description in "plain words". At least for me, this is
very useful.

If you think about things that are common to a sufficiently large number
of syslog applications, you can not standardize on many more properties.
What syslog applications do with the messages is very different, as are
the filtering capabilities.

One thing I could think of is a MIB/special table (whatever in SNMP
terms) *just* for *simple syslog *senders**. It is common for devices
like routers, switches and firewalls to provide a limited syslog
reporting capability. What needs to be configured here is

TARGET :==
[the receiver of the syslog message]
- IP address or hostname
- port on traget system
- transport (UDP, "plain tcp" [not standardized], -tls, 3195, ...)
- facility to be used for messages
- eventually severity *level* as a filter (e.g. send only emergency
message or
  send all except debug)
- optionaly pointer to local config file

Some devices support multiple TARGETs, some only a single one.

I might have forgotten some properties, but the above description should
be usable with a very large number of devices. It may also be that you
can model this with the existing MIB ;) 

I hope my comment is useful.

Rainer

> -----Original Message-----
> From: Glenn M. Keeni [mailto:[email-masked]]
> Sent: Friday, January 12, 2007 9:30 AM
> To: [email-masked]
> Subject: [Syslog] The SIMPLE SyslogMIB
> 
> Hi,

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jan 2007 11:31:25 +0100

> reporting capability. What needs to be configured here is

[...]
 
> Some devices support multiple TARGETs, some only a single one.

The question really is who is interested to configure syslog
originators typically found on network elements via SNMP. If there are
people interested in this, they better speak up now and tell us what
information they need to get the syslogs on their products configured.

If nobody speaks up with concrete input and implementation plans, we
should perhaps drop syslog configuration via SNMP and just focus on
monitoring (and leave syslog configuration to future MIB work or leave
this to NETCONF once they have figured out to write data models).

I personally would vote for a very basic syslog monitoring MIB which
allows me to track syslog activities and to identify discrepancies
between originated syslog messages and actually received syslog
messages. Ideally, an implementation of such a MIB would hook into an
SNMP master agent via AgentX (of a similar mechanism) so I can
transparently access the MIB by talking to the main SNMP agent on the
device.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "David Harrington" <[email-masked]>
Date: Fri, 12 Jan 2007 13:31:15 -0500

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-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> Sent: Friday, January 12, 2007 3:30 AM
> To: [email-masked]

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 12 Jan 2007 19:50:39 +0100

I agree for the reasons outlined in mails before.
Rainer

> From: David Harrington [mailto:[email-masked]]
> Sent: Friday, January 12, 2007 7:31 PM
> To: [email-masked]
> Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
> 
> Hi,
> 
> [speaking as co-chair]
>

---

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Fri, 12 Jan 2007 13:53:17 -0500

> Sent: Friday, January 12, 2007 10:31 AM
> To: [email-masked]
> Finally, we are getting discussion of the issues of what 
> needs to be modeled by more than two people with opposing ideas.
> 
> Is it acceptable practice to have more than one syslog 
> application (sender, receiver, relay) running on a 
> server/host/system simultaneously? 

Absolutely. Especially, sender. 

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

Agree.

However, I am not clear it must be covered by a single SNMP agent with
single MIB. It should probably be possible to manage multiple syslog
instance with single SNMP agent per host, but we are not excluding each
instance having it own SNMP agent on different port, right?  

I don't know if this violates anything in SNMP, but it may be easier
implementation-wise no to have to integrate my syslog component with
system SNMP agent.  

Thanks,
Anton. 

> 
> The chairs will make a determination of consensus, and this 
> issue will be closed.
> 
> David Harrington
> [email-masked]
> [email-masked]
> [email-masked]
> co-chair, Syslog WG 
>  
>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 13 Jan 2007 09:17:26 +0900

> implementation-wise no to have to integrate my syslog component with

With the present MIB it is possible to have
a. A single snmp agent per host manage multiple Syslog entities
b. multiple snmp agents per host manage each managing a separate
   syslog entity, [if someone wants to do that]
and there will no problem of interoperability between systems of
type (a) and configuration (b).

Glenn

---

From: "David Harrington" <[email-masked]>
Date: Fri, 12 Jan 2007 19:19:33 -0500

Nothing we do here should prevent you from using multiple snmp agents
running on different ports if desired.

dbh

> From: Anton Okmianski (aokmians) [mailto:[email-masked]] 
> Sent: Friday, January 12, 2007 1:53 PM
> To: David Harrington; [email-masked]
> Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking 
> consensus
> 
>  
>

---

From: "tom.petch" <[email-masked]>
Date: Sat, 13 Jan 2007 13:03:58 +0100

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.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 12, 2007 7:31 PM
Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

> Hi,
>
> [speaking as co-chair]
>
> Finallture are not well-understood. What can we expect when
> > > people who did not help write the specification try to understand,
> > > implement, and use it?
> > >
> > > I usually expect a specification being promoted to Proposed
> Standard
> > > to be clear and unambiguous, and I don't see that level of
> document
> > > maturity here.
> >
> > IMHO, the core problem is that we still do not differentiate
> > between the
> > software - most thinking syslogd - and the *protocol* syslog.
> > It is NOT.
> > If it were, the IETF would be the wrong place to standardize it.
> POSIX
> > would be. I still find that the protocol definitions are
> > clear. I agree
> > it is not unambigous how to implement different parts, but that is
> not
> > because of the on-the-wire architecture but because of
> > existing API sets
> > (and software architecture).
> >
> > I personally would not like to take up the challenge of
> standardizing
> > the API set. I do not even find it desirable (from a software
> > monoculture point of view).
> >
> > Rainer
> >
>
>
>

---

From: "tom.petch" <[email-masked]>
Date: Sat, 13 Jan 2007 13:03:58 +0100

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 12, 2007 7:31 PM
Subject: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

> > |Index|Facility|Type |  Descripty, we are getting discussion of the issues of what needs to be

ion |Status|     Messages        |

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 15 Jan 2007 01:03:36 +0900

Rainer,
   There is no standard for configuration and operation for syslog.
Do there is not much of configuration supported by the MIB. The
earlier versions of the MIB had some configuration which was based
on the unix-syslog. This has been dropped in the later versions
because of its complexity and non-universality.
   However the configuration that you are suggesting is there -
the listening address/port for a syslog receiver, the transport type,
and the configuration file. This is probably the common configuration
for syslog entities that we can talk of in the absence of any document.

    Glenn

> - opionaly pointer to local config file
>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 15 Jan 2007 01:12:51 +0900

> 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

---

From: "tom.petch" <[email-masked]>
Date: Sun, 14 Jan 2007 21:43:23 +0100

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Sunday, January 14, 2007 5:12 PM
Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

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

---

From: "Rohit M \(rrohit\)" <[email-masked]>
Date: Tue, 16 Jan 2007 15:18:45 +0530

Hi Tom, 

 >> I think that this is not the case for syslog and so the additional
complexity is not justified. 

IMHO, adding an option for Multiple instance does not add additional
complexity;
It just adds an option for extensibility. 

Thanks
Rohit

-----Original Message-----
From: tom.petch [mailto:[email-masked]] 
Sent: Monday, January 15, 2007 2:13 AM
To: Glenn M. Keeni
Cc: [email-masked]
Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; <[email-masked]>
Sent: Sunday, January 14, 2007 5:12 PM
Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

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

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

> >> Finally, we are getting discussion of the issues of what needs to 
> >> be modeled by more than two people with opposing ideas.
> >>
> >> 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.
> >> sender or receivers on the same server/host. I believe this is a 
> >> valid requirement.
> >>
> >> The chairs will make a determination of consensus, and this issue 
> >> will be closed.
> >>
> >> David Harrington
> >> [email-masked]
> >> [email-masked]
> >> [email-masked]
> >> co-chair, Syslog WG
> >>
> >>
> >>>    I will try to address David's concern about the complexity and 
> >>> utility of the MIB.
> >>> It has gone through several iterations, each one making it simpler

> >>> than the earlier version :-)
> >>>    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.
> >>>
> >>> [Scenario: two syslogd's are running on a syslog server - one  for

> >>> experiments one for regular operations.]
> >>>
> >>> 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

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 16 Jan 2007 20:20:57 +0900

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

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 16 Jan 2007 12:30:26 +0100

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

> Sent: Tuesday, January 16, 2007 12:21 PM
> To: [email-masked]
> >>> I do not believe that the MIB should be modelled to support
> multiple
> > instances
> a
> >>> SNMP techniques are adequate to support this and each can be
> modelled within
> > the
> 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
> should be
> > instance, as you have chosen to do with syslog.  Most creators of
MIB
> modules
multiple
> instances
> be
application
> experimental
> valid
> will
+-----+--------+-----+--------------+------+-----+-----+---------
> +
+-----+--------+-----+--------------+------+-----+-----+---------
> +
+-----+--------+-----+--------------+------+-----+-----+---------
> +
> to

---

From: "tom.petch" <[email-masked]>
Date: Tue, 16 Jan 2007 14:39:38 +0100

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-masked]>
To: <[email-masked]>
Sent: Tuesday, January 16, 2007 12:30 PM
Subject: RE: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

Rainer

that
starting
MIB
multiple
application

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 16 Jan 2007 16:00:42 +0100

Hi Tom,

> Sent: Tuesday, January 16, 2007 2:40 PM
> To: Rainer Gerhards; [email-masked]
> does not provide the infrastructure that applications deserve. 

With all due respect, I disagree here. I do (and have done) a lot of
multi-platform work. Even CP/M or DOS 1.0 did qualify to the core
definition of an operting system. I think an OS is not defined by "it
must some Unix clone".

More seriously: as far as I know (a bit outdated knowledge) IBM MVS and
DOS/VSE, Unisys OS2200 and many others do not provide a syslog stack.
Does that disqualify them as operating systems? I doubt a number of
real-time OSs do not provide one. Again, not an operating system?
NetWare does not provide one, but you can rightly argue if it is a
general purpose OS. 

Even if you require an OS to address the application logging need, you
will find it addressed in Windows. There is the event log system. It is
different from syslog. Some find it superior, many not ;) Anyhow, it is
there and there is a standard API. 

I think we should not try to get cross-platform politics into your
discussion. You may like Windows or you may dislike it. It satisfies all
criteria to be called a full-fledged operating system. Its deployment
base would also IMHO force us to think about it EVEN if it were none. We
can not ignore real world - not even if we do not like it ;)

> You
> point out
> systems do, 

just out of curiosity: which non-*nix based OSs do provide a syslog
stack at the API level? I am not just argueing, this is a honest
question. I've worked mainly on *nix and Windows the past years, so I
might have become disconnected here...

> so that an application wishing to use those services can
> invoke them

I work well with three different ones on a single machine - but that's
quite off-topic, of course ;)

> each application does it itself, with the consequences we are now

... which is the same with SNMP. Who says there won't be a thrid-party
engine some day that fourth parties hook in? Maybe I write one? Maybe
open source? Maybe someone else does. Does that change the picture?
Maybe... 

And what about e.g. SDSc syslog and rsyslog who have multiple syslog
receiver processes for good reason? Is *nix no longer an OS because it
does not natively support RFC 3195? (just kidding ;))
> have certain common attributes - I have used this on Linux but have
not
> seen it
> particular operating system so my bias is towards, if Microsoft want
to
> model

Is it smart to call for proprietary solution if (if!) a standard one
comes at very low cost? Can we bash MS for being non-standard when at
the same time recommending them to do that ;)

Rainer
consensus
> > >>> requirement to manage more than one with SNMP, then I believe
> that
> > the usual
> > > have not done this and have relied on other standard SNMP
> techniques
> > to allow
> > >>>> more than one active syslog application
(sender/receiver/rerlay)
> > is a
syslog
> issue

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jan 2007 11:18:06 -0500

Hi,

[speaking as co-chair]

MIB Issue#1 is not about whether Windows is a real operating system. 

If you want to have that discussion feel free, but please do it
elsewhere - it is inappropriate for the syslog WG, and it is certainly
off-topic for MIB Issue#1.

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> Sent: Tuesday, January 16, 2007 8:40 AM
> > >>> 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
> > > for the support of multiple instances  of the router, hub,
bridge,
> > host etc etc
> > > is the norm, which should be modelled and supported.  I think
that
> > this is not
> > >>>>> |  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
> > |
> > >>>>> Now, talking of MIB complexity. The present MIB is simple
and
> its

---

From: "David Harrington" <[email-masked]>
Date: Tue, 16 Jan 2007 11:43:48 -0500

Hi,

[speaking as a contributor, and a MIB Doctor]

> Well, no. 

As a MIB Doctor, I generally support Glenn's statement, and not Tom's.

Using tables is **one** of the standard SNMP techniques for managing
multiple instances. I would say it is the most commonly used standard
SNMP technique for managing instances.

There are multiple ways to model instances in SMIv2, each with
advantages and disadvantages.

David Harrington
[email-masked] 
[email-masked]
[email-masked]
IETF MIB Doctor

---

From: "John Calcote" <[email-masked]>
Date: Tue, 16 Jan 2007 10:54:14 -0700

Tom,
 
Saying that Windows is not an operating system in some key respects because it doesn't provide the infrastructure that apps need (because it doesn't provide SNMP support natively) is a little like saying Solaris shouldn't be called a desktop environment because it doesn't provide Beryl as a cool 3D windowing environment. 
 
That's just silly - of course Windows provides this important infrastructure - it's just called WMI rather than SNMP. I know they're not the same protocol, but they ARE the same infrastructure. And this exactly supports MS's marketing model - get them hooked into our stuff so they have to continue to use our stuff. Not good for the interop world, but very good for MS - and the client base they have shows that a LOT of people agree with them (even if it hurts! :)
 
Sorry for the side track, I just couldn't resist.
 
John
 
-----
John Calcote ([email-masked])
Sr. Software Engineeer
Novell, Inc.

>>> On Tue, Jan 16, 2007 at  6:39 AM, in message <045301c73974$0a5b65a0$0601a8c0@pc6>, "tom.petch" <[email-masked]> wrote:
Rainer

Tom Petch

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

Rainer

that
starting
MIB
multiple
application