At 01:17 PM 10/19/1999 -0700, d wrote:
>> [EMAIL PROTECTED] sez:
...
>First, however, does everyone agree with this, which I think is a
>fundamental concept:
>
>> * Interoperates (at least in degraded mode) with existing syslog
>> network protocol as both source and sink.
>
>I like that... but it's a key to many other decisions, I think. And
>what about config files, too - could syslog++ read those as well?
I think that in general the IETF does not deal with the behaviour of a
program on a single system. The IETF specifies interfaces between "things"
operating over the Internet (and by extension other IP networks). It is
probably beyond the IETF's scope to specify that an implementation has to
read some other software's configuration file.
Agree that the new protocol SHOULD include compatibility with the old
protocol for both pitch and catch (or source and sink, client and server,
heckyll and jeckyll, etc.). If it's not possible to do this easily in the
protocol, we should get a new port number and completely ignore the
existence of the old protocol. Implementations supporting both protocols
could then use both ports. Implementations supporting only one would use
only one port.
Should this new protocol be required to work over TCP, UDP, or both?
...
>> * The protocols must be simple enough to build support into
>> firewalls...
>
>I'd simply vote for a simple protocol, period. Complexity is asking
>for trouble, and is harder to get support for.
Firewalls are a bad measure of simplicity, too. Existing syslog over UDP
is pretty darn simple, but not really very compatible with most people's
ideas of what is "simple" across a firewall, I think.
...
>> * (Re-)Configuration of logging facilities/levels/destinations,
>> authentication mechanisms, and authorization mechanisms can be
>> done:
>> a. On the fly.
>> b. From the command line and/or by modifying config files.
>> c. From a GUI.
>
>How can you specify that a logging facility done through a gui, for
>goshsakes?
Also, this is another implementation detail. If my micropayment coke
machine has a fixed syslog configuration burned into a ROM, the IETF can't
tell, can't do anything about it, and mostly doesn't want to know.
...
>> Extensibility:
>> * Easy to add new logging facilities and have all machines understand
>> them and without recompiling source code.
>
>I'm not even sure what this means.
It means that some people's implementations are going to be more complex
than other people's. But it's an implementation issue.
The PROTOCOL requirement might include that the protocol be extensible, if
it can be made so without /u/s/i/n/g/ /A/S/N/./1 complicating it more than
the extensibility warrants. Some kind of escape-code facility might be
simple and workable.
