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 Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog