Subject: [Syslog-sec] Required transport

From: "Anton Okmianski" <[email-masked]>
Date: Thu, 28 Oct 2004 18:17:09 -0400

Hi!

I am doing final edits to the new revision of udp transport draft. I want to return to one issue we touched upon before. We have stated this in the past: 

"This transport protocol is REQUIRED for all syslog protocol implementations."

I am not 100% comfortable with this. I am looking at syslog as a protocol which is often embedded in the application, not general purpose re-usable syslog libraries which some people have in mind. If my application only want to send syslog messages via some TCP mapping, why should it be required to implement the UDP part which it does not intend to use?

Same thing on the receiver.  I understand the use case of general purpose syslog receiver.  However, if I have special purpose application to listen to faults from a given other application, why must I implement udp mapping?  

I have indeed worked on applications which fall into the above two scenarios. The sending one did indeed use UDP. But if we have chosen TCP, I don't see how the UDP transport requirement would have applied to us.  

Any sentiments against striking this requirement?

Thanks,
Anton. 

_______________________________________________
Syslog-sec mailing list
[email-masked]
http://www.employees.org/mailman/listinfo/syslog-sec

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 29 Oct 2004 10:45:39 -0400

Hi,

We are in the business of defining standards to ensure
**interoperability**. If we do not choose a transport that is required
for compliance, then two implementations compliant to the standard,
where one uses UDP and the other uses TCP, would not be interoperable.

The goal of this group is to define a standard set of features to be
included in implementations to guarantee interoperability between
**any** two independent implementations compliant to this standard. 

In the scenario you discuss, the implemention is for a "special
purpose application". The implementor doesn't care about
interoperability with **any** other implementations, only other
**specific-application** implementations, so there is a different set
of interoperability requirements for that special application (TCP,
special messages, etc.). The implementor does NOT need to develop to
the IETF standard for general-purpose syslog interoperability, and
therefore doesn't need to implement UDP support. They just cannot
claim compliance to the IETF standard if they don't. But that should
not be very important because their main claim is that they provide
the special-application functionality.

Our job is not to develop standards that fit the architectures of
specific-purpose applications so marketing departments can claim IETF
standards-compliance, it is to develop a minimum set of compliance
rules to ensure interoperability between independent implementations.
Selecting one transport and making it a requirement is an important
part of the standard.

David Harrington
[email-masked]

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Anton
Okmianski
Sent: Thursday, October 28, 2004 6:17 PM
To: [email-masked]
Subject: [Syslog-sec] Required transport

Hi!

I am doing final edits to the new revision of udp transport draft. I
want to return to one issue we touched upon before. We have stated
this in the past: 

"This transport protocol is REQUIRED for all syslog protocol
implementations."

I am not 100% comfortable with this. I am looking at syslog as a
protocol which is often embedded in the application, not general
purpose re-usable syslog libraries which some people have in mind. If
my application only want to send syslog messages via some TCP mapping,
why should it be required to implement the UDP part which it does not
intend to use?

Same thing on the receiver.  I understand the use case of general
purpose syslog receiver.  However, if I have special purpose
application to listen to faults from a given other application, why
must I implement udp mapping?  

I have indeed worked on applications which fall into the above two
scenarios. The sending one did indeed use UDP. But if we have chosen
TCP, I don't see how the UDP transport requirement would have applied
to us.  

Thanks,
Anton.