Re: [netconf] [netmod] RE: pls clarify get operation

[Qin Wu <[e-mail]>]

suggestions or guidelines defined in NMDA architecture and NMDA guideline(/rfc8407#section-4.23.3) seem to only assume NMDA client only talks with NMDA server, non-NMDA client only talks with non-NMDA server.

True, but there’s no statement that a client or server cannot be both.  Note also that the NC/RC-NMDA RFCs explain how clients can discover if a server supports NMDA.  The intention is that the client would first try to use NMDA and, if not supported, fallback to non-NMDA.

[Qin]:You are right, but it not specified in RFC8407. revisiting the section 4.23.3.1 of RFC8407
“
   A server that needs to support both NMDA and non-NMDA clients can
   advertise both the new NMDA module and the temporary non-NMDA module.
   A non-NMDA client can use separate "foo" and "foo-state" subtrees,
   except the "foo-state" subtree is located in a different (temporary)
   module.  The NMDA module can be used by a non-NMDA client to access
   the conventional configuration datastores and the deprecated <get>
   operation to access nested "config false" data nodes.

”
It provides guideline how to create temporary non-NMDA module from NMDA module, but temporary non-NMDA module is not standard module. So everybody will create the same temporary non-NMDA module?
I also feel this second paragraph is not very clear, especially the last sentence,  is nested config false data nodes part of NMDA module or temporary non-NMDA
Module? Looks like  nested config false data node part of NMDA module?
Can non-NMDA client consume NMDA module? If the answer is Yes, why the server need to advertise both NMDA and temporary non-NMDA module?
Why <get> operation is deprecated when non-NMDA client uses NMDA module?
How does the non-NMDA client deal with temporary non-NMDA module? Use <get> operation to get access to it?
How does the non-NMDA client distinguish NMDA module from temporary Non-NMDA module?

Kent // contributor