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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
