Andreas Siegert wrote:
> [...]
>
> What is wrong with having a basic set of
> facilities in /etc/facilities as part of the protocoll and lots of user
> defined ones that can be added?
Because it almost guarantees that one or more of the following will happen:
* Embedded implementations by Cisco, 3Com, Lucent, Nortel, etc. won't allow you
to change the facilities mapping.
* The Microsoft implementation will bury everything in the registry, requiring
you to hand-edit every box to get it to look like your others.
* Sun, HP, IBM, SCO, SuSE, Red Hat, Caldera, Corel, Mandrake, OpenBSD, BSDi,
NetBSD, FreeBSD, Cisco, 3Com, Lucent, Nortel, and Microsoft will all have their
own extension facilities that conflict with each other and you won't be able to
change them in /etc/facilities (for those that even have /etc/facilities) on
each box because you can't recompile all the bundled programs that have the
facility numbers hard coded in some way instead of referencing the
/etc/facilites database.
* There will be programs that stop logging because they use some weird facility
name that you didn't include in the standard /etc/facilities file for your
site.
* You'll spend all your time hunting down people who setup a new machine and make
use of the centralized logging service, but who didn't use the site-standard
/etc/facilities.
* You'll merge with another organization and will have to get a unified
/etc/facilites on everybody's machines, which will turn into a political
football.
* You'll run into management that wants all boxen to be "pure" and won't let you
change /etc/facilities on their machines.
* You'll realize that you really want hierarchical facilities, which this scheme
can't support.
Facilities as text strings totally avoids these problems. Documenting the existing
facilities names (and maybe a few new ones) in the RFC solves the problem of people
using totally divergent names.
Yes it's more bandwidth. No it's not that much more unless you chose egregiously
long names. And besides, the bytes will probably be in the message text if they're
not in the facility name.
> [...]
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
