RFC 4741定义Netconf 1.0,RFC 6241定义Netonf 1.1。RFC第3.1节规定:;
All NETCONF protocol elements are defined in the following namespace: urn:ietf:params:xml:ns:netconf:base:1.0
我的疑问是;RFC6241定义了具有相同XML名称空间的新RFC<cancel-commit>
。难道我们不需要一个新的命名空间来识别这个新的RPC操作吗?请澄清。
请澄清命名空间的角色。
不,每次向协议添加操作时都不需要新的命名空间。
名称空间只是一组名称。它的存在是为了防止名称冲突。如果某个实体(除了IETF NETCONF WG之外(决定;取消提交";是他们的一个操作的合适名称,他们可以使用相同的名称——将其放在不同的命名空间中并保留(本地(名称。两个"名称"之间不会发生名称冲突;取消提交";名称,因为冲突是通过名称空间解决的。
如果在添加新名称后,命名空间内的本地名称之间没有冲突,则可以向其中添加任何名称。
您也可以从YANG(NETCONF的数据建模语言(的角度来看这一点。YANG模块本质上是一个名称空间。您会在每次添加rpc或操作模式节点时发布一个新的YANG模块并更改名称空间语句吗?不,你不会的这也是为什么我们为协议的两个版本(1.0和1.1(对同一模块(ietf-netconf(进行了两次修订。(我忘了1.0早于YANG,但你可能已经知道了。ietf-net conf只有一次修订(。
定义协议版本(以及"取消提交"是否可用(的是基本NETCONF能力,作为NETCONF问候消息的一部分报告(对于1.1(:
urn:ietf:params:netconf:base:1.1
在会话建立。当NETCONF会话打开时,每个对等(客户端和服务器(必须发送包含该对等方的能力列表。每个对等方必须至少发送基本NETCONF能力;urn:ietf:params:netconf:base:1.1";。同行可能包括以前NETCONF版本的功能,以表明它支持多个协议版本。
8.1.能力交换
请注意此URI与NETCONF协议XML元素(无:xml:ns
(的命名空间有何不同。
NETCONF 1.0的功能是urn:ietf:params:netconf:base:1.0
。