On Wed, Jun 17, 2015 at 01:41:56PM +0200, Ladislav Lhotka wrote: > > > Well, but it is exactly what Kent objected against. It is the requirement to > support “old clients” that causes the trouble here (and elsewhere). If client > A sets “inactive” somewhere, then the datastore semantics will change also > for client B that doesn’t understand “inactive” and may be wondering why the > server ignores his edits. > > I understand (although RFC 6241 doesn’t say it explicitly) that, unlike YANG > extensions, a NETCONF capability advertised by the server can be mandatory > for the client in the sense that it has to understand and honour it.
There is no way for a client to tell whether a certain capability URI (it has never seen before) is mandatory to understand or not. In fact, I would say in a proper solution it would be the server would have to close the connection if it finds a client that does not understand its language. And yes, we are on very slippery grounds here. If implementors can create arbitrary cool 'annotations' that break clients that do not understand them, we will loose interoperability. > A conclusion of this may be that it makes no sense to define > annotations through YANG extension after all. On the other hand, I > do see a value of having annotations defined in YANG modules. Without further protocol support to negotiate annotations, I think annotations must be limited to things that can be safely ignored by a client. I have not read the I-D yet but I would expect that it should say something like that. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
