Hi Rainer,
On Thu, 22 Sep 2005, Rainer Gerhards wrote:
3) Backward compatibility and versioning are not really discussed.
You define semantics of the version field but these semantics
require the sender to be configured with the version that the
receiver will support. Is this extensibility model acceptable to
people who will deploy this protocol? Also, it seems that this
extensibility model means that making a change that requires a
version number bump is very costly. Structured data seems like the
major extensibility mechanism that does not require a version
number bump. Is this mechanism sufficient to make sure version
bumps will be infrequent?
The core problem with version number coexistence is that syslog traffic
is simplex. So it is not possible to have the sender and receiver
negotiate on a specific version (which would obviously relieve many of
the costs associated with it).
We are still using a header that is depending on the field positions and
avoids multi-line entities. The reasons are:
- keep as consistent with traditional syslog as possible
- allow coexistence with existing syslog implementations
(as outlined in section A.1)
- keep the header as small as possible - we have severe size
restrictions in syslog based on the need to fit a message into
a single IPv4 UDP packet without fragmentation (message are allowed
to be longer, but this probably reduces reliability in a
troubleshooting
case in a broken network)
Given the simplex nature and the header structure, it has been WG
concensus that the currently specified versioning is acceptable and not
a major drawback.
I also think that a version number bump - by its nature - is not
costlier than in other protocols. That it actually is costlier stems
back to the fact that the sender must be correctly (and manually)
configured, something that other protocols handle during initial
connection negotiation. Extending syslog to include a negotiation phase
and thus becoming a (half)duplex protocol would solve the issue;
however, it would bear a much higher cost in terms of acceptence of the
new protocol. Many implementors and users I have talked to inisit on
the simple "send it and forget it" nature of the syslog protocol. If we
would change that considerably, I would strongly expect to loose a lot
of acceptance. As a side-note, the added complexity is also the major
thing hindering real-world acceptance of RFC 3195. We tried to avoid
this problem in syslog-protocol, obviously at some cost. Here it is the
need to manually configure the sender.
On the frequency of version number bumps, we assume that the current
header provides every information needed in the forseeable future (of
course, "forseeable future" is a weak term...). We expect that most
needs can be addressed by structured data entries. For example,
syslog-sign is expected to use structured data and so is RFC 3195bis, if
there is need for extensions.
I think that Sam is also saying is that it would be appropriate to have a
section on what happens when we have the following situations:
- old style (RFC 3164) reciever receiving new style messages
- new style reciever recieveing 3164 messages.
And perhaps we should also examine what a Version 1 receiver would do with
a theoretical Version 2 message. Maybe if we feel that we've covered
everything, we might not need a version?
Thanks,
Chris
_______________________________________________
Syslog-sec mailing list
[email protected]
http://www.employees.org/mailman/listinfo/syslog-sec
