Subject: [netconf] kw review of draft-wu-netconf-nmda-compatibility-01

From: Kent Watsen <[email-masked]>
Date: Mon, 25 Mar 2019 05:29:10 +0000

I started reading this document, but struggled with this sentence in the Introduction:

“NMDA Transition Guidelines in section 4.23.3 of [RFC8407] <snip/> doesn't provide guidelines on whether existing NETCONF protocol operations such as get/get-config/edit-config change semantics when they are exchanged between the non NMDA client and the NMDA aware  server.”

Correct, no statements are made (here or in RFC 8526), because no changes exist.  RFC 6241 is unchanged by RFC 8526. 

The draft also has this statement in the Problems section:

“When a server is upgraded to NMDA aware server and needs to support
both NMDA client and non-NMDA clients, there is no standards-based way for the server to know whether the client supports NMDA.”

True, but it doesn’t matter, as the server only cares if the client uses the RPC from RFC 6241 or RFC 8526.  

In order to maintain backwards compatibility, there are *no* changes to RFC 6241.   It is an implementation issue for the NMDA-aware server to maintain support for the non-NMDA aware RPCs.  

FWIW, the draft also has suggestions for clarifying NMDA behavior (e.g., with-defaults), which may be needed, but I didn’t dig into these suggestions as I want to first ensure my understanding of the problem statement. 

Thanks, 
Kent // contributor

---

From: Qin Wu <[email-masked]>
Date: Mon, 25 Mar 2019 07:31:27 +0000

发件人: netconf [mailto:[email-masked]] 代表 Kent Watsen
发送时间: 2019年3月25日 13:29
收件人: [email-masked]
主题: [netconf] kw review of draft-wu-netconf-nmda-compatibility-01

“NMDA Transition Guidelines in section 4.23.3 of [RFC8407]<https://tools.ietf.org/html/rfc8407#section-4.23.3> <snip/> doesn't provide guidelines on whether existing NETCONF protocol operations such as get/get-config/edit-config change semantics when they are exchanged between the non NMDA client and the NMDA aware  server.”

[Qin]: No intention to change existing protocol operation, but we believe clarification on protocol behavior is needed or additional behavior needs to be considered since coexisting NMDA client and Non-NMDA client to communicate with NMDA server does exist.

[Qin]:Exactly, we believe we can use RPC from RFC6241 or RFC8526 to distinguish the RPC request is sent from NMDA client or non-NMDA client.

[Qin]: I still have misconception to maintain protocol backward compatibility, e.g., default config, system config, where does these config data saved? <running>?

After NMDA is introduced, these config data seems to moved to <operational>? Correct, based on RFC6241, it seems to indicate default config is part of <running>, but for system config, which datastore  is it saved within NETCONF server? It is unspecified. if this is true, to maintain backward compatibility, the current NMDA NC spec doesn’t tell us how to handle these config data relocation,

Should this config data relocation be aware of Non NMDA Client or not?

[Qin]:Yes, this is intention. We want to address NMDA implementation ambiguity issues.

Thanks,

Kent // contributor