Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on draft-ietf-syslog-protocol-20

From: "tom.petch" <[email-masked]>
Date: Fri, 1 Jun 2007 12:19:12 +0200

Chris

I am fine with the layer diagram given below but I am less clear about the
consequences for the MIB.

Currently, there is a table with an arbitrary integer index which contains
application name, application control file name, receive address and statistics.
I have never been too clear on what an entry in this table represents, as I have
queried before.

The details below suggest that messages sent and received at the transport level
become scalars (digression: need to be clear what a message is when this is TLS
over TCP) with a table with an entry per relay destination (per application?).

Doubt one: we currently do not have any destination information in the table,
only a receive address to bind to; will this be added?

Doubt two; should we be - we should be! - providing a similar table for
originators since they too can send to multiple destinations.

Doubt three; should we have a table for different origins, else balancing
counters will be difficult?  If a collector receives 30 messages when the
various relay and originator not relayed counters add up to 25, how do you know
which stream has gone missing?  or do you parse the message and expect there to
be helpful data in the SDE?

This is all getting complicated and I am unclear about the benefits of going
down this road.

Tom Petch

----- Original Message -----
From: "Chris Lonvick" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "David Harrington" <[email-masked]>; "'Sam Hartman'"
<[email-masked]>; "syslog" <[email-masked]>
Sent: Tuesday, May 22, 2007 7:22 PM
Subject: Layer diagram & mib counters - was:Re: [Syslog] Comments on
draft-ietf-syslog-protocol-20

> Hi All,
>
> What I'm seeing is that our effort to add granularity for mib accounting
> has made the document less clear.  My apologies for that.
>
> Does the following make more sense:
>
>    +---------------------+    +---------------------+
>    |  content            |    |  content            |
>    |---------------------|    |---------------------|
>    |  syslog application |    |  syslog application | (originator,
>    |                     |    |                     |  collector, relay)
>    |---------------------|    |---------------------|
>    |  syslog transport   |    |  syslog transport   | (transport sender,
>    |                     |    |                     | (transport receiver)
>    +---------------------+    +---------------------+
>              ^                          ^
>              |                          |
>               --------------------------
>
>
> In this, the "content" will be developed by some application and handed to
> syslogd (using *nix as an example device).  syslogd will format the
> message adding in the PRI, timestamp, etc., and will hand it to the
> transport.
> - For udp transport, the "transport sender" will encapsulte it within udp
>    and put it onto the wire.
> - For the case of tls, the "transport sender" will establish a new, or use
>    an existing session with the "transport receiver".
>
> For discrepancies (if any) between the IP address of the "originator" and
> the "transport sender", the originator can use the [origin ip=...] SDE
> (Section 7.2).
>
>
> If this makes sense, then the mib counters can be:
> - the number of messages sent and received by the "syslog application"
>    (syslogd)
> - the number of messages sent and received by the "transport sender" and
>    "transport receiver".
> The tricky part here is that the counters of the "transport sender" and
> "transport receiver" are not going to be useful to counting messages that
> are relayed.  Only the counters of the "syslog application" are going to
> be useful for that.  To deal with that, I'll propose that that a table be
> set up to associate the messages sent to each relay destination.
>
> As an example from syslog.conf:
>
>                 kern.crit                    @loghost
>                 kern.info                    @loghost2.example.com
>
> The relay destinations will have to be enumerated.
>     get "numOfRelayDests" would return "2"
>     get "relayDest(1)" would return "loghost"
>     get "relayDest(2)" would return "loghost2.example.com"
>
> What is to be sent to those destinations would have to be quantified.
>     get "priOfRelayDest(1)" would return "2" (from kern.crit as the filter)
>     get "priOfRelayDest(2)" would return "6" (or "kern.info")
>
> When the device receives a "<2>..." syslog message (PRI=2, kern.crit), it
> will relay it to the two relay destinations.
> Then
>     syslogOperationsMsgsReceived will be incremented by 1
>     syslogOperationsMsgsRelayed(0) will be incremented by 2
>        (the message went to two destinations)
>     syslogOperationsMsgsRelayed(1) will be incremented by 1
>        (it sent one copy to "relayDest(1)" which is loghost)
>     syslogOperationsMsgsRelayed(2) will be incremented by 1
>        (it sent another to ""relayDest(2)")
>     syslogOperationsMsgsTransmitted will be incremented by 2
>        (it transmitted both)
>
> Also, on loghost, syslogOperationsMsgsReceived will be incremented by 1
> and on loghost2.example.com syslogOperationsMsgsReceived will also be
> incremented by 1.
>
> This gives an administrator a way to balance out messages sent and
> received.
> - If our device shows 3 messages relayed to loghost, and loghost shows 3
>    messages received, then we have a balance, even if MsgsTransmitted from
>    our device is 482.
> - If our device shows 3 messages relayed but loghost shows 2 messages
>    received, then we might have a discard on our device, or the message may
>    have been dropped by some intermediary.
> - If our device shows 3 messages relayed but loghost shows 46 receieved
>    then we likely have another device sending messages to loghost.
>
> To be clear on this, the counters for "transport sender" and "transport
> receiver" will NOT be associated with a peer - they will just count the
> number of messages sent and received.  It will be up to the counters
> associated with the "syslog application" to associate the messages with
> peers so that the count of messages relayed will have some meaning.
>
> Does this make sense?  As David said, we're not doing our job unless we're
> clear on the concepts, terminology and have a way to manage the devices.
>
> Thanks,
> Chris
>
>
>
> On Fri, 18 May 2007, tom.petch wrote:
>
> > Not sure where this draft is heading, but as a WG member, comments <inline>
> >
> > Tom Petch
> ---remainder elided for brevity---

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

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 1 Jun 2007 06:17:12 -0700 (PDT)

Hi Tom,

I appreciate the thoughts.

I see consensus in the WG on the layering diagram.  I've asked Rainer to 
update -protocol with that diagram and definitions.  Let's get that out 
the door at this time.

I see that we are unclear on what we should be counting and the benefit of 
counting it.  Glenn has separated the mib into textual conventions and the 
counters.  The TC is now here:
   http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt
Would everyone please review this?  I would like for us to establish this 
as our base and then we can have discussions on counting messages.

Thanks,
Chris

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 1 Jun 2007 16:38:23 +0200

I have reviewed this draft and have only one real concern: the facility
names (e.g. kernel, mail) are somewhat *nix-specific. So far, we avoided
making them normative. With only a few facilities available, IMHO, we
should not dedicate two thrids of them to some historic function.

Rainer

> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]]
> Sent: Friday, June 01, 2007 3:17 PM
> To: tom.petch
> Cc: 'Sam Hartman'; syslog
> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments
> ondraft-ietf-syslog-protocol-20
> 
> Hi Tom,
> 
> I see that we are unclear on what we should be counting and the
benefit
> of
> > counters will be difficult?  If a collector receives 30 messages
when
> the
> >>    |                     |    |                     |  collector,
> relay)
> >> - the number of messages sent and received by the "transport
sender"
> and
> >> "transport receiver" are not going to be useful to counting
messages
> that
> >> Does this make sense?  As David said, we're not doing our job
unless
> we're

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 Jun 2007 14:46:10 -0400

Hi,

[speaking as co-chair]

I would like to recommend that the WG ask the OPS ADs for a MIB Doctor
to work as a Technical Advisor to the WG. I think a MIB Advisor can
help guide the WG about designing the MIB.

Obviously I am a MIB Doctor, but it makes it difficult to keep the
functions separate when I work as contributor, as co-chair and as MIB
Advisor. I would like to have an independent MIB Advisor providing
guidance on the MIB design.

David Harrington
co-chair, syslog wg 

> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, June 01, 2007 6:19 AM
> To: Chris Lonvick
> Cc: David Harrington; 'Sam Hartman'; syslog
> Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] 
> Comments on draft-ietf-syslog-protocol-20
> 
> Chris
> 
> >    |                     |    |                     |  
> collector, relay)
> messages that

---

From: "David Harrington" <[email-masked]>
Date: Fri, 1 Jun 2007 15:06:46 -0400

Hi,

[speaking as co-chair]

We asked Glenn to split the two textual conventions into a seperate
document because other working groups are developing MIB modules that
reference syslog facility and severity textual conventions, and we
don't want our complete syslog MIB discussions to hold up their work.
Chris and I felt that there was consensus on the non-normative values
defined in the facility and severity textual conventions.

If this WG decides to debate these values, then I will recommend that
other working groups simply define their own textual conventions for
these values. I consider that sub-optimal, but no other WG should be
held up by the syslog WG, which has a horrible track record for
reaching consensus on anything.

I would like to do a poll:

1) Should these textual conventions be accepted as they are?

2) Would this WG like to see us define a normative set or a
non-normative set of facilities and severities?

3) Whether normative or non-normative, which is more important?
efficient allocation of the limited facility values, or backwards
compatibility with existing (and historic) implementations?

Thanks

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, syslog wg

> From: Rainer Gerhards [mailto:[email-masked]] 
> Sent: Friday, June 01, 2007 10:38 AM
> To: Chris Lonvick
> Cc: syslog
> Subject: [Syslog] 
> > I see consensus in the WG on the layering diagram.  I've 
> asked Rainer
> > to
> > update -protocol with that diagram and definitions.  Let's get
that
> out
> > counting it.  Glenn has separated the mib into textual 
> conventions and
> > the
> > Would everyone please review this?  I would like for us to
establish
> > this
> > > Currently, there is a table with an arbitrary integer index
which
> > contains
> > > application name, application control file name, receive 
> address and
> > statistics.
> > > become scalars (digression: need to be clear what a 
> message is when
> > this is TLS
> > > Doubt one: we currently do not have any destination information
in
> > the table,
> > > Doubt two; should we be - we should be! - providing a 
> similar table
> > for
> > > various relay and originator not relayed counters add up 
> to 25, how
> > do you know
> > > This is all getting complicated and I am unclear about 
> the benefits
> > of going
> > > down this road.
> > >
> > > Tom Petch
> > >
collector,
> > >>    |  syslog transport   |    |  syslog transport   |
(transport
> > sender,
(transport
> > receiver)
> > >> In this, the "content" will be developed by some application
and
> > handed to
> > >> - For the case of tls, the "transport sender" will 
> establish a new,
> > or use
> > >> the "transport sender", the originator can use the 
> [origin ip=...]
> > SDE
> > >> (Section 7.2).
> > >>
> > >>
> > >> The tricky part here is that the counters of the 
> "transport sender"
> > and
> > >> be useful for that.  To deal with that, I'll propose that that
a
> > table be
> > >>     get "priOfRelayDest(1)" would return "2" (from 
> kern.crit as the
> > filter)
> > >> Also, on loghost, syslogOperationsMsgsReceived will be 
> incremented
> > by 1
> > >> and on loghost2.example.com syslogOperationsMsgsReceived 
> will also
> > be
> > >> incremented by 1.
> > >>
> > >> - If our device shows 3 messages relayed to loghost, and
loghost
> > shows 3
> > >> receiver" will NOT be associated with a peer - they will 
> just count
> > the
> > >> associated with the "syslog application" to associate 
> the messages
> > with
> > >>> Not sure where this draft is heading, but as a WG 
> member, comments
> > <inline>
> > >>>
> > >>> Tom Petch

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Jun 2007 22:28:42 +0200

> 1) Should these textual conventions be accepted as they are?

I am fine with the *nix biased values since this is where syslog is
coming from and extremely widely deployed. However, I have no clue
what noMap(99) is nor do I understand any of the words after the first
sentence in the DESCRIPTION clause of SyslogFacility.
 
> non-normative set of facilities and severities?

Are you opening up section 6.2.1 of <draft-ietf-syslog-protocol-20.txt>?
Why not use the same "creative wordings" for this ID also in the MIB?
This makes things consistent (and perhaps leads to a de-facto standard).
Or is the proposal to make the TC document purely Informational?

> compatibility with existing (and historic) implementations?

I assume compatibility; otherwise the protocol design could have used
a very different format and enlarged the number spaces.

/js

PS: I am a long time Unix user and somewhat biased. ;-)

-- 
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: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 02 Jun 2007 08:51:07 +0900

Hi,
> sentence in the DESCRIPTION clause of SyslogFacility.
Oops. That is a legacy of the parent MIB document where it was possible
to set the defaultSyslogFacility. This is irrelevant in the present
document and will be removed.
The description will read
    DESCRIPTION
        "This textual convention enumerates the facilities
         that originate syslog messages.
        "
> Or is the proposal to make the TC document purely Informational?
OK. I propose to replace the opening comments by text like
-- The Facilities and Severities of syslog messages are
-- numerically coded with decimal values.
-- Facility and Severity values are not normative but often used.
-- Some of the operating system daemons and processes are traditionally
-- designated by the Facility values given below.
-- Daemons and processes that do not that have an explicitly
-- assigned a Facility may use any of the "local use" facilities
-- or they may use the "user-level" Facility.

I also propose that we delete the reference to section 6.2.1 of
 <draft-ietf-syslog-protocol-20.txt>.
> a very different format and enlarged the number spaces.

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 02 Jun 2007 09:15:07 +0900

> 1) Should these textual conventions be accepted as they are?
Yes.
> non-normative set of facilities and severities?
Non-normative.
> compatibility with existing (and historic) implementations?

Backwards compatibility. This is very important.

Glenn

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 02 Jun 2007 14:11:52 +0900

> I have never been too clear on what an entry in this table represents, as I have
There are two tables. I presume that you are referring to
syslogControlTable. The DESCRIPTION for syslogControlEntry
should answer your question
       DESCRIPTION
           "The configuration parameters pertaining to a syslog
            application.
           "
Let me know which part is unclear, I will try to clarify.
> only a receive address to bind to; will this be added?
The answer is yes.
You may refer to my earlier mail -

   (1) monitoring the relay activity.  We want to have
     - a list of the relays
     - for every relay
         o the priority(ies) of the message that will be relayed to
           this relay
         o the number of messages transmitted to this relay
           (messagesTransmittedToRelay)
     - etc.
> originators since they too can send to multiple destinations.
In the table for relay destinations- we have a destination-priority
pair. Application A1 will relay Priority P1 to destination D1 etc.
I am not clear about what exactly you want in a similar table for
originators. Could you explain that?
> be helpful data in the SDE?

If we ignore the errors we basically have three counters
      syslogOperationsMsgsReceived,
      syslogOperationsMsgsTransmitted, ( this include relayed messages)
      syslogOperationsMsgsRelayed

I am not clear what is meant by "various relay and originator not
relayed counters".
If it means syslogOperationsMsgsTransmitted, there is no problem at all
with
      syslogOperationsMsgsReceived    = 30 and,
      syslogOperationsMsgsTransmitted = 25
If it does not mean syslogOperationsMsgsTransmitted then please tell me
what it means.

      Honestly, I do not see anyway in which the three counters can be
balanced. [Why do we need to balance these ?]

There will be an additional set of destination-wise counters for relayed
messages
      syslogOperationsMsgsTransmittedToRelay
                                    [ messages transmitted to a  relay]

As far as I can tell there is only one generic equation
     SUM (syslogOperationsMsgTransmittedToRelay) =
                                            syslogOperationsMsgsRelayed
There is just one more generic relationship
     syslogOperationsMsgsTransmitted  >=    syslogOperationsMsgsRelayed

> This is all getting complicated and I am unclear about the benefits of going

I do not believe that it is complicated. It is as simple as that -
there are just two operations "receive" and "send". And "send" has two
sub-types- relay, non-relay. It cannot be complicated :-)

Glenn

---

From: "Rohit M (rrohit)" <[email-masked]>
Date: Sun, 3 Jun 2007 07:25:34 +0530

Hi Chris, 

   Do we really two separate Drafts/RFCs to define Syslog MIB.
   The TC MIB can part of the same Syslog Draft/RFC; both of the MIBs
   TC and Syslog MIB can be defined in the same Draft ?

   Thanks
   Rohit 

-----Original Message-----
From: Chris Lonvick (clonvick) 
Sent: Friday, June 01, 2007 6:47 PM
To: tom.petch
Cc: 'Sam Hartman'; syslog
Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments

Hi Tom,

I see that we are unclear on what we should be counting and the benefit
of counting it.  Glenn has separated the mib into textual conventions
and the counters.  The TC is now here:
   http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt
Would everyone please review this?  I would like for us to establish
this as our base and then we can have discussions on counting messages.

Thanks,
Chris

On Fri, 1 Jun 2007, tom.petch wrote:

> Chris
>
> I am fine with the layer diagram given below but I am less clear about

> the consequences for the MIB.
>
> Currently, there is a table with an arbitrary integer index which 
> contains application name, application control file name, receive
address and statistics.
> I have never been too clear on what an entry in this table represents,

> as I have queried before.
>
> The details below suggest that messages sent and received at the 
> transport level become scalars (digression: need to be clear what a 
> message is when this is TLS over TCP) with a table with an entry per
relay destination (per application?).
>
> Doubt one: we currently do not have any destination information in the

> table, only a receive address to bind to; will this be added?
>
> Doubt two; should we be - we should be! - providing a similar table 
> for originators since they too can send to multiple destinations.
>
> Doubt three; should we have a table for different origins, else 
> balancing counters will be difficult?  If a collector receives 30 
> messages when the various relay and originator not relayed counters 
> add up to 25, how do you know which stream has gone missing?  or do 
> you parse the message and expect there to be helpful data in the SDE?
>
> This is all getting complicated and I am unclear about the benefits of

> going down this road.
>> What I'm seeing is that our effort to add granularity for mib 
>> accounting has made the document less clear.  My apologies for that.
>>
relay)
>> In this, the "content" will be developed by some application and 
>> handed to syslogd (using *nix as an example device).  syslogd will 
>> format the message adding in the PRI, timestamp, etc., and will hand 
>> it to the transport.
>> For discrepancies (if any) between the IP address of the "originator"

>> and the "transport sender", the originator can use the [origin 
>> ip=...] SDE (Section 7.2).
>>
>>
>> The tricky part here is that the counters of the "transport sender" 
>> and "transport receiver" are not going to be useful to counting 
>> messages that are relayed.  Only the counters of the "syslog 
>> application" are going to be useful for that.  To deal with that, 
>> I'll propose that that a table be set up to associate the messages
sent to each relay destination.
>> When the device receives a "<2>..." syslog message (PRI=2, 
>> kern.crit), it will relay it to the two relay destinations.
>> Then
>> Also, on loghost, syslogOperationsMsgsReceived will be incremented by

>> 1 and on loghost2.example.com syslogOperationsMsgsReceived will also 
>> be incremented by 1.
>>
>> To be clear on this, the counters for "transport sender" and 
>> "transport receiver" will NOT be associated with a peer - they will 
>> just count the number of messages sent and received.  It will be up 
>> to the counters associated with the "syslog application" to associate

>> the messages with peers so that the count of messages relayed will
have some meaning.
>>
>> Does this make sense?  As David said, we're not doing our job unless 
>> we're clear on the concepts, terminology and have a way to manage the
devices.

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 04 Jun 2007 18:32:17 +0900

Hi,
  There has been concern that we are unclear about what we are counting
and the benefits of counting it. The following text should clarify what
we are counting. Once we are clear about the objects we can have a
meaningful discussion on the benefits.

   Glenn

             Syslog Message counters in the SyslogMIB
             ========================================

   The following is the simple syslog operational model for message
   receive, send and relay. The relationship among the counters will
   relate to this model. 

   A syslog application does one or more of the folowing:
     - receives syslog messages
     - transmits syslog messages some of which are relay messages 
       [ a received syslog message may be forwarded to one or more 
         relay destinations depending on the message priority value] 

                     +<===Syslog Appn==>+              
                     |                  |              
                     |      +-----------|-> Originated Messages
                     |      |           |
                     |      V           |
                     |   Originated     |                        
                     |   Messages    +--|-> MessagesToRelayDestn1
            Received |               |  |
            -------->|- --+----------+--|-> MessagesToRelayDestn2
            Messages |    |          |  |
                     |    |          +--|-> MessagesToRelayDestn3
                     |    |          :  |
                     |    |          +--|-> MessagesToRelayDestnN
                     |    |          |  |
                     |    V          V  |
            Incoming | Consumed  Relayed|   Outgoing   
            Messages | Messages    Msgs |   Messages
                     |                  |
                     +------------------+

       syslogOperationsMsgsReceived    = Received Messages

       syslogOperationsMsgsRelayed     = MessagesToRelayDestn1 + 
                                         :
                                         MessagesToRelayDestnN  

       syslogOperationsMsgsTransmitted = OriginatedMessages    +
                                         MessagesToRelayDestn1 +
                                         :
                                         MessagesToRelayDestnN  

       Note:
         a. there are no counters for 
             Consumed Messages
             Originated Messages
         b. the following set of counters will be available in the 
            next version of the syslogMIB: 
             syslogRelayMessagesToDestn.1 = MessagesToRelayDestn1
             syslogRelayMessagesToDestn.2 = MessagesToRelayDestn2
             :
             syslogRelayMessagesToDestn.N = MessagesToRelayDestnN
_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "David Harrington" <[email-masked]>
Date: Mon, 4 Jun 2007 07:11:26 -0400

Hi,

There are other WGs that are developing MIB modules that refer to
syslog facility and severity textual conventions. By separating the
facility and severity TCs from the rest of the syslog MIB, we reduce
the dependency problem, by allowing the TC draft to advance
independent of the rest of the syslog MIB document.

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> From: Rohit M (rrohit) [mailto:[email-masked]] 
> Sent: Saturday, June 02, 2007 9:56 PM
> To: Chris Lonvick (clonvick); tom.petch
> Cc: syslog; Sam Hartman
> Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] 
> Commentsondraft-ietf-syslog-protocol-20
> 
> Hi Chris, 
> 
Comments
> asked Rainer to
> >> - For udp transport, the "transport sender" will 
> encapsulte it within
> udp
> >> - For the case of tls, the "transport sender" will establish a
new,
> >> - the number of messages sent and received by the 
> "transport sender"
> and
> >>    "transport receiver".

> >>     get "priOfRelayDest(1)" would return "2" (from kern.crit as
the
> incremented by
> >>    messages received, then we have a balance, even if 
> MsgsTransmitted
> from
> >>    our device is 482.
> >>> Not sure where this draft is heading, but as a WG member, 
> comments 
> >>> <inline>
> >>>
> >>> Tom Petch

---

From: "Rohit M (rrohit)" <[email-masked]>
Date: Mon, 4 Jun 2007 16:43:09 +0530

In that case, going forward we will have two drafts for every MIB as it
looks like.
Which other MIB is using these TCs ?

Thanks
Rohit 

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Monday, June 04, 2007 4:41 PM
To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch'
Cc: 'syslog'; 'Sam Hartman'
Subject: RE: Layer diagram & mib counters - was:Re: [Syslog]

Hi,

There are other WGs that are developing MIB modules that refer to syslog
facility and severity textual conventions. By separating the facility
and severity TCs from the rest of the syslog MIB, we reduce the
dependency problem, by allowing the TC draft to advance independent of
the rest of the syslog MIB document.

David Harrington
[email-masked]
[email-masked]
[email-masked]
co-chair, Syslog WG 

Comments
new,

the

---

From: "David Harrington" <[email-masked]>
Date: Mon, 4 Jun 2007 09:20:21 -0400

Hi Rohit,

As a MIB Doctor, I may be more aware of this type of practice than
you. So let me discuss some of the issues raised by your email.

1) Having a separate document for textual conventions for a technology
is not uncommon. See RFC 2514, 2856, 3419, 3593, 3595, 3705, 3811,
4001, 4265, and 4801. I won't bother to list the relevant
internet-drafts. So you should question your presumption that having
two documents, one for TCs and another for the related MIB module, is
a bad thing. 

It is often much easier to establish consensus on reusable textual
conventions than on the rest of a MIB module design. One document's
advancement can be delayed by dependencies on other documents, so
allowing other documents to be dependent only on the reusable textual
conventions, rather than on the complete SYSLOG-MIB document should
make it easier to advance dependent MIB modules within the IETF
process.

2) With regard to these specific textual conventions, one thing to be
aware of is the fact that the SYSLOG-MIB actually doesn't use these
textual conventions at all. (They are still defined in mib-15, but
should be absent from mib-16.) So you should question your presumption
that these textual conventions belong in the SYSLOG-MIB; if the
SYSLOG-MIB doesn't use them, then why do they need to be defined in
the SYSLOG-MIB?

3) If the SYSLOG-MIB doesn't use them, then why are we defining them
in this WG? Well, because this WG is composed of syslog experts. The
WG whose MIB module references these TCs is the IPCDN WG, which has a
lot of cable data networking experts, but not necessarily the best
personnel for defining syslog-specific textual conventions.

As a MIB Doctor and co-chair of this WG, I had my own concerns about
doing this work in the syslog WG, if the SYSLOG-MIB did not actually
use these TCs. I consulted the MIB Doctors (including the area
director for OPS), and the consensus was that the syslog WG was the
corrrect place to define the textual conventions, even if we didn't
use them in the SYSLOG-MIB. And I discussed having the separate
document for the TCs with my co-chair and the responsible area
director for the syslog WG, and we agreed that was appropriate.

Hopefully, this gves you some of the background behind the decision to
have this separate document. 

If the WG does not want to adopt this document as a WG draft, Glenn
can always publish it as an individual draft. Persaonally, I think it
makes sense to publish it a syslog WG draft.

David Harrington
[email-masked] 
[email-masked]
[email-masked]
co-chair, Syslog WG 

> Sent: Monday, June 04, 2007 7:13 AM
> To: David Harrington; Chris Lonvick (clonvick); tom.petch
> Cc: syslog; Sam Hartman
establish
which 

> > > transport level become scalars (digression: need to be clear
what
collector,
(transport
(transport
and 

loghost

---

From: "Rohit M (rrohit)" <[email-masked]>
Date: Mon, 4 Jun 2007 19:38:31 +0530

Hi David, 

   Thanks for your detail response.
   Do we know the MIBs which are using these TCs or planning to use
these ?

Thanks
Rohit

-----Original Message-----
From: David Harrington [mailto:[email-masked]] 
Sent: Monday, June 04, 2007 6:50 PM
To: Rohit M (rrohit); Chris Lonvick (clonvick); 'tom.petch'
Cc: 'syslog'; 'Sam Hartman'
Subject: RE: Layer diagram & mib counters - was:Re: [Syslog]

Hi Rohit,

As a MIB Doctor, I may be more aware of this type of practice than you.
So let me discuss some of the issues raised by your email.

1) Having a separate document for textual conventions for a technology
is not uncommon. See RFC 2514, 2856, 3419, 3593, 3595, 3705, 3811, 4001,
4265, and 4801. I won't bother to list the relevant internet-drafts. So
you should question your presumption that having two documents, one for
TCs and another for the related MIB module, is a bad thing. 

It is often much easier to establish consensus on reusable textual
conventions than on the rest of a MIB module design. One document's
advancement can be delayed by dependencies on other documents, so
allowing other documents to be dependent only on the reusable textual
conventions, rather than on the complete SYSLOG-MIB document should make
it easier to advance dependent MIB modules within the IETF process.

SYSLOG-MIB doesn't use them, then why do they need to be defined in the
SYSLOG-MIB?

3) If the SYSLOG-MIB doesn't use them, then why are we defining them in
this WG? Well, because this WG is composed of syslog experts. The WG
whose MIB module references these TCs is the IPCDN WG, which has a lot
of cable data networking experts, but not necessarily the best personnel
for defining syslog-specific textual conventions.

As a MIB Doctor and co-chair of this WG, I had my own concerns about
doing this work in the syslog WG, if the SYSLOG-MIB did not actually use
these TCs. I consulted the MIB Doctors (including the area director for
OPS), and the consensus was that the syslog WG was the corrrect place to
define the textual conventions, even if we didn't use them in the
SYSLOG-MIB. And I discussed having the separate document for the TCs
with my co-chair and the responsible area director for the syslog WG,
and we agreed that was appropriate.

If the WG does not want to adopt this document as a WG draft, Glenn can
always publish it as an individual draft. Persaonally, I think it makes
sense to publish it a syslog WG draft.

David Harrington
[email-masked]
[email-masked]
[email-masked]
co-chair, Syslog WG 

establish
which 

what
collector,
(transport
(transport
and 

loghost

---

From: "tom.petch" <[email-masked]>
Date: Mon, 4 Jun 2007 12:44:30 +0200

inline>
Tom Petch

----- Original Message -----
From: "Rohit M (rrohit)" <[email-masked]>
To: "Chris Lonvick (clonvick)" <[email-masked]>; "tom.petch"
<[email-masked]>
Cc: "Sam Hartman" <[email-masked]>; "syslog" <[email-masked]>
Sent: Sunday, June 03, 2007 3:55 AM
Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments
ondraft-ietf-syslog-protocol-20

Hi Chris,

   Thanks
   Rohit

<tp>
I had precisely this thought but now see David's explanation that there are
other WGs interested in having these TCs in which case, yes, I think it worth
separating them - their future development is likely to diverge.

Tom Petch

---

From: "tom.petch" <[email-masked]>
Date: Mon, 4 Jun 2007 15:24:42 +0200

<inline>
Tom Petch

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Chris Lonvick" <[email-masked]>; "'Sam Hartman'"
<[email-masked]>; "syslog" <[email-masked]>
Sent: Saturday, June 02, 2007 7:11 AM
Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on
draft-ietf-syslog-protocol-20

> Let me know which part is unclear, I will try to clarify.

Since syslogOperationsTable is an SMI augmentation of syslogControlTable, I was
treating them as one table.  And I do not understand what a row in the table
represents; applications to me is the like of SMTP, FTP, Web access.

I see syslog in network devices where arguably there are no 'applications',
SNMP, TFTP, telnet, HTTP and such being there for device management, with syslog
messages relating to happenings at link or network level, or perhaps OS (eg
storage/addressing); or I see syslog in non-**ix servers as a separate
process/daemon.  In either case, it is the process that is configured, not what
I think of as an application; so I don't understand:-(.  (And, in earlier I-Ds,
I got the impression that these applications could be on different boxes with
some protocol transferring the messages to the syslog originator).

> > over TCP) with a table with an entry per relay destination (per
application?).

<snip>

> originators. Could you explain that?

Chris wrote of reconciling counts of messages sent by one syslog stack with
those received by another stack to see if some were lost. I like this idea - and
am assuming that the reconciliation would be done on a 5-tuple of
protocol/portnumbers/IPaddresses basis or something similar - but can only see
it working if we know where an originator is sending messages to.  I think of an
originator as having the capability to send the same message to more than one
place (relay or collector), or to send different messages to different places eg
based on severity, so reconciliation must depend on having a table in the
originator of how many were sent where, must it not?

As I said before, I like the idea of being able to reconcile counts, but fear it
may end up too complex to implement since, to do it properly, you would need to
extract such tables from potentially every syslog stack in the management domain
at the same point in time and then later repeat the process in order to get a
diff between the counters; and then start reconciling.

Tom Petch

<snip>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 4 Jun 2007 11:50:54 -0400

sure. 
draft-ietf-ipcdn-eventmess-xx tries to correlate syslog messages and
SNMP notifications. 

Right now (-09-) ipcdn is using their own enumerations based on
RFC3164. They have been advised (by me, their MIB Doctor) to use TCs
defined by the syslog WG, so there will be consistency across WGs.

dbh 

> Sent: Monday, June 04, 2007 10:09 AM
> > dependency problem, by allowing the TC draft to advance
independent
> > > > message is when this is TLS over TCP) with a table with an
entry
> > per
> > > > add up to 25, how do you know which stream has gone missing?
or
> > do 

> > > >> This gives an administrator a way to balance out messages
sent
> > > >>    received, then we might have a discard on our device, or
the
> > > message may

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 05 Jun 2007 17:41:40 +0900

> treating them as one table.  And I do not understand what a row in the table
There is no problems treating the two tables as one.
> some protocol transferring the messages to the syslog originator).
Right. The syslog-wg has decided to call "it" an "application". [ I did
not think that "application" is the most appropriate term.]
One row in the table represents information about one "application".
> diff between the counters; and then start reconciling.
I will agree with you. Reconciling the counts of multiple applications,
possibly on multiple servers, is complex. I would say it is impractical
if not impossible.

Glenn

---

From: "Rainer Gerhards" <[email-masked]>
Date: Tue, 5 Jun 2007 11:37:45 +0200

> possibly on multiple servers, is complex. I would say it is
impractical

I fully agree - it is (close to) impossible. Most importantly, in
practice admins discard a number of messages. So you can not simply look
at messages send/received - you also need to know which messages need to
be collected and which ones need to be relayed. In short, you need to
pull config information in addition to the pure tables (because the
tables do not reflect internal processing). Then keep in mind, that
probably every vendor has different filtering capabilities and
methods...

I have to admit that I find this whole discussion on consolidating
counts counter-productive. You do not get any useful information out of
it, but for the sake of it everything else gets complicated and delayed.
Over-engineered IMHO....

Rainer

---

From: "tom.petch" <[email-masked]>
Date: Wed, 6 Jun 2007 11:44:34 +0200

David

I see the problem slightly differently.  I think that there is adequate
expertise on this list to turn a data model into suitable SMI and that what is
lacking is the data model for syslog; from the MIB doctor reports I have read,
that is one thing they rarely bring to the party.  Rather they focus on the SMI
and on asking pointed questions about the meaning and representation of objects
in the model.

We have progessed, producing a better defined syslog stack, what I think is
needed now is to take that a stage further -  no SNMP expertise needed - in
defining what management data users would like to know or what implementers are
prepared to offer.  The existing MIB module is obviously an example of this; my
problem with it is in not understanding it as well as I think I need to in order
to use it. And of course the lack of others saying 'it's obvious what it means'
(or not) or
whatever so that a consensus may form.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Chris Lonvick'"
<[email-masked]>
Cc: "'Sam Hartman'" <[email-masked]>; "'syslog'" <[email-masked]>
Sent: Friday, June 01, 2007 8:46 PM
Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments on
draft-ietf-syslog-protocol-20

> > which contains
> > (transport sender,
> > (transport receiver)
> > establish a new, or use
> > > - the number of meFrom [email-masked] Wed Jun 06 06:53:07 2007
From: "tom.petch" <[email-masked]>
To: "David Harrington" <[email-masked]>
Subject: Re: Layer diagram & mib counters - was:Re: [Syslog] Comments on
	draft-ietf-syslog-protocol-20
Date: Wed, 6 Jun 2007 11:44:34 +0200
Cc: syslog <[email-masked]>
Reply-To: "tom.petch" <[email-masked]>

David

I see the problem slightly differently.  I think that there is adequate
expertise on this list to turn a data model into suitable SMI and that what is
lacking is the data model for syslog; from the MIB doctor reports I have read,
that is one thing they rarely bring to the party.  Rather they focus on the SMI
and on asking pointed questions about the meaning and representation of objects
in the model.

We have progessed, producing a better defined syslog stack, what I think is
needed now is to take that a stage further -  no SNMP expertise needed - in
defining what management data users would like to know or what implementers are
prepared to offer.  The existing MIB module is obviously an example of this; my
problem with it is in not understanding it as well as I think I need to in order
to use it. And of course the lack of others saying 'it's obvious what it means'
(or not) or
whatever so that a consensus may form.

Tom Petch

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'tom.petch'" <[email-masked]>; "'Chris Lonvick'"
<[email-masked]>
Cc: "'Sam Hartman'" <[email-masked]>; "'syslog'" <[email-masked]>
Sent: Friday, June 01, 2007 8:46 PM
Subject: RE: Layer diagram & mib counters - was:Re: [Syslog] Comments on
draft-ietf-syslog-protocol-20

> Advisor. I would like to have an independessages sent and received by the "syslog
> > application"
> > >    (syslogd)
> > "transport sender" and
> > kern.crit as the filter)
> > kern.crit), it
> > incremented by 1
> > will also be
> > loghost shows 3
> > MsgsTransmitted from
> > the message may
> > just count the
> > comments <inline>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 6 Jun 2007 11:45:58 +0200

----- Original Message -----
From: "David Harrington" <[email-masked]>
To: "'Rainer Gerhards'" <[email-masked]>; "'Chris Lonvick'"
<[email-masked]>
Cc: "'syslog'" <[email-masked]>
Sent: Friday, June 01, 2007 9:06 PM
Subject: [Syslog] tc-mib poll

<snip>
> 1) Should these textual conventions be accepted as they are?

Yes, fine by me

> non-normative set of facilities and severities?
I do not understand this; normative means that is part of a protocol which must
be adhered for for conformance and I do not see what protocol we are talking of
here

> compatibility with existing (and historic) implementations?
Compatibility - this list has been around and stable for a long time and I see
similar proprietary ones (albeit with an added one or multiplied by eight) going
back further.

Tom Petch

> > > transport level
> > > balancing
> > > accounting
> > > "transport

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 8 Jun 2007 09:21:12 +0200

On Wed, Jun 06, 2007 at 11:45:34AM +0200, tom.petch wrote:
 
> I would suggest putting these enumerations under IANA control, as has
> been done by, eg, disman (RFC3877) and ccamp (RFC4802).
> 
> If we want to add to the list, and having other WGs use them makes
> me think that that will happen, then IANA control makes that much
> simpler.  We can specify what level of review is needed - no need to
> agree a new RFC for every change.

Note that the number space is very limited and that determines whether
extensions are actually possible or not...

/js