Subject: Re: [Syslog] Proposed charter

From: "Chris Lonvick (clonvick)" <[email-masked]>
Date: Sat, 25 Jul 2009 16:06:15 -0700

Hi Glenn and all,

We need to hear from others.  IIRC, the concepts were getting a bit difficult to follow and not everyone was nodding their heads together on this.

All: please respond with your comments on this.  The default is to exclude items from the charter unless we feel that there is a strong commitment to advance a document.

Thanks,
Chris

 -----Original Message-----
From: 	Glenn M. Keeni [mailto:[email-masked]]
Sent:	Friday, July 24, 2009 12:30 AM Pacific Standard Time
To:	Chris Lonvick (clonvick)
Cc:	[email-masked]
Subject:	Re: [Syslog] Proposed charter

Hi,
Chris Lonvick wrote:
> Hi Folks,
> 
> David and I discussed and we would like to propose the following as a 
> new charter.
> 
> The goal that is listed is for what we have commitment at this time.  We 
> can add more goals but that will only happen if we have solid commitment 
> for people who will write a document and for people who will review it.
> 
> If you really want something that's in the ppt (you can find that in the 
> on-line agenda) to be included in this charter, then get your comments 
> to the list.

I would strongly recommend that we do the SYSLOG-MIB work. It was
waiting on the finalization of the other Syslog protocol components.
Now that we have those in place we can wrap this one up. I will
volunteer the time and the effort to take this through. Unfortunately,
I will not be making it to the Tuesday meeting, but I hope to follow
the proceedings online.

> We would appreciate any comments to this draft charter before the WG 
> meeting on Tuesday.

Cheers

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 26 Jul 2009 08:53:43 +0900

Hi Chris,
Chris Lonvick (clonvick) wrote:
> Hi Glenn and all,
> 
> We need to hear from others.  IIRC, the concepts were getting a bit difficult 
> to follow and not everyone was nodding their heads together on this.
There was some discussion on
   a. whether the MIB needed to support multiple syslog entities
      ( originators, receivers, relays) in a single MIB
   b. need for additional objects to configure the syslog
      entities ( e.g. filters)
   c. terminology
Then we decided to wait till the protocol documents to got through.
> 
> All: please respond with your comments on this.  The default is to exclude 
> items from the charter unless we feel that there is a strong
commitment to
> advance a document.

I think that we can very well move ahead from here. I will resend
the summary "SIMPLE SyslogMIB" mail to the list for further comments.

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 26 Jul 2009 09:59:05 +0900

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.
To make it manageable we need to define a Syslog-MIB
(Management Information Base) module. 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.
  The working group is being rechartered and we
are looking for comments/feedback on the Syslog-MIB
proposal. In the absence of comments the chairs have
threatened to drop the Syslog-MIB proposal from the
charter. 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. So, keep the comments coming.
  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
  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.

---

From: "David Harrington" <[email-masked]>
Date: Sun, 26 Jul 2009 08:29:40 +0200

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-masked]
[email-masked]
[email-masked]

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Glenn M. Keeni
> Sent: Sunday, July 26, 2009 2:59 AM
> To: syslog

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.

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

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

> 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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Jul 2009 08:50:41 +0200

On Sun, Jul 26, 2009 at 01:06:15AM +0200, Chris Lonvick (clonvick) wrote:
 
> We need to hear from others.  IIRC, the concepts were getting a bit
> difficult to follow and not everyone was nodding their heads
> together on this.
> 
> All: please respond with your comments on this.  The default is to
> exclude items from the charter unless we feel that there is a strong
> commitment to advance a document.

My problem with this document has been that was overly ambitious and
at the same time too simplistic. For example, the goal seems to be to
model sender, receiver, and relays in the same way (the ambitious part
- and earlier versions also include much more configuration objects)
which at the same time a syslog server is restricted to exactly one
transport protocol and one binding address.

I would be OK with this MIB work if the MIB module can be reduced to
essentially a monitoring MIB (no read-create control table). I also do
not think the insights the MIB currently tries to provide about
relaying is needed.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 26 Jul 2009 10:42:34 +0200

> [mailto:[email-masked]] On Behalf Of David Harrington
> 
> 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.
> 

Re-chartering an existing WG and forming a new WG are two different
cases. For re-chartering at least in the OPS area we prefer that an
existing working group debates and reaches some kind of consensus about
a proposed new charter text and then submits it to the AD's. I do not
know if the same practice is followed by SEC or other areas but I
suspect it might not be that different. New Working Groups follow a
different process, which may start by a bar-BOF, or BOF, new or old
players proposing a charter, implies mandatory IETF review and other. 

Dan

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 27 Jul 2009 00:02:32 +0900

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

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 27 Jul 2009 00:27:26 -0700 (PDT)

Hi,

David and I are trying to be pragmatic about the rechartering effort. 
The slides contain a long list of things that _could_ be done.  However, 
we're not seeing people jump up and state that they are committed to doing 
any of them, with the exception of the dtls document where we have a 
starting point, an author, and reviewers.  We don't want to present a 
proposed charter which might look good, but won't have any commitment 
behind it.

If the dtls work is the only thing that's going to go forward, then it 
makes sense to keep the WG in the security area.

We are hoping that OPS people will drop into the room and take up the 
challenge on some of the items.  :-)  If not, then we'll drop back to 
divining consensus and committment from the mailing list which really 
hasn't had much activity about rechartering.

Regards,
Chris

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 27 Jul 2009 09:30:45 +0200

Chris,

jumping in very late and without having read through the discussion. I just
want to say that I have been totally tied up with a project for the past two
and a half month and I am off to summer vacation soon. I'll try to read
through the doc and provide some feedback from my POV within the next two
days, in the hopes that this may be useful.

Rainer

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Chris Lonvick
> Sent: Monday, July 27, 2009 9:27 AM
> To: Romascanu, Dan (Dan)
> Cc: syslog

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 27 Jul 2009 19:24:07 +0900

Hi,
> Hi,
[Stuff deleted]
> As a MIB Doctor and OPSDIR member and co-chair, I know this statement
Problem with definitions. I should have made it clearer.
My definition of "manageable" is managing the IETF Standard Syslog
protocol using IETF Standard management protocols and IETF standard
MIBs. In that context your statement is wrong.

> Having a standards-track MIB module would
Yes. That last sentence is well said. Thanks.
>> So, keep the comments coming.
[Stuff deleted]

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 27 Jul 2009 19:32:14 +0900

Juergen,
       Thanks. I would be more than happy to reduce the MIB to
essentially a monitoring MIB and focusing on essentially sender
and receiver functions. That is where we started:-)
       The point about multiple transports for syslog servers
is interesting. Lets discuss, if this remains on the charter.

       Glenn