[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Phil Shafer a écrit :
I've finally got an initial version of the draft for a netconf
capability that makes syslog data available over long-lived RPCs.
I just sent it off to the RFC Editor, so it should show up on
ietf.org sometime this weekend, but an advance copy is available.
A few comments and questions:
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.
IMHO, even if it is feasible and allowed by Netconf, nothing here
justifies the need of a new operation.
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 ?
The reply would be exactly the same as the one you described in the
draft (except the <data> element of course).
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.
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 ?
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.
org:LORIA - INRIA Lorraine, France;Madynes
tel;work:+33 (0)3 83 59 20 48