Hi, the last sentence "application can also include an APPNAME SDE [RFCPROT] application." is missing some text from what I proposed. "application can also include an APPNAME SDE in the message identifying itself as the "foobar" application."
You can simplify this: "application can also include an APPNAME Structured Data Element [RFCPROT]." dbh > -----Original Message----- > From: Glenn M. Keeni [mailto:[EMAIL PROTECTED] > Sent: Monday, November 12, 2007 1:41 AM > To: David Harrington > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02 > > David, > Thanks for the text. I have done some minor editorial > changes and word-smithing to fit it into the context. It > reads as follows: > > For interoperability and backwards compatibility reasons, > the mapping specified in this document between a label > which represents a Facility or a Severity, and the value > which represents the corresponding code, is normative. > So the mapping from a label configured by operators in > syslog.conf or equivalent will consistently map to the > same Facility code regardless of implementation, but > the label itself is often semantically meaningless, > because it is impractical to attempt to enumerate all > possible facilities, and the mapping (label and > corresponding value) that is used for an actual facility > is, and has historically been, implementation-dependent. > > For example, the foobar application might log messages > as having come from local7, even though there is no > "local" process on the device, and the operator can > configure syslog.conf to have local7.critical messages > be relayed, even though there might be multiple facilities > using Facility local7. This is typical current practice, > and originators, relays and collectors know how to handle > this situation. For improved accuracy, the foobar > application can also include an APPNAME SDE [RFCPROT] > application. > > Let me know if I have missed something. I will put into > the draft and send it off on 14/11/2007. > > Glenn > > David Harrington wrote: > > Hi, > > > > Please append the following paragraphs to section 2 > "Background", and > > please add these paragraphs to the comment text in the MIB > itself that > > describe "Textual Conventions". A reference should be added in the > > section 2 text for the APPNAME SDE with a pointer to the protocol > > document. > > > > "For interoperability and backwards compatibility reasons, > the values > > and > > labels are normative, so the mapping from a label configured by > > operators > > in syslog.conf or equivalent consistently maps to the same Facility > > number > > regardless of implementation, but the label itself is often > > semantically > > meaningless, because there are not enough numbers to cover all > > possible > > facilities, and the enumeration (label and value) that is > used by an > > actual facility is, and has historically been, > > implementation-dependent. > > > > For example, the foobar application might log messages as > having come > > from > > local7, even though there is no "local" process on the > device, and the > > > > operator can configure syslog.conf to have local7.critical > messages be > > > > relayed, even though there might be multiple facilities > using Facility > > > > local7. This is typical current practice, and originators, > relays and > > > > collectors know how to handle this situation. For improved > accuracy, > > the > > foobar application can also include an APPNAME SDE in the message > > identifying itself as the "foobar" application." > > > > Thanks, > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
