[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)?
Yes. And hopefully its content defined with SHOULDs. I think it
should say that this SHOULD be a process name or process ID.
I also don't understand this statement: "the syslogd is restarted, the
PROCID changes". Do you mean when the processing sending requests
restarst, it MAY change the PROCID value (if it is a process id and
not name)?
Thanks,
Anton.
>
> 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
>
_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec