RE: [Syslog] delineated datagrams

[Balazs Scheidler <[e-mail]>]

On Fri, 2006-08-04 at 13:59 -0400, David Harrington wrote:
> Hi,
> 
> As you probably know by now, I like to see design reuse across IETF NM
> solutions, especially across SNMP, syslog, ipfix, and netconf where
> feasible.
> 
> As all the IETF NM protocols move toward similar secure transport
> solutions, including moving from datagrams to streams, it would be a
> good thing to use consistent aproaches to framing.
> 
> Here is what is happening in the other IETF NM protocols:
> 
> SNMPv1/v2c/v3 uses octet-counting within its BER encoded messages.
> For SNMP over TCP (RFC3430):
>    It is possible that the underlying TCP implementation delivers byte
>    sequences that do not align with SNMP message boundaries.  A
>    receiving SNMP engine MUST therefore use the length field in the
>    BER-encoded SNMP message to separate multiple requests sent over a
>    single TCP connection (framing).  An SNMP engine which looses
> framing
>    (for example due to ASN.1 parse errors) SHOULD close the TCP
>    connection. 
> 
> SNMP over SSH (ISMS) does not specify how to delineate datagrams,
> beyond the BER octet-counting.
> (As editor of the SNMP/SSH draft, I will probably copy the text from
> RFC3430.)
> 
> IPFIX uses octet-counting. See
> http://www.ietf.org/internet-drafts/draft-ietf-ipfix-protocol-22.txt
> section 3.1.
> 
> The NETCONF protocol uses an RPC-based communication model.  
> From
> http://www.ietf.org/internet-drafts/draft-ietf-netconf-prot-12.txt:
>    NETCONF peers use <rpc> and <rpc-reply> elements to provide
> transport
>    protocol-independent framing of NETCONF requests and responses.
> There is ongoing discussion about the framing in the netconf
> notification protocol, and the possibility of interleaving
> notifications and request/responses within a session or channel. 

I see a significant difference between syslog and and SNMP, SNMP is
binary and has an internal structure with no appearent record
terminator. 

IPFIX is again different to syslog, it has a well defined binary
structure, adding a "byte counter" is a natural extension of the
protocol.

Netconf as I see from your description started out with a stream based
transport from the first place (and by browsing the RFC quickly)

In this sence Netconf has the most similarities to syslog, it has a
text-based internal structure (XML) and no byte-counter based framing,
the closing XML tag finishes the transaction.

Syslog also has a text based internal structure (one syslog entry),
terminated via NL. Adding a byte counter feels somewhat alien.

I agreed with Rainer about byte-counters when he proposed that, I did it
for the sake of moving forward.

Dropping the byte counter idea and adding simple extensions to the
message format (trying to stay compatible as much as possible) could buy
us very easy migration to the new protocol. In fact this would mean that
currently deployed existing syslog/tls implementations would be
compliant.

I read through the BEEP based syslog protocols and I liked some of the
features it'd provide (see the mailing list archives), however I don't
like that syslog/COOKED is not simply a syslog transport, but a format
spec as well. After specifying syslog-transport-tls we might continue
working on a BEEP based transport but strictly adhering to the current
syslog message model (e.g. skipping the XML message representation which
has no benefits over SD-IDs but is a lot more verbose).


-- 
Bazsi


_______________________________________________
Syslog mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/syslog