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

["Glenn M. Keeni" <glenn at cysols.com>]

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:glenn at cysols.com] 
>> Sent: Monday, November 12, 2007 1:41 AM
>> To: David Harrington
>> Cc: syslog at ietf.org
>> 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
>>> dbharrington at comcast.net
>>> ietfdbh at comcast.net
>>>
>>>
>>>
>>> _______________________________________________
>>> Syslog mailing list
>>> Syslog at lists.ietf.org
>>> https://www1.ietf.org/mailman/listinfo/syslog
>>
>>
> 
> 



_______________________________________________
Syslog mailing list
Syslog at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog