On Fri, Jan 03, 2020 at 11:39:31AM +0000, Jonathan wrote: > > Since <operational> is the only way to expose config false nodes for > > an NMDA server, it is kind of mandatory as soon as you have config > > false nodes to expose.
> RFC 6241 describes <get> as retrieving "running configuration and device > state information" and <get-config> as retrieving "all or part of a > specified configuration datastore". RFC 8526 introduces <get-data> which it > describes as "similar to NETCONF's <get-config> operation". As far as I can > tell, neither RFC 8342 not RFC 8526 actually identify which operation to use > to retrieve operational state data. Am I right in assuming it would be > <get-config>? In that case, it is similar to <get> when performed on > <operational> as it will also return state data. There is quite some discussion of 'operational state datastore' in subsections of section 3.1.1 'The <get-data> Operation' in RFC 8526. There is also an example in section 3.1.1.4. The <get-config> operation returns config data, hence it won't return config false data, i.e., its not a good choice for <operational>. The reason why we have NMDA is that <get> semantics have been found to be problematic. Hence, NMDA systems should use RFC 8526 operations (<get-data> and <edit-data>) when talking to each other. > And what should be the result of performing <get> on an NMDA-supporting > server? Should it still return config true nodes from <running> plus config > false nodes from <operational>? Or should the operation be rejected? A proper NMDA client should never send a <get>. Supporting <get> only makes sense for legacy clients and they might expect RFC 6241 behaviour as far as that is implementable (the reason we have NMDA is that <get> semantics assume that <running> is identical to <applied> config, which is just not always true). /js -- 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
