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

[Phil Shafer <phil@juniper.net>]

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.

Thanks,
 Phil

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