On Tue, Jul 31, 2018 at 02:27:36PM +0000, Christer Holmberg wrote: > > >> Related to that, it would also be good to have an interoperability > >> statement, saying that implementations that implement the draft will > >> still work with implementations that do not. > > > > This primarily concerns clients: They need to be able to fallback to > > using <edit-config> instead of <edit-data> and <get> instead of > > <get-data> if they communicate with a non NMDA NETCONF server. I am > > not sure whether this is a "SHOULD be able to fallback" or a "MUST be > > able to fallback". > > If you use MUST, you guarantee that fallback will always work (assuming implementations follow the spec). If you use SHOULD, I think you'll need some additional discussion on when it doesn't apply, what to do then, etc. > > So, my suggestion (from a reviewer perspective) would be MUST. > I am not sure about this. It is very well possible that in a few years client implementations may require NMDA and instead of trying a fallback they stop if the peer does not support NMDA. The complexity of clients varies widely, ranging from implementations that can hide the complexities behind an API to simple scripts without much fallback complexity. If we write MUST, it will be ignored in practice by a certain fraction of clients. /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/>
