Hi Tom, You're right; I didn't go far enough. I was looking for a framing defined by the netconf protocol, not the separator of messages within a transport. Unfortunately, Netconf uses a number of transport-dependent schemes within the multiple transports it supports, including both octet-counting approaches and terminating character approaches. Sigh.
The "]]>]]>" sequence only works in the SSH transport mapping, not the BEEP or SOAP mappings. So much for trying to find consistency. Note that Netconf is considering a design that allows multiple syslog messages to be sent in a netconf notification session. If we used "]]>]]>" as a syslog message delimiter, we would prevent netconf from transporting multiple syslog messages, since netconf can only transport valid XML, and the "]]>]]>" in a syslog message would indicate the end of an <rpc-reply>, causing netconf to lose synchronization? See the Montreal Netconf Interim minutes currently available on the netconf mailing list for more details. David Harrington [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > -----Original Message----- > From: Tom Petch [mailto:[EMAIL PROTECTED] > Sent: Monday, August 14, 2006 6:36 AM > To: David Harrington; 'Chris Lonvick'; 'Miao Fuyou' > Cc: [EMAIL PROTECTED] > Subject: Re: [Syslog] delineated datagrams > > ----- Original Message ----- > From: "David Harrington" <[EMAIL PROTECTED]> > To: "'Chris Lonvick'" <[EMAIL PROTECTED]>; "'Miao Fuyou'" > <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; "'Tom Petch'" <[EMAIL PROTECTED]> > Sent: Friday, August 04, 2006 7:59 PM > Subject: RE: [Syslog] delineated datagrams > > > > > > 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: > > > <snip> > > > > 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. > > Ok as far as it goes but incomplete. As the ssh mapping says, > > " As the previous example illustrates, a special character sequence, > ]]>]]>, MUST be sent by both the client and the server > after each XML > document in the NETCONF exchange. This character sequence cannot > legally appear in an XML document, so it can be > unambigiously used to > indentify the end of the current document in the event of an XML > syntax or parsing error, allowing resynchronization of the NETCONF > exchange." > . > Wishing to promote design reuse across IETF NM solutions, > especially across the > character-based ones, I did propose the same separator for > syslog over tls and > still see it as the technically best solution (even though > our message content > can be anything and so, unlike NETCONF, we cannot rely 100% > on that not > appearing in our message content). > > > > > David Harrington > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > _______________________________________________ Syslog mailing list Syslog@lists.ietf.org https://www1.ietf.org/mailman/listinfo/syslog
