>> * Facility
>> o A string, not a number!
> Nope. Major redundant waste of disk space, network bandwith and line
> width.
Disk space and line width are presentation issues, and I'd note that
currently facilities are in text form by the time theyhit the disk
anyway, so this is making them no worse.
As for network bandwidth, if you want your facilities small, use "a",
"b", "c", etc! Don't cripple the protocol with your site's
constraints...please!
> Can easily be reconstructed out of /etc/facilities.
Not unless you can come up with some way to magically ensure
/etc/facilities (or analog thereof) is in sync across all hosts
involved. Indeed, I would argue that any sort of central registration
of facility names - even per-machine, and a per-machine central
registray is exactly what /etc/facilities is - is bad.
>> * Identifier for the originating system
>> o DNS name, IP, whatever
> IP only. DNS names are less reliable and resolving them takes time
> that we might not have.
But we might have it, too, and in some environments you want what the
name was at the time, not what it may be by the time you get around to
looking at it. "Make it configurable."
I also note that using IP addresses restricts the protocol to use over
IP, which would be a bad thing for that person who wanted to use serial
lines to a logging strongbox machine.
der Mouse
[EMAIL PROTECTED]
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
