David,
Thanks for the perspective on the comments. The issue still
remains open:
a. Does the WG want syslog to be manageable using
Internet Standard management protocols?
b. If the answer is "yes",
b-1 Then we retain the Syslog-MIB work item on the WG charter.
b-2 Examine the existing work e.g.
the draft syslog-MIB proposal, available at
http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17,
kick off discussion on this work.
c. If the answer is "no", then this line of discussion is closed
we drop the Syslog-MIB work item from the charter.
I would think that it is fair to take discussions on adequacies and
inadequacies of the existing Syslog-MIB work as a "yes" response.
Glenn
David Harrington wrote:
> Hi,
>
> I am in the unenviable position of having to respond to this message
> from the standpoint of being syslog WG co-chair, a MIB Doctor and
> OPSDIR member, and a contributor. The things I need to respond are
> spread throughout Glenn's email. I will try to accurately state my
> perspective for each set of comments.
>
> comments inline.
>
> David Harrington
> [email protected]
> [email protected]
> [email protected]
>
>> -----Original Message-----
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Glenn M. Keeni
>> Sent: Sunday, July 26, 2009 2:59 AM
>> To: syslog
>> Subject: Re: [Syslog] Proposed charter
>>
>> Hi,
>> The Syslog protocols have been defined and are in
>> "proposed standard" stage. Now the working group needs
>> to decide whether it needs Syslog to be manageable.
>
> As co-chair, I think this is slightly wrong. The IETF needs to make
> this decision, and the IETF is represented by the syslog WG (which
> focuses on developing proposed solutions within the scope of its
> charter), the area directors (who focus on area-wide consensus, and
> possibly multi-area consensus), the IESG (who focus on IETF-wide
> consensus), and the WG chairs (who focus on balancing the various
> inputs and trying to chart a way forward). The WG is not the only
> entity that needs to make this decision.
>
>> To make it manageable we need to define a Syslog-MIB
>> (Management Information Base) module.
>
> As a MIB Doctor and OPSDIR member and co-chair, I know this statement
> is wrong.
>
> syslog has been a defacto standard for many years, and already has
> solutions to make it manageable. Syslog-conf is widely used for
> configuration, and there are many proprietary MIB modules for
> monitoring syslog, and many applications that know how to process
> syslog messages to sort them, display them to operators, and correlate
> them with other management information such as SNMP traps.
>
> There are many ways to make a protocol manageable; writing a
> standards-track MIB module is one option. This WG, and the whole IETF,
> needs to decide whether syslog should have a standards-track solution
> for managing syslog (or for managing any other IETF standards-track
> protocol).
>
> When the syslog WG was started, it was common practice in the IETF to
> address manageability by requiring WGs to "write a MIB" to manage and
> monitor their proposed protocol standards using the Internet-Standard
> Management Framework (effectively SNMP + MIBs). The philosophy behind
> that practice has been changing. After significant discussion with the
> operator and vendor communities, the IETF has been moving toward a
> philosophy of multi-protocol/multi-solution management, and away from
> the "write a MIB" approach. The discussion is ongoing, and those
> interested can follow the discussion mostly in the OPSAWG WG and on
> the IETF Discuss mailng list.
>
> This WG should make a decision about whether they want to propose an
> IETF standards-track solution for managing syslog. That solution might
> be a standards-track MIB module, or a non-standards-track MIB module.
> It might be a proposed standard for syslog-conf, or a best current
> practices document for using proprietary solutions, or an
> Informational document that describes how syslog is currently being
> managed and monitored, and so on.
>
> As co-chairs, Chris and I have not seen consensus on what the WG
> thinks is the right direction to follow.
>
>> This has been
>> an ongoing work for several years which was shelved
>> at some stage to let the WG focus on the core protocol
>> documents.
>
> As co-chair: It is true that we shelved the proposed MIB module. Part
> of the reason was to wait until the core documents stabilized, so we
> had consistent terminology and clearly defined concepts to manage. The
> other reason for shelving the proposal is the co-chairs did not feel
> there was WG consensus on how to do management of syslog through a
> standards-track MIB module.
>
>> The working group is being rechartered
>
> As co-chair: The working group is considering rechartering.
>
> As contributors, Chris and I need to be convinced there is consensus
> to do so, and that resources are willing to commit to doing the work,
> and if so the chairs will work with the syslog and IETF communities to
> establish a new charter proposal with clear objectives and milestones,
> and then ask the area directors (who may consult with the IESG and
> IAB) to approve the proposed charter.
>
>> and we
>> are looking for comments/feedback on the Syslog-MIB
>> proposal.
>
> As co-chair and contributor: We are looking for comments/feedback on
> any proposed work direction for a re-chartered syslog WG. We are
> looking for commitment from people to do the work. We are looking for
> an expression of interest from multiple independent resources to
> produce a vendor-neutral solution.
>
>> In the absence of comments the chairs have
>> threatened to drop the Syslog-MIB proposal from the
>> charter.
>
> As contributor: In the absence of comments and commitments, Chris and
> I threaten to drop **any** proposal from the charter proposal that we
> are working to develop and present to the area directors. Chris and I
> are using our chair experience to help fashion a viable charter.
>
> As co-chair: Let me make this clear - anybody can write a proposed
> charter for a WG and present it to the area directors for approval;
> you do not need current chairs to do so. Working with the current
> chairs to fashion a charter makes a difference because the area
> directors have experience with us, and they know we know how to
> fashion a charter, and if this is a "re-charter" that might involve
> retaining the existing chairs. Any proposed WG could be called
> something other "syslog WG". It could be created in the Security area
> or the OPS area (and would need to be presented to the appropriate
> area directors). The current chairs may or may not continue as chairs
> for (or even be involved in) a rechartered or newly chartered WG.
>
>> If that happens, for some time, you will NOT
>> be able to monitor/manage syslog from your management
>> console using the Internet Standard management
>> protocols.
>
> As a MIB Doctor and OPSDIR member:
>
> If your management console currently supports management of syslog,
> then its current functionality will not be affected by not having this
> in the proposed charter. If your management console currently uses the
> Internet Standard management protocols (SNMPv3) to manage syslog, the
> current functionality will not be affected.
>
> If your current management console uses data from vendor-proprietary
> MIB modules to manage syslog, and the device you are managing supports
> the new IETF syslog, and the vendor-proprietary MIB modules do not
> support the IETF syslog, or the vendor-proprietary MIB modules are
> changed to support IETF syslog and your console is not changed to
> match, then your management console may not do a good job of managing
> that IETF-compliant syslog implementation.
>
> If your management console uses proprietary MIB modules from different
> vendors to manage the new IETF syslog, then your management console
> may need to present (and operators to understand) multiple different
> ways to manage IETF syslog, and operators and applications may have
> some difficulty correlating management information about IETF syslog
> across vendors.
>
> If the devices your management console manages do not support an
> industry-standard MIB module for managing IETF syslog, then your
> management application(s) may not be able to take advantage of some
> features of the IETF syslog solution (and newly emerging extensions to
> the IETF syslog solution). Having a standards-track MIB module would
> help enable operators and management applications to manage IETF
> syslog in a more standardized manner.
>
>> So, keep the comments coming.
>
> Yes. Please do.
>
>> A simple explanation of the current proposed
>> Syslog-MIB is given below. It explains the design
>> principles and more importantly the kind of things
>> that can be done by the Syslog-MIB.
>> If you want to see the actual draft syslog-MIB
>> proposal, please try
>> http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17
>
> As co-chair:
> Tom Petch, Juergen Schoenwaelder, and Bob Natale (and possibly others)
> questioned whether the design of the MIB module in this WG proposal
> represented WG consensus. Chris and I reached the conclusion that
> there was a lack of consensus on how the MIB module in the WG MIB
> draft should be designed. If there is no consensus, then it will be
> impossible for this MIB module to represent such a consensus.
>
> As co-chairs, in consultation with the area director, we decided that
> there was insufficient commitment of resources to reach consensus and
> continue work on the current MIB draft under the existing charter.
>
> As contributors: Chris and I want to see clear statements of interest
> from a variety of contributors for developing a standards-track MIB
> module, plus commitments to do the work, including commitment to reach
> a consensus on the design. We welcome comments about whether a MIB
> module should be part of a new charter.
>
> dbh
>
>> Thanks and cheers
>>
>> Glenn
>>
>> ----------------------- Simple SyslogMIB --------------------
>> Design
>> =======
>> 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 (Network Management
>> System) to manage the syslog entity (sender, receiver, relay) by
>> looking at its
>> (a) status ( up/down/suspended/unknown)
>> (b) configuration (Address, protocol, port number etc.)
>> (c) macro statistics
>> total number of messages (sent, received, relayed)
>> total number of exceptions
>> ( drops, discards, malforms)
>> The asynchronous notifications will alert the NMS about changes
>> in the syslog entity's status.
>> That in a nutshell is what one will want to or need to do
>> for basic syslog 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.]
>>
>> Examples:
>> =========
>> 1. We may want to get a table like the following on our NMS
>> console:
>>
>> 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.
>>
>> 2. Facility wise statistics can be generated 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
>>
>>
>> 3. In a more advanced scenario,
>> i. a syslog entity can be started, from the NMS console,
>> [with a specific address and port, if it is a receiver] or,
>> ii.an existing syslog entity can be stopped or suspended.
>> [I will not try to explain how that can be done.]
>>
>> I think that is as simple as it can be. Let me know if
>> a. it can be made simpler or,
>> b. it is too simple and more detailed information/functions
>> are necessary.
>>
>> _______________________________________________
>> Syslog mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/syslog
>>
>
_______________________________________________
Syslog mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/syslog
