Hi

Comments inline.

> My position is that -protocol should NOT contain any transport mapping
> and that there should be a short RFC outlining how -protocol is to be
> mapped on UDP transport.

I think it is important to have at least one transport mapping to ensure
interoperability.

>
> > I'm a bit doubtful about doing that
> > as it would
> > allow people to do syslog-protocol/tcp, or
> > syslog-protocol/sctp, etc.

SNMP has had one required transport mapping, and permitted additional
mappings. In fifteen years of use, no attempt to add transport protocols
has gathered enough industry interest to really succeed, and SNMP is a
protocol with many known problems directly caused by the UDP transport
limitations. I suspect your fears will not be realized.

> If we do this,
> I'll probably
> > insist that syslog-protocol/udp be a REQUIRED implementation
> > and others
> > are OPTIONAL.

I think having one required is the right way to go, and I think it would
be useful to have the WG define at least one alternate protocol mapping,
which addresses the major shortcomings of the required transport, to
help ensure that we don't end up with a bunch of proprietary
implementations for the same alternate transport.

>
> I think this is an very important comment in regard to the overall
> design. I think it is of advantage to facilitate the creation of other
> transport mappings, as for example is currently being
> discussed for SNMP
> inform messages.

Where is this discussion taking place? In the syslog WG or in the SNMP
community? As an active member of the SNMP community, I don't think I'm
aware of this discussion. I am aware of discussions about adding TCP
transport for all types of SNMP messages, not just informs, but that
effort is dying the slow death of apathy.

> I agree that it makes it easy to "abuse" -protocol to
> create non-standard transport mappings.

See my comment about the slow death of apathy. I think people may be way
too worried about a proliferation of transport mappings. New transport
mappings will only be supported if there is a solid economic benefit
involved. Again, the SNMP community has permitted alternate transport
mappings for years, but few if any vendors have actually supported them
in their equipment.

> this is current state of the art, there ARE many syslog/raw tcp
> implementations in the wild.

I recommend that we work to standardize these additional mappings if
they already exist in the wild and have proven truly useful. I recommend
checking to see how many operators actually enable and USE those
syslog/raw tcp implementations.

dbh


Reply via email to