Phil Shafer a écrit :
I personally prefer the solution embedding syslog messages in a <notification> element (specified in http://www.ietf.org/internet-drafts/draft-ietf-netconf-notification-01.txt)Vincent Cridlig writes:I don't really understand the design choice of the get-syslog-streams operation because I think it breaks the idea of the get-config operation.Syslog stream definitions are not limited to configuration, since the device may define default streams.Wouldn't it be more conform to Netconf to define a short data model for syslog streams and use the regular get-config with a selection node ?I'm not prepared to be the first lamb on that altar. ;^)For the second part 3.2, I am confused. What happens if I send a get-syslog-events with a stop-time one hour later ? Can I still use this Netconf session to send other RPC during this time ? I guess no. The Netconf session would be locked for a long period of time.Yup, exactly.If I understand well, this approach assumes that the agent is parsing the XML data stream on the fly (like with SAX, but not DOM). Because the rpc-reply does not seem to be closed until a stop condition happens and DOM can not read a partial document. If this is the case, must the agent assume that the rpc-reply message will be valid before it received the whole message ? And process it ?Yes, if you are looking for a real-time stream, you'll need to use a technology that allows you to parse it as it arrives. SAX is perfect for this, giving you callbacks to drive a simple state machine.
for the following reasons:- It does not block the Netconf session, so you can receive syslog notifications and still do other things, (Otherwise you need two Netconf sessions) - The processing of messages is easier because parsing partial messages is not necessary. Just considering the special caracter ]]>]]> for sequencing the messages. I prefer to process a buffer of full Netconf messages than start processing a stream which could contain errors lately, - You can check message well-formness and validity before processing it => more secure, - You can have the same functionnality (like receiving the next 100 syslog messages).
Minor point which is more a taste problem:Whatever will be the solution, I think syslog messages should be parsed and rebuilt in an XML structure on the agent side, before being sent to the manager. This is easy to do (there are plenty of parser generator) and makes the management application more consistent, because everything is formatted in the same way. The agent would behave like a full syslog/Netconf gateway, similar to what was done with XML/SNMP gateways.
Regards, Vincent___________________________________________________________________________ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com -- to unsubscribe send a message to netconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://ops.ietf.org/lists/netconf/>