Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text to address ietf last call comments (fwd)

From: Chris Lonvick <[email-masked]>
Date: Sat, 16 Jun 2007 09:49:53 -0700 (PDT)

Hi Folks,

This note from Sam to [email-masked] for those of you who don't subscribe.

Thanks,
Chris

---------- Forwarded message ----------
Date: Fri, 15 Jun 2007 19:48:25 -0400 (EDT)
From: Sam Hartman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 contains new text
      to address ietf last call comments

I'd like to draw the attention of the community to section 3 of
draft-ietf-syslog-protocol-21.txt.  This text contains text and a
clarified model of the various layers in the syslog architecture and
new terminology for the parties.

I believe this is responsive to the ietf last call comments and I
believe the changes have been discussed sufficiently in the WG.

I am not asking for a new last call but I do want to make people aware
of the text.  If people believe a new last call is necessary please
let me know now.  Currently the document is scheduled on the Thursday,
June 21 telechat.

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

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

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Wed, 20 Jun 2007 22:56:25 +0900

Hi,
  My comments follow.

Glenn

+------------------------------------------------------------+

1. Page 4.
   "syslog content" is the management information contained
    in a syslog message.
   a. Are we sure about this "management information"?
      It seems to be a restriction on the scope of the
      information that can be carried in a syslog message.
      I suggest that we drop the term "management". It
      does not add any value but raises several questions.
   b. What is the difference in a "syslog content" and
      "syslog message"
      Do we need a distinction?

2. The "syslog application" layer handles generation,
   interpretation, routing and storage of syslog messages.
    "handles generation" is confusing. Then the
     syslog message will first appear at this layer.
     But it appears before ( on top of) this layer
     More about this in (c)

3. I do not agree with the first layer "content" .
   On page-5 the "functions" of the layers are given, the
   functions of the "content" layer are not given.
   It is not clear what abstraction is intended in a layer.
   But whatever that is - layer-1 (syslog content) and
   layer-2(syslog application) do not belong to the same
   genre. Layer-1 does not belong there.

4. On page-6
   The boxes represent syslog-enabled applications.
   a. Is a syslog-enabled application not a syslog
      application ?
      The boxes in Diagram-2 are labelled "collector" ,
      "originator" which are syslog applications.

[The following comments are not related to recent changes
 in the document. But, they are relevant and will need to be
 addressed some time. ]

5. If, syslog-mib-tc is being published then we probably do
   not need to have the paragraphs other than the first one in
   section 6.2.1

6. 6.2.5 APP-NAME
   The APP-NAME field SHOULD identify the device or application
   that originated the message.

   We need to explain "device" or drop the term. Is a host a
   device?

+----------------------------------------------------------+

---

From: "tom.petch" <[email-masked]>
Date: Fri, 22 Jun 2007 11:53:15 +0200

Glenn

I think that the existing, already agreeed text in protocol-21 does give us a
three way split in the stack.   Looking at the ABNF, there is MSG which is
prepended by additional fields to form SYSLOG-MSG which will in turn be
prepended before the PDU is placed on the wire.  So I can see a top layer
generating and interpreting MSG, a middle layer turning that into SYSLOG-MSG and
a lower layer providing the UDP/TLS/etc headers/trailers.

In turn, this can drive statistics and error counters, so that a single MSG
which is sent with two different facility codes each over three transports would
count  as 1 in the upper layer, 2 in the middle and 6 in the lower.  Or an
invalid facility would increment an error counter in the middle layer.

I am not saying this is the only split or the best split and I am certainly not
saying any implementation has to make any of this layering apparent in its code
structure; but I do think that a three-way split is sensible.

But, as I have said before, I also see an inconsistency in the definitions added
to protocol-21, one that I would like to see resolved..

Tom Petch

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: "Chris Lonvick" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, June 20, 2007 3:56 PM
Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew
text to address ietf last call comments (fwd)

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sat, 23 Jun 2007 09:44:54 +0900

Tom,
   I do understand the line of reasoning. But I do not agree with the
conclusion. I agree that if we follow the ABNF we can have layers.
[It does not limit us to three layers]. But a reality check says that
we can have at most 2 significant layers. Significant from the point
of view of operations and management. Facilities will just generate
SYSLOG-MSG.
   Given that we have three layers it will be useful to have a reality
check by mapping these layers to entities that we have defined or know
about. I am afraid we keep going round in loops  because of the lack of
precise definitions. Without these definitions it is very difficult
to tell who is going wrong where. The terms and entities we know
understand in this context are "Facility" , "Transport". Who generates
the MSG? Is that a new entity that we are defining? What real world
entity does it map to ? Why are we interested in its operations ?
The answer to the last question will determine the significance of the
entity and the corresponding "layer".
   I am sorry if the above sounds like a digression, but I have a real
problem in mapping onto reality without answers to the above.
> structure; but I do think that a three-way split is sensible.
I will not argue. But, I will repeat, who sends the MSG, to whom ?
Facilty to X ? X to Facility ? Facility to Facility ? If it one of the
first two cases then, what is "X" ?
> to protocol-21, one that I would like to see resolved..
I fully agree.

Glenn

---

From: "Rainer Gerhards" <[email-masked]>
Date: Sat, 23 Jun 2007 11:52:43 +0200

Glenn,

> -----Original Message-----
> From: Glenn M. Keeni [mailto:[email-masked]]
> Sent: Saturday, June 23, 2007 2:45 AM
> To: tom.petch
> Cc: [email-masked]
> Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3
> containsnewtext to address ietf last call comments (fwd)
> 
> Tom,

Facilities do not generate anything. A facility is a number in the range
0..23 - that's it. Originators generate messages.

> the MSG?

An originator.

>Is that a new entity that we are defining? 

No

>What real world entity does it map to ? 

Syslogd

>Why are we interested in its operations ?
To detect problems and get performance stats (from a mib perspective).

> problem in mapping onto reality without answers to the above.

Please note that there are actually more than three layers in the real
world. See

http://www.rsyslog.com/module-Static_Docs-view-f-/generic_design.html.ph
tml

The text in this link was offered for inclusion in the draft, but it was
objected as being not network-centric enough. As a result, -protcol-20
defined the 3 layers that we actually have from a network point of view:

http://tools.ietf.org/id/draft-ietf-syslog-protocol-20.txt

That was rejected as being to complex. So -21 went back to 2 layers and
consequently needed to use very vague terms. The problem simply is that
you cannot put the complexity of real-world syslog (and its POSIX API)
into a two-layer network view. If you are forced to, you need to remove
many subtleties. To use the terms from my precise architecture
description:

An -protocol-21 originator is a combination of

a) PLOrig
b) remote PLOrig
c) PLGenerator
d) PLGExt
e) Message Router

A relay is a combination of

a) GWI
b) GWO
c) RelayEng
d) RelayEngExt
e) Message Router

A collector is a combination of

a) Store, Disc, ...
b) CollectorEng
c) CollectorEngExt
d) Message Router

As you can see, they have much in common. But you cannot precisely
define them if you are not permitted to define them precisely - aka "you
get what you pay for" ;) 

> first two cases then, what is "X" ?

Using Facility here is just plainly wrong.

And what do you mean by "send" - this was a lengthy discussion.
-protocol was forced to use "send" only for the technical term of
putting messages on the wire. If so, than transport senders send to
transport receivers.

If you use "send" in a more logical, upper-layer view (which is
prohibited for -protocol by WG consensus), then originators ultimately
send to collectors. That's it.

In precise real world terms: PLGenerators send to Collector Engines.

And, yes, we are going in loops. It doesn't help that the WG always
forgets what it requested the other day. Whatever definition you like -
I am pretty sure, you'll find something in the 22 revisions of
-protocol.

I am tired of moving text from one revision into the new one, just to
remove it the next time.

Folks, lets get serious and remember what you have decided over the past
5 years. A little bit of consistency would definitely help. At least it
would be helpful the know if the spec should be precise or vague, be
focused on the network part only or talk about things that affect
application design, put primary effort on backwards compatibility and so
on. I personally have to admit that I consider the syslog
standardization effort to have failed. Most probably, we should conclude
the WG and discard work done. Better than throwing more and more work
into the waste bin. I'd have stopped working on this 3 years ago when I
first thought so...

Rainer
> >>> Subject: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3
> contains
> >>> new text

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Sun, 24 Jun 2007 08:21:23 +0900

Rainer,
> 0..23 - that's it. Originators generate messages.
No. Facility is not a number. Perhaps the number or value that you are
referring to is an encoding of the facility.  rfc3164 and later
draft-ietf-syslog-protocol-21.txt Table 1. gives the mapping between
the numerical codes and corresponding "Facility" :-)
But let us not split hairs.

>> understand in this context are "Facility" , "Transport". Who generates
But the MSG ( or "content") is already present before the originator
(syslog application). This is wrong. It just does not fit the layer
mechanism.
>> What real world entity does it map to ?  
Syslogd is a "syslog application" ? Then it is in layer 2. We do
not have a mapping for layer 1 - "content".
> To detect problems and get performance stats (from a mib perspective).
Yeah. It appears that we do not have a specific interest in its
operations. An example of a specific interest in "syslog application"
statistics would be "how many Kernel messages are generated hourly"
or "how many Kernel messages with severity code = 'Error' are
generated hourly".
> Please note that there are actually more than three layers in the real
I will not try to argue about that.  We can have any number of layers.
But whether all of them are significant or not is the question. That is
what we are trying to ascertain.
[STUFF DELETED]
> Using Facility here is just plainly wrong.
Well, if Facility does not generate the message, who generates the
message? I have explained the problem - the "originator" sits below
the "content" or MSG layer. So it cannot be the generator.
> And what do you mean by "send" - this was a lengthy discussion.
If "send" is a problem - replace "send" with "originate". Who originates
MSG ( in this case some entity is originating the message before the
"originator"!) ?
> In precise real world terms: PLGenerators send to Collector Engines.
It does not help much. According to your definitions/descriptions
PLGenerators is part of "originator" in this layered model. That is a
problem.
>>> to protocol-21, one that I would like to see resolved..
I appreciate your efforts. I am sure that we are getting closer.

Glenn
>> containsnew

---

From: "Rainer Gerhards" <[email-masked]>
Date: Sun, 24 Jun 2007 11:02:16 +0200

Glenn,

OK, it looks like we get to the root of the issue: our understanding of
facility is fundamentally different.

You assume that facility is indeed a semantic entity that uniquely
identifies an "originator" (that part of the system, that originally
generates the MSG content).

I do not understand how this can work. Can you please explain to me how
a set of only 24 different values is able to uniquely identify
application classes?

In a practical example, can you please explain me which facilities must
be used by these "originators" (randomly selected):

- http daemon
- dns daemon
- firewalls
- scp daemon
- ssh daemon
- SIP gateways
- network cache servers
- routers
- switches

Thanks,
Rainer

> Sent: Sunday, June 24, 2007 1:21 AM
> To: Rainer Gerhards
> Cc: tom.petch; [email-masked]
> >> about. I am afraid we keep going round in loops  because of the
lack
> > of
> >>> I think that the existing, already agreeed text in protocol-21
does
> >> give us a
> >>> prepended by additional fields to form SYSLOG-MSG which will in
> turn
> >> be
> >>> prepended before the PDU is placed on the wire.  So I can see a
top
> >> layer
> >>> count  as 1 in the upper layer, 2 in the middle and 6 in the
lower.
> >> Or an
> >>> saying any implementation has to make any of this layering
apparent
> >> in its code
> > forgets what it requested the other day. Whatever definition you
like
> -
> > application design, put primary effort on backwards compatibility
and
> so
> > into the waste bin. I'd have stopped working on this 3 years ago
when
> I

---

From: "tom.petch" <[email-masked]>
Date: Sun, 24 Jun 2007 12:31:04 +0200

Glenn

I can define two layers in the ABNF (one that generates MSG and one that
generates SYSLOG-MSG) but SYSLOG-MSG is not ready to go on the wire so a third
layer is needed, ie a transport, which is worth a mention in -protocol even if
it is not defined there.  So two layers in the ABNF, two in -protocol, three in
the syslog stack as a whole.  Transport matters - the point of this work it to
provide security and it is the (TLS) transport that gives us that; whether you
see that as part of operations and management is a point of view.

Tom Petch

----- Original Message -----
From: "Glenn M. Keeni" <[email-masked]>
To: "tom.petch" <[email-masked]>
Cc: "Chris Lonvick" <[email-masked]>; <[email-masked]>
Sent: Saturday, June 23, 2007 2:44 AM
Subject: Re: [Syslog] draft-ietf-syslog-protocol-21.txt: section 3 containsnew

containsnew

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Mon, 25 Jun 2007 16:56:41 +0900

Tom,
> it is not defined there.  
I agree.
> So two layers in the ABNF, two in -protocol, three in
I agree that it is a point of view. I do not see the necessity of
the two layers for MSG and SYSLOG-MSG as a part of operations and
management.
The reason being that it will generally be the same entity
("application", "module" call it whatever) that will generate MSG and
SYSLOG-MSG.

Glenn

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 25 Jun 2007 09:59:20 +0200

> ("application", "module" call it whatever) that will generate MSG and

Unix *nix, these are always two different entities. 

Rainer

---

From: "Rainer Gerhards" <[email-masked]>
Date: Mon, 25 Jun 2007 10:06:50 +0200

I have been a bit brief. MSG is passed in via the POSIX API. So the
actual generator of MSG is not syslogd. However, and you are right on
this, from the "on the wire" IETF point of view, both are generated by
the same entity, that being syslogd.

Rainer

> From: Rainer Gerhards [mailto:[email-masked]]
> Sent: Monday, June 25, 2007 9:59 AM
> To: Glenn M. Keeni; [email-masked]
> Subject: RE: [Syslog] draft-ietf-syslog-protocol-21.txt: section
> 3containsnewtext to address ietf last call comments (fwd)
>

---

From: "Glenn M. Keeni" <[email-masked]>
Date: Tue, 26 Jun 2007 16:23:12 +0900

> the same entity, that being syslogd.
I would like to add that syslogd is one example only.
The generator could be a mail application, the authentication
module of any application or, any application that anyone
chooses to write  with the the syslog logging mechanism. It can
also be a piece of hardware that is wired to send a certain
"syslog message" under some circumstances. On the wire it is a
syslog message! There isn't much more to it.
So we do have a wide variety of "originators" on hand to fit
into the "layered model". That calls for a simple model :-)

Glenn