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

["Anton Okmianski" <aokmians@cisco.com>]

> > Why is PROCID defined to be just 16 character?
> 
> 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?

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

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.
> 
> Any more comments are appreciated.
> 
> Rainer
> > 
> > Thanks,
> > Anton. 
> > 
> >   
> > 
> > > -----Original Message-----
> > > From: syslog-sec-bounces@willers.employees.org
> > > [mailto:syslog-sec-bounces@willers.employees.org] 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
> > > Syslog-sec@www.employees.org
> > > http://www.employees.org/mailman/listinfo/syslog-sec
> > > 
> > 
> 
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec