Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID

From: "Rainer Gerhards" <[email-masked]>
Date: Thu, 21 Apr 2005 17:34:54 +0200

> -----Original Message-----
> From: Anton Okmianski [mailto:[email-masked]] 
> Sent: Thursday, April 21, 2005 5:19 PM
> To: Rainer Gerhards; 'syslog'
> Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> 
> Rainer:
> 
> Well, you could put everything into structured data.  The idea here
> that we make certain fields more readily available because we believe
> (assuming consensus) that they will be most frequently used for
> filtering messages.  So, I think all three should be in the header.
> The MSGID, I think, may be unfamiliar to some people, but it is in
> wide use. For example,  pretty much all Cisco devices use something
> like this. I would take a bold guess that Cisco is not alone in this
> practice.   
> 
> Why is PROCID defined to be just 16 character?

because that should be sufficient and we should try to keep the header
as small as possible (giving the total size of just 480 octets if we
want to unsure the message is not fragmented).

> 
> Is this ok to define a field (PROCID) and not even say what it MUST or
> SHOULD contain?  The section only mentions what it MAY contain.  I can
> see where Dado was coming from when the definition is so tentative.  

Well... we had a very long discussion on this field just the past days.
We had a very hard time to find any text at all. We can of course say
"SHOULD" instead of "MAY", but I am not sure if that will actually
clarify.

> Should we also define structured data elements for process-id and
> process-name? This way if you put one into PROCID, we have a place to
> put the other in the message. 

process-name should be placed in APP-NAME. Remeber, PROCID was renamed
from APP-INST, because we could not find a concensus on what an
"instance" is. So I think we should not mirror these header fields to
structured-data.

Anyhow, I see a valid point in Dado's suggestion: all of these 3 fields
are highly optional and all of them have no strict definition. Maybe
this is not a good thing for well-defined header fields. I don't see any
issue with filtering at the receiver side, even if it is structured
data. Even in the header, these fields may be absent (actually a dash in
them, which means they are not there). So I think it is not an issue to
include them in structured data. The only issue is that when it comes to
truncation, the header will always survive, while STRUCTURED-DATA will
be the first thing to be truncated.

Any more comments are appreciated.

Rainer
> 
> Thanks,
> Anton. 
> 
>   
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf 
> > Of Rainer Gerhards
> > Sent: Thursday, April 21, 2005 10:10 AM
> > To: syslog
> > Subject: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> > 
> > Hi all,
> > 
> > I've received a good idea from Dado Colussi (his comment is 
> > based on the -10 version of syslog-protocol, thus his 
> > reference to SENDER-INST). With his permission, I repost it here:
> > 
> > ###
> > >>I have failed to convince myself that the SENDER-NAME, 
> > SENDER-INST and 
> > >>MSGID are well justified in the HEADER part. According to 
> > the syntax 
> > >>specified in Section 6, all of the fields are required. 
> > However, each 
> > >>field has a near-void semantics. There would be a nice mechanism
> of 
> > >>STRUCTURED-DATA for optional data with whatever semantics.
> > >>
> > >>Is there a clear common benefit of having these fields as a part
> of 
> > >>the HEADER instead of as a part of STRUCTURED-DATA? I think 
> > the HEADER 
> > >>should include fields that have clear semantics and only 
> > fields that 
> > >>MUST be present in each message.
> > ###
> > 
> > Probably this could solve the past discussion we had on 
> > PROCID/SENDER-INST.
> > 
> > Comments appreciated.
> > 
> > Rainer
> > _______________________________________________
> > Syslog-sec mailing list
> > [email-masked]
> > http://www.employees.org/mailman/listinfo/syslog-sec
> > 
> 
_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "Anton Okmianski" <[email-masked]>
Date: Thu, 21 Apr 2005 11:52:16 -0400

> because that should be sufficient and we should try to keep 

If I want to put process name in this field. "FrameworkService.exe"
which exists on my machine does not fit.  

> the header as small as possible (giving the total size of 
> just 480 octets if we want to unsure the message is not fragmented).

What if my message content is always short. Are not you making a bit
of an administrative policy decision here?

> process-name should be placed in APP-NAME. Remeber, PROCID 

Think of applications which have multiple processes or ephemeral
processes.  Let me give you a use-case I have in mind. 

I can see how APP-NAME would be a general application-suite name. This
is how the user may know the application.  Say "Outlook Express" using
windows example.  This does not necessarily mean that this app will
only have one process! I would then identify the specific process in
PROCID by name.  Imagine "outlook-smpt.exe".  I'd think using process
name in PROCID instead of process ID would make sense in many cases
because it is better for categorizing/filtering messages. Process id
is ephemeral if my application spawns processes or just restarts.  I
would then like to also provide the process id somewhere in the
message.  Hence process-id field in structured data.

In other words, you want to go from most abstract to most specific.
Putting process name in APP-NAME and using "software" structure
element to identiy the software suite is backwards, IMO. 

Anton.    

> was renamed from APP-INST, because we could not find a 
> concensus on what an "instance" is. So I think we should not 
> mirror these header fields to structured-data.
> 
> Anyhow, I see a valid point in Dado's suggestion: all of 
> these 3 fields are highly optional and all of them have no 
> strict definition. Maybe this is not a good thing for 
> well-defined header fields. I don't see any issue with 
> filtering at the receiver side, even if it is structured 
> data. Even in the header, these fields may be absent 
> (actually a dash in them, which means they are not there). So 
> I think it is not an issue to include them in structured 
> data. The only issue is that when it comes to truncation, the 
> header will always survive, while STRUCTURED-DATA will be the 
> first thing to be truncated.
> 
> > > [mailto:[email-masked]] On Behalf Of 
> > > Rainer Gerhards
> > > I've received a good idea from Dado Colussi (his comment 
> is based on 
> > > the -10 version of syslog-protocol, thus his reference to 
> > > SENDER-INST). With his permission, I repost it here:
> > > 
> > > ###

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 Apr 2005 12:12:18 -0400

> these 3 fields
> this is not a good thing for well-defined header fields. 

Maybe this is not a good thing for an industry "standard" - Maybe we
should make them not-optional and/or strictly define them. 

>From RFC2026:
"A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has
received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable."

I question whether these field definitions have resolved the known
design choices, are well-understood, and enjoy enough community
interest to be considered valuable.

I think coming to an agreement on the format and semantics, and
specifying it clearly and umambiguously in the documentation, would
enhance the value of these fields. Let's standardize the semantics of
the field, rather than just standardizing a bucket for undefined
information.

David Harrington
[email-masked]