Phil Shafer wrote:
Shane Kerr writes:
Each notification is valid XML, self contained. Do we really need to
wrap the set for some reason?
I see the other side. Do we really need to break the existing RPC
mechanism for something that can be easily handled within it? Given
that the notifications are likely to get simple syslog messages,
the requirement to be self contained is easily fulfilled.
I believe the kind of tool that only does stand-alone full
document parsing should not be the focus of our design.
This seems to be like designing SNMP for MIB walker tools.
When that happened, it became almost all SNMP was good for.
I suspect that all the actual agent and manager implementers
will be using an event-driven parser, not a document-driven parser.
Since the WG doesn't agree on the functional requirements
for notifications, it is not surprising that there is no
agreement on the solution. Since all Phil and I really want to do
with NETCONF notifications is deliver text or XML syslog,
this would be fine. I'm not sure what the rest of the WG
wants to do with these things.
I hate Requirements Documents but this document has hardly
been read or reviewed by anybody in the WG. I think we
should try to agree on what we want to do with NETCONF
notifications before going any further. Real use cases,
based on real products, used in real networks -- not
"nice-to-have", "maybe need this someday" features.
Thanks,
Phil
Andy
--
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/>