On Wed, Jun 17, 2015 at 6:13 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> > > On 17 Jun 2015, at 14:50, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > > > > On Wed, Jun 17, 2015 at 02:34:52PM +0200, Ladislav Lhotka wrote: > >> > >>> On 17 Jun 2015, at 13:51, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > >>> > >>> 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, > >> > >> So it means that, e.g. the annotations from > >> > >> https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00 > >> > >> cannot be safely used by the server even after advertising them via > :conditional-enablement capability. > > > > Yes, advertisement is not sufficient. > > > >>> 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. ;-) > >> > >> But it’s not a specific problem of this draft, it would simply mean > that annotations that cannot be ignored cannot be used at all, no matter > what. However, some annotations that have been proposed (and probably used > in the wild) are of that sort. > >> > > > > They cannot be used safely until there is an annotation negotiation > > mechanism, or as Martin indicated, a way for a client to explicitely > > enable the functionality associated with certain annotations. > > Even this breaks down if an annotation has global side effects. This > actually seems to be true for the whole idea of a client cherry-picking > from the capabilities (and YANG modules) advertised by the server. > > IMO conditional enablement is trivial to add in a way that does not break clients unaware of the disabled nodes. As Martin pointed out, the only way the client can see them is to ask explicitly that the metadata be returned. Otherwise the disabled nodes look like deleted nodes. For validation purposes, they are deleted nodes. The NETCONF-EX <get2> operation had a "metadata" parameter so the client could ask for specific attributes. Hard-wired parameters like "with-defaults" or "with-disabled" will also work. If the client cannot ignore the behavior defined by the capability, then it isn't a NETCONF protocol capability, it's a different non-standard protocol. > Lada > Andy > > > > > /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/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
