RE: [Syslog-sec] Required transport

["David B Harrington" <ietfdbh@comcast.net>]

Hi Anton,

I think you'll find the IESG will expect the WG to select one
transport as the interoperability baseline for the standard.
I could of course be wrong, so I suggest the area directors be
consulted to see what expectations they have on this issue.

dbh

-----Original Message-----
From: Anton Okmianski [mailto:aokmians@cisco.com] 
Sent: Friday, October 29, 2004 2:02 PM
To: ietfdbh@comcast.net; syslog-sec@employees.org
Subject: RE: [Syslog-sec] Required transport

David:

> 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. 

I think this will still be assured.  Example:

RFC A - syslog protocol
RFC B - udp mapping
RFC C - tcp mapping

If somebody says they are complaint to RFC A, it only means that they
follow message format.  If somebody says that they are complaint with
RFC B, then it means they support UDP transport for syslog.  So, I
don't see any ambiguity or interoperability issues between
implementation claiming to support a given RFC. Why should support for
RFC C require support for RFC B?  

Here is a practical analogy.  My mail application can retrieve email
using POP3, IMAP or MS Exchange protocol.  MIME, which defines mail
format, does not say that you MUST use it over POP3 to ensure
interoperability.  It is a choice of application vendors and
administrators what they will implement. This works pretty
interoperably as far as I can tell since we read email from each
other. And it opened the possibility for various alternatives.  

> 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.

In the case I was mentioning an application cares about interoperating
with standard syslog loggers, but only with ones that support a TCP
transport RFC. Very simple qualification.  Obviously, administrator
will need to ensure that the syslog implementation on the other side
implements TCP binding RFC if they want to use an application like
this. 

> 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.

All applications are special-purpose. I am not talking about
accommodating some strange scenario.  But rather what would be a
pretty standard use case where an application would want to support
just one transport for reasons of reliability, for example. Initially,
vendors may choose to support UDP, but as other transport mappings
become prevalent, they should not be required to be stuck to legacy
transport. 

What you are saying is that if vendor wants to use just TCP and claim
compliance to RFC C, it must implement UDP and RFC B.  I see
absolutely no practical point in this if application does not intend
on using UDP transport.   

I also don't see a need for featuring UDP as a preferred (ie
"standard") transport, while we know all of its deficiencies. In fact,
I can see a danger in this. It may drag syslog protocol back instead
of allowing it to evolve to better transports.    

I think our goal for this effort was specifically to make syslog
protocol transport-independent. Kinda like SOAP messages which can be
sent over whatever transport. Mandating a UDP mapping IMO defeats this
purpose, even if it provides for possibilities for optional
extensions.  

Anton.



_______________________________________________
Syslog-sec mailing list
Syslog-sec@www.employees.org
http://www.employees.org/mailman/listinfo/syslog-sec