[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
well... by the definition currently in the draft, "FrameworkService.exe"
as PROCID would be very far streched. The current "spirit" of the draft
would be to have an APP-NAME of "MySuite/FrameworkService.exe" and a
PROCID of 1234.
In any case, your example shows that the fields might actually better be
taken off the header. We could use very long names for everything, but I
think that would actually better make it into STRUCTURED-DATA. My
impression from these discussion is that when you talk to 10 people, you
will probably receive 9 different views of what might be contained in
these fields. If you look at current TAG, you'll also notice that there
are many different things used inside it. If we want to keep it in the
header, we might even think to go back to a single field TAG, with a
size limit of 100 octets that each vendor might use as he likes... Now
we have 3 fields, none of them well-defined, and none of them
well-definable (because we have so different needs). If we semantically
strong define FIELDS for these needs, we'll probably end up with 10 to
15 new fields, most of them will be empty in most messages (but always
diffrent ones). I think this is not desirable.
Rainer
> -----Original Message-----
> From: Anton Okmianski [mailto:aokmians@cisco.com]
> Sent: Thursday, April 21, 2005 5:52 PM
> To: Rainer Gerhards; 'syslog'
> Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
>
> > > 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