> On 17 Jun 2015, at 17:13, Andy Bierman <[email protected]> wrote: > > > > On Wed, Jun 17, 2015 at 6:13 AM, Ladislav Lhotka <[email protected]> wrote: > > > On 17 Jun 2015, at 14:50, Juergen Schoenwaelder > > <[email protected]> wrote: > > > > On Wed, Jun 17, 2015 at 02:34:52PM +0200, Ladislav Lhotka wrote: > >> > >>> On 17 Jun 2015, at 13:51, Juergen Schoenwaelder > >>> <[email protected]> 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.
I don’t think it is that easy. What if an unaware client creates something in the inactive area which he sees as empty? Will all the inactive subtree be deleted? But I agree this is not the time to discuss this particular annotation. Martin proposed some text changes and I’d like to know whether everybody is happy with them. Lada > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
