Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02

2007-11-14 Thread Glenn M. Keeni
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 [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


Re: [Syslog] WGLC: draft-ietf-syslog-tc-mib-02

2007-11-11 Thread Glenn M. Keeni
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