Hi,
Apologies for the delayed to the syslog-mib related queries and
comments.
As Dave has said it - the proposed syslog-mib attempts to provide
the dials and knobs that would be required my most if not all syslog
implementations. I have used the present BSD Syslog as the least common
denominator. I have consulted the BSD Syslog documentation and man pages
to arrive at the MIB design.
If there are some Objects that are "required" but left out in the MIB
or Objects that are in the MIB but are unlikely to be used - we would
like to hear about it. The present MIB is far from its final form.
I am yet to refer to the document
http://www.balabit.hu/static/syslog-ng/reference/book1.html
cited by [EMAIL PROTECTED] (sorry I do not have the name). I
intend doing that sometime before revising the present draft. But
meanwhile I would like to hear "I want to do this and the MIB does not
offer a way to do it". Lets try to arrive at some consensus on such
requirements. If there is consensus we add it to the MIB otherwise we
leave it for vendor specific MIBs. Adding MOs to the MIB to provide
more dials and knobs is the smaller of the problems.
I plan to have a revised version of the MIB ready by Mid February-
the major changes will be in the "DESCRIPTION" and the "REFERENCE"
clauses of the MOs in the MIB and the Security Considerations section.
The "DESCRIPTIONS" need to be accurate and unambigious as these will
guide implementors. In the present draft I have not done been able to
put in enough efforts on the descriptions.
The "REFERECNCES" will supplement the "DESCRIPTIONS" and here I need
some advice. I intend using the BSD manpages in the "REFERENCES" clause.
Will this be OK? Is there any other more specific reference ? It seems
to be difficult to specify the objects for managing a protocol that does
not have a standard reference.
Dave, did you volunteer to help me with the Security Considerations
scetion? I will greatly appreciate any help.
Thanks and Cheers
Glenn
Harrington, David wrote:
> It is fairly common to provide a standard mib for basic configuration
> (least common denominator).
>
> Such a standard mib is often supplemented by a vendor-specific mib to
> allow users to provide more fine-tuned configuration.
>
> Vendors can support a standard configuration request by using default
> values for all the non-standard attributes, where a standard configuration
> is adequate for the operator. This has the benefit that an operator can use
> a standard configuration request across vendors.
>
> dbh
>
>
>>-----Original Message-----
>>From: Rainer Gerhards [mailto:[EMAIL PROTECTED]]
>>Sent: Thursday, January 09, 2003 4:15 PM
>>To: Harrington, David; [iso-8859-1] [iso-8859-1] Magos�nyi
>>�rp�d; Glenn
>>Mansfield Keeni
>>Cc: [EMAIL PROTECTED]
>>Subject: RE: syslog-mib
>>
>>
>>Hi,
>>
>>
>>>I think the answer to your question is "by defining a
>>>standard so vendors are encouraged to use a common approach
>>>rather than everybody using their own vendor-specific
>>>proprietary approach."
>>>
>>>If we were not trying to define an industry standard, I
>>>wouldn't see the point of doing this work in the IETF.
>>
>>I agree with this approach, but I have to admit that in my
>>point of view this can only provide a basic configuration set
>>for some typical uses. We, for example, have flexible,
>>firewall-like rule sets in our products (which consume and
>>emit syslog but are not limited to this) which can not be
>>configured by the MIB.
>>
>>Anyhow, I think providing a guideline to vendors is
>>definitely helpful and there are many syslog devices out that
>>can work perfectly with the provided config info.
>>
>>Just my 2 cents...
>>
>>Rainer Gerhards
>>Adiscon
>>
>>
>>
>
>
