[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Syslog-sec] SENDER-NAME, PROCID, MSGID
Anton,
So this boils down that you are happy with the current draft and just
would like to have PROCID larger (let's say 64 or 128 octets)?
Rainer
> -----Original Message-----
> From: Anton Okmianski [mailto:aokmians@cisco.com]
> Sent: Thursday, April 21, 2005 9:48 PM
> To: Rainer Gerhards; syslog-sec@employees.org
> Subject: 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