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

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

> -----Original Message-----
> From: Anton Okmianski [mailto:aokmians@cisco.com] 
> 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: 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