Glenn M. Keeni
Wed, 14 Nov 2007 02:49:39 -0800
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." > OOps. That was a cut and paste error. > You can simplify this: > "application can also include an APPNAME Structured Data Element > [RFCPROT]." This sounds better. I will use this. Thanks. > > dbh
Glenn > >> -----Original Message----- >> From: Glenn M. Keeni [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