[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-shafer-netconf-syslog-00.txt



Cridlig Vincent wrote:
Phil Shafer a écrit :
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.  ;^)

Unfortunately, somebody has to go first.

I suspect that the co-Chairs, ADs, and rest of the IESG are not
going to be very impressed with this excuse as a justification
for what appears to be a very questionable design decision.


Andy



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.
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)
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/>




--
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/>