Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 17 Jan 2007 23:46:20 +0900

Hi Rohit,
   Thanks for the review. All the points are well noted.
I have got these fixes in the next version.

   Cheers

   Glenn
Rohit M (rrohit) wrote:
> Hi, 
> 
>   I tend to agree that MIB should support 
>   multiple syslog sender or receivers on the same server/host.
> 
>   If the device just has one; then they can only instantiate one entry
> for the same.
> 
>   I have few other comments related to the MIB:
> 
>    syslogDefaultSeverity OBJECT-TYPE
>        SYNTAX      SyslogSeverity
>        MAX-ACCESS  read-write
>        STATUS      current
>        DESCRIPTION
>            "The default syslog severity will be used to
>             compute the syslog priority that will be added
>             to syslog messages when the message needs to be
>             relayed and does not have priority specified.
> 
>             The value of this object SHOULD remain unchanged
>             across reboots of the managed entity.
> 
> [ROHIT] I am getting confused with the usage of word priority and
>         severity here. May be I am missing something here; in that
>         case, please add any REF if applicable.
> 
> 
> 
> [ROHIT] I see the usage of "The local time" at so many places; I guess
> this should be
>         "The value of sysUpTime".         
> 
>  syslogEntityStatusChanged NOTIFICATION-TYPE
>        OBJECTS   {
>                     syslogEntityControlStatus,
>                     syslogEntityControlDescr,
>                     syslogEntityControlBindAddrType,
>                     syslogEntityControlBindAddr,
>                     syslogEntityControlTransportDomain,
>                     syslogEntityControlService,
>                     syslogEntityControlConfFileName
>                  }
> 
> [ROHIT] IMHO, The notification definition should clarify that
> syslogEntityControlStatus
>         is the new status value after change. 
> 
> Thanks
> Rohit
> 
> 
> -----Original Message-----
> From: Glenn M. Keeni [mailto:[email-masked]]
> Sent: Friday, January 12, 2007 4:17 PM
> To: [email-masked]
> Subject: Re: [Syslog] MIB Issue #1 - one or multiple? Seeking consensus
> 
> Anton Okmianski (aokmians) wrote:
>>> 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.
>> 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.
> 
> 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
> 
> 
>>  
>>
>>> -----Original Message-----
>>> From: David Harrington [mailto:[email-masked]]
>>> Sent: Friday, January 12, 2007 10:31 AM
>>> To: [email-masked]
>>> 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?
>> 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.
>>>
>>> If you agree with this, please say so.
>>> If you disagree with this, please say so.
>> 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
>>>  
>>>
>>>> -----Original Message-----
>>>> From: Glenn M. Keeni [mailto:[email-masked]]
>>>> Sent: Friday, January 12, 2007 3:30 AM
>>>> To: [email-masked]
>>>> 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-masked]
>>>> https://www1.ietf.org/mailman/listinfo/syslog
>>>>
>>>
>>> _______________________________________________
>>> Syslog mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/syslog
>>>
>> _______________________________________________
>> Syslog mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/syslog
>>
> 
> 
> 
> _______________________________________________
> Syslog mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/syslog
> 

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog