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
