RFC 4741 defines Netconf 1.0 and RFC 6241 defines Netconf 1.1. Section 3.1 of these RFC says that;
All NETCONF protocol elements are defined in the following namespace: urn:ietf:params:xml:ns:netconf:base:1.0
My query is; RFC6241 has defined a new RFC <cancel-commit> with the same XML namespace. Do not we need a new namespace to identify this new RPC operation? Please clarify.
Please clarify the role of Namespace.
No, a new namespace is not needed every time an operation is added to the protocol.
A namespace is just a grouping of names. It exists to prevent name clashes. If some entity (other than the IETF NETCONF WG) decides that "cancel-commit" is an appropriate name for one of their operations, they can use this same name - by placing it in a different namespace and retaining the (local) name. No name clash can occur between the two "cancel-commit" names, since the clash is resolved by their namespace.
If there is no clash between local names within a namespace after adding a new name, any name can be added to it.
You can also take a look at this from the YANG perspective (the data modeling language for NETCONF). A YANG module is essentially a namespace. Would you publish a new YANG module with a changed namespace statement every time you add a rpc or action schema node to it? No, you would not. That is also why we have two revisions of the same module (ietf-netconf) for the two versions of the protocol (1.0 and 1.1). (I forgot that 1.0 predates YANG, but you probably get the idea. There is only one revision of ietf-netconf in existence).
What defines the version of the protocol (and whether "cancel-commit" is available) is the base NETCONF capability, reported as part of a NETCONF hello message (for 1.1):
urn:ietf:params:netconf:base:1.1
Capabilities are advertised in messages sent by each peer during session establishment. When the NETCONF session is opened, each peer (both client and server) MUST send a element containing a list of that peer's capabilities. Each peer MUST send at least the base NETCONF capability, "urn:ietf:params:netconf:base:1.1". A peer MAY include capabilities for previous NETCONF versions, to indicate that it supports multiple protocol versions.
Note how this URI differs from the namespace for NETCONF protocol XML elements (no :xml:ns).
The capability for NETCONF 1.0 is urn:ietf:params:netconf:base:1.0.
