A server that has a reason to support NMDA (because, for example, applied config can differ from running config) has to provide a 'cooked view' towards non-NMDA clients that is not representing the entire truth and hence may cause clients to draw wrong conclusions.
Perhaps there is a business case to cheat non-NMDA clients but for serious network operations, one would hope that the transition towards NMDA is ideally short so that clients can work with robust data. /js On Sat, Jun 29, 2019 at 12:21:48PM +0000, Kent Watsen wrote: > Hi Qin, > > > If my understanding is correct, Frank’s intention is not proposed to fall > > back to single datastore, split tree. His concern is how Does the non-NMDA > > client talk with NMDA compliant devices, suppose large amount of devices > > support NMDA. > > Using the original non-NMDA protocols, assuming the servers support both NMDA > and non-NMDA. > > > Does the device need to support both NMDA model and non-NMDA model? > > Yes, assuming a heterogeneous mix of NMDA and non-NMDA servers. > > > Is this common case or corner case in real deployment senario. > > While the industry is transitioning to NMDA, it is an expected case. At some > point, the IETF will obsolete non-NMDA support. > > > 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. > > Kent // contributor > _______________________________________________ > netconf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
