RE: Facility (was: RE: [Syslog-sec] Syslog protocoldraft(draft-ietf-syslog-protocol-11.txt))

["Rainer Gerhards" <rgerhards@hq.adiscon.com>]

Alex,

please go through 

http://www.syslog.cc/ietf/autoarc/msg01406.html

It was not about facility, but the other similar fields. Based on that
discussion, I think it would still make sense to retain facility as it
is (especially because it is a key concept know to the syslog
community).

Rainer 

> -----Original Message-----
> From: syslog-sec-bounces@www.employees.org 
> [mailto:syslog-sec-bounces@www.employees.org] On Behalf Of 
> Alexander Clemm (alex)
> Sent: Wednesday, May 11, 2005 1:56 AM
> To: alex@cisco.com; syslog-sec@employees.org
> Subject: Facility (was: RE: [Syslog-sec] Syslog 
> protocoldraft(draft-ietf-syslog-protocol-11.txt))
> 
> Hi,
> 
> I wanted to again bring up the concept of facility.  Perhaps 
> the working
> group has gone through this many times before already, in which case I
> apologize as I'm still "new to the party".   Is there any specific
> strong reason why facility should be restricted to a number 
> in the range
> 0..2147483647?  If not, my preference would be that facility not be
> restricted to a numeric identifier, but that alphanumeric 
> characters be
> permissible.  
> 
> Now, taking this further, section 6.2.2 indicates that facility may be
> "operator assigned" and may be utilized for some "grouping of 
> messages"
> by receivers.  This appears to be pretty application 
> specific, and I am
> wondering if this type of semantics really belongs in the 
> "core" of the
> protocol, or if (since it may essentially involve application-specific
> semantics) it it would not be more appropriate to put such a facility
> into SD elements.  It would appear that the "core" should only include
> fields that will be used widely across by pretty much any
> implementation, with very precisely defined semantics, while SDs are
> more intended for things that are optional, or things whose 
> use depends
> on certain conditions.  As facility is currently defined in section
> 6.2.2, it appears more a candidate for the latter.  Any comments?  
>  
> Thanks
> --- Alex
> 
> 
> -----Original Message-----
> From: syslog-sec-bounces@willers.employees.org
> [mailto:syslog-sec-bounces@willers.employees.org] On Behalf 
> Of Alexander
> Clemm (alex)
> Sent: Monday, May 02, 2005 8:47 AM
> To: syslog-sec@employees.org
> Subject: [Syslog-sec] Syslog protocol
> draft(draft-ietf-syslog-protocol-11.txt)
> 
> [...]
> 
> Required syslog format:  There are essentially 3 parts of the message
> which identify the originator of the message, not even 
> counting the host
> name:
> Facility, App-Name, Proc-ID.  
> - Should they be grouped together - why separate them for example with
> the truncate field - may want to take a look at the order of 
> the fields.
> I would think that the truncate field should in fact either 
> appear after
> the version field, or right before the structured data field.  
> - Why would facility consist only of digits, not alphanumeric 
> characters
> - Are three fields really needed?  It seems that it makes 
> sense to allow
> to identify the type of the subsystem or application that 
> generates the
> syslog message, as well as the particular instance in case there are
> several.  This makes two fields.  Why a third field?  
>  
> [...]
> _______________________________________________
> 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