[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> I fully agree to your comments on standardization and what a
> standard should be. The *real problem* is that I do not see
> any of these things to be used in majority. They are all
> equally often (of seldom) used. I don't see any one of the
> current uses that is worth requiring it. I don't see any
> generally useful information (maybe the MSGID). This is why I
> like the idea of removing them.
I beg to differ. I see process name, process id or both (in syntax
name[id]) used in syslog messages all the time. And for good reason.
This maps cleanly to APP-NAME and PROCID.
I only suggested that in cases when you have an app suite, it may make
sense to allow APP-NAME to refer to app suite and PROCID to process
name.
Message IDs are used by (at a minimum) Solaris syslog and Cisco
devices, although they use them differently.
I agree with David, we don't need just a bucket transport mechanism.
There is XML, ASN.1, etc for this already. We need standard defined
semantics for information we are allowing to be communicated.
Anton.
>
>
> Anyhow, I am open to all suggestions on *what exactly* should
> be standardized. Based on this and past discussions and my
> experience with syslog (both on the sender and
> receiver/analysis side),I have to admit I have no clue at all
> which fields we should specify. For each, you can argue that
> it is either not specific enough or not worth standardizing
> (because it is to specialised).
>
> So I leave it to the WG to suggest some fields and semantics.
> I am simply out of ideas. Text suggestions are highly welcome.
>
> Rainer
>
> > -----Original Message-----
> > From: David B Harrington [mailto:ietfdbh@comcast.net]
> > Sent: Thursday, April 21, 2005 8:02 PM
> > To: Rainer Gerhards; 'syslog'
> > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> >
> > Hi Rainer,
> >
> > The problem is that you're trying to make the "standard"
> accommodate
> > all possible variations of current usage.
> >
> > Standards are not about defining something so generically and
> > ambiguously that every vendor can claim compliance to the
standard.
> > Standards should be about forcing agreement on a format that
> > subsequent standard-compliant implementations would use so the
> > information was actually useful; any vendor that chose to
> not follow
> > the standard simply doesn't get to market their product as being
> > standard-complaint.
> >
> > To put this in a slightly different way, we should be
> focusing on what
> > is most beneficial to the consumers of the information, not what
is
> > easiest for the vendors.
> >
> > If we don't narrow the design choices to support, say, the
> 90% of the
> > 90/10 rule, then we end up with something that is so
> ambiguous as be
> > largely useless.
> >
> > It is the vendors' responsibility to "port" their
> information to the
> > standard format, not the standards committee's responsibility to
> > "port" the standard to each vendor-specific format. We should
> > certainly try to choose a standard format that will be easy
> for most
> > vendors to "port" to, but we should not be trying to define
> something
> > so generic it requires no porting (and ends up being pretty
> useless).
> >
> > David Harrington
> > dbharrington@comcast.net
> >
> > > -----Original Message-----
> > > From: syslog-sec-bounces@www.employees.org
> > > [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of
Rainer
> > > Gerhards
> > > Sent: Thursday, April 21, 2005 12:28 PM
> > > To: syslog
> > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> > >
> > > Hi David & all,
> > >
> > > what I currently see in TAG (RFC 3164, the "source" for
APP-NAME,
> > > PROCID and MSGID) is
> > >
> > > - image name
> > > - OS process ID
> > > - operator-assigned ID
> > > - vendor-assigned application name
> > > - vendor-assigned app name tree
> > > - transactions IDs (smtp, database, ...)
> > > - message IDs
> > > - reboot IDs
> > > - severity values (only combined with one of the above)
> > > - any combination of the above
> > >
> > > ... and this is just what immediately comes to my mind.
> > >
> > > If we really want to provide strong syntax and semantics, we
must
> > > define different fields for all of them - musn't we? Even
> then, we
> > > have the issue that a Postfix SMTP transaction ID might
> be totally
> > > different from an Exchange SMTP transaction ID. What I am
> trying to
> > > convey is that
> > I
> > > think it is beyond the scope of syslog to well-define
identifiers
> > for
> > > each potential vendor usage.
> > >
> > > Observed, existing syslog actually solves this issue by using a
> > single
> > > field - TAG - that will include whatever the vendor/operator
> > > decides. It still is useful, because it allows filtering
> on it. But
> > > it is far
> > from
> > > being well-defined.
> > >
> > > I may be totally wrong here, but I have to admit that I have
> > > *absolutely no idea* how we could get these things into a
> few header
> > > fields AND then well-define them. If somebody knows how
> to do that,
> > > I would deeply appreciate any text suggestion.
> > >
> > > Rainer
> > >
> > > > -----Original Message-----
> > > > From: David B Harrington [mailto:ietfdbh@comcast.net]
> > > > Sent: Thursday, April 21, 2005 6:12 PM
> > > > To: Rainer Gerhards; 'Anton Okmianski'; 'syslog'
> > > > Subject: RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
> > > >
> > > >
> > > >
> > > > > 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.
> > > >
> > > > 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
> > > > dbharrington@comcast.net
> > > >
> > > >
> > > >
> > > >
> > > _______________________________________________
> > > 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
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec