Sam, 

>     Rainer> Why? Simply
>     Rainer> because any transport-layer requirement (DTSL, SSL, SSH,
>     Rainer> whatever) would NOT be compatible with currently existing
>     Rainer> syslog implementations. So due to this requirement, we can
>     Rainer> not create a backwards-compatible spec (not even in the
>     Rainer> sense that existing receivers can put messages in the
>     Rainer> right bins). 
> 
> Let's be clear about what backward compatibility we're looking for.
> Do we require that new senders be able to be configured to talk to old
> receivers?  

I depens on what you mean with that - if "to be configured to talk to
old receivers" means they must not use -protocol but rfc 3164 instead,
this is not what was discussed on this list (-protocol-14 had addressed
this already).

> Or do we require that old receivers be able to put any
> message from a new sender into the right place?

Not over any transport, but the core need behind the recent changes was
that -protocol/-transport-udp messages should allow an old sender to put
it into the right bin. This implies  plain text transmission.

> 
> In particular what you're seeming to say implies that we cannot define
> new transports because doing so would be backward incompatible.  I
> don't think that is what we said.
> 
> If we do define a new transport, presumably both UDP and the secure
> transport would be mandatory to implement.

This looks like I misunderstood your intension. I thought that unsecured
UDP should no longer be supported. So what you actually said is that we
can go ahead with the unsecured UDP as long as we also mandate a
(different) secure transport.

If that is the case, I am reliefed, because this is something that can
practically be done. And, yes, configuring a sender to use unsecured udp
(-transport-udp) for one target and a secured transport for another
target is definitely a good option. We just need to be able to
interoperate with the "unsecured plain text udp syslog world".

Rainer

_______________________________________________
Syslog mailing list
Syslog@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/syslog

Reply via email to