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

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

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?

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.  

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. 

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