headers
tom.petch | 1 Jun 2007 12:19

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

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
(Continue reading)

Permalink | Reply | 22 comments |
headers
Chris Lonvick | 1 Jun 2007 15:17
Picon
Favicon

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

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

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.
>
(Continue reading)

Permalink | Reply | 15 comments |
headers
Rainer Gerhards | 1 Jun 2007 16:38
Gravatar

http://www.ietf.org/internet-drafts/draft-ietf-syslog-tc-mib-00.txt

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:clonvick <at> cisco.com]
> 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 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
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Harrington | 1 Jun 2007 20:46
Picon

RE: Layer diagram & mib counters - was:Re: Comments on draft-ietf-syslog-protocol-20

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 

> -----Original Message-----
> From: tom.petch [mailto:cfinss <at> dial.pipex.com] 
> 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
> 
> I am fine with the layer diagram given below but I am less 
> clear about the
> consequences for the MIB.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Harrington | 1 Jun 2007 21:06
Picon

tc-mib poll

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
(Continue reading)

Permalink | Reply | 6 comments |
headers
Juergen Schoenwaelder | 1 Jun 2007 22:28
Picon
Favicon

Re: tc-mib poll

On Fri, Jun 01, 2007 at 03:06:46PM -0400, David Harrington wrote:

> I would like to do a poll:
> 
> 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.

> 2) Would this WG like to see us define a normative set or a
> 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?

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

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. ;-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Glenn M. Keeni | 2 Jun 2007 01:51
Favicon

Re: tc-mib poll

Hi,
Juergen Schoenwaelder wrote:
> On Fri, Jun 01, 2007 at 03:06:46PM -0400, David Harrington wrote:
>  
>> I would like to do a poll:
>>
>> 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.
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.
        "
>  
>> 2) Would this WG like to see us define a normative set or a
>> 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?
OK. I propose to replace the opening comments by text like
-- The Facilities and Severities of syslog messages are
(Continue reading)

Permalink | Reply | 0 comments |
headers
Glenn M. Keeni | 2 Jun 2007 02:15
Favicon

Re: tc-mib poll


> 
> I would like to do a poll:
> 
> 1) Should these textual conventions be accepted as they are?
Yes.
> 
> 2) Would this WG like to see us define a normative set or a
> non-normative set of facilities and severities?
Non-normative.
> 
> 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?

Backwards compatibility. This is very important.
> 

Glenn

_______________________________________________
Syslog mailing list
Syslog <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog
Permalink | Reply | 0 comments |
headers
Glenn M. Keeni | 2 Jun 2007 07:11
Favicon

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

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.
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.
> 
> 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?
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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Rohit M (rrohit | 3 Jun 2007 03:55
Picon
Favicon

RE: Layer diagram & mib counters - was:Re: Comments ondraft-ietf-syslog-protocol-20

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
ondraft-ietf-syslog-protocol-20

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
(Continue reading)

Permalink | Reply | 6 comments |

Gmane