[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Notification-04 comments
Hello,
The document has improved a LOT.
General)
Do we really need 3 namespaces, wouldn't one or two suffice?
targetNamespace="urn:ietf:params:xml:ns:netconf:subscription:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:notification:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:replayNotification:1.0"
and the targetnamespace in 3.2.5.3 is missing
I find it confusing that we have several separate XML Schemas. I would like to see them
merged, it would make the draft easier to understand.
I feel the XML Schema should start with a top level element (e.g. <top>) and specify the
containing elements all the way down.
I would prefer to see examples for each and every defined message/operation/RPC.
Chapter 1.4)
What does the one but last requirement mean?
Chapter 3.1) The capability string should be defined under it's own heading like in
chapter 7.3.
Chapter 3.2.5.2) Why do we need this chapter? What is the difference between this and the
previous query? I propose to remove it.
Chapter 3.2.5.2) Targetnamespace is missing
Chapter 5)
"Currently, the NETCONF family of specification allows for running
NETCONF over a number of transport protocols, some of which support
multiple configurations."
What does it mean that they support multiple configurations. Isn't that valid for all
protocols?
Chapter 5) I think this example (without the ]]>]]> string) would be better placed in
chapter 2.2.1 where I am really missing an example.
I think all that's written in this chapter is trivial. We could live without this chapter.
Chapter 7.5.2) Put here some text or remove it.
Chapter 8) I feel that much of this chapter is trivial and does not contain any real new
information. For me the only meaningful part is the last paragraph.
I would add to the last paragraph that the security of the receiving manager application
might be different for the different protocols e.g. netconf, Syslog, Snmp. Based on this
it should be considered whether it is appropriate to send Snmp, Syslog, etc. information
via Netconf.
Balazs
--
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/>