Ladislav Lhotka <lho...@nic.cz> wrote: > > > On 17 Jun 2015, at 14:20, Martin Bjorklund <m...@tail-f.com> wrote: > > > > Ladislav Lhotka <lho...@nic.cz> wrote: > >> > >>> On 17 Jun 2015, at 12:12, Martin Bjorklund <m...@tail-f.com> wrote: > >>> > >>> Ladislav Lhotka <lho...@nic.cz> wrote: > >>>> Hi Martin, > >>>> > >>>> thanks for the review. > >>>> > >>>> Martin Bjorklund <m...@tail-f.com> writes: > >>>>> o Last paragraph of section 3 and the "description" in the > >>>>> extension. > >>>>> > >>>>> The text says that semantics are defined "by other means". I > >>>>> think the semantics should be defined in the > >>>>> description/reference statements (by using links or inline text > >>>>> doesn't matter). > >>>> > >>>> Kent argued that an extension definition in YANG cannot make an > >>>> annotation part of the contract between the server and client: the > >>>> client can ignore it, and so the fact that the extension is defined in > >>>> a > >>>> module advertised by the server isn't sufficient for the server to > >>>> start > >>>> using the annotation and expect the client to take it into > >>>> account. > >>> > >>> Agreed. > >>> > >>>> Hence "by other means", which can be, e.g. a capability. > >>> > >>> Take the inactive thing as an example. I would assume that by > >>> advertising the module where inactive is advertised, the server > >>> announces that it implements the syntax *and semantics* of this new > >>> annotation. I do not expect one capability for the syntax, and > >>> another for the semantics. > >> > >> 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. > > > > Absolutely! > > > >> 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. > > > > No! > > > > My point is that how this affects the client must be considered > > case-by-case. > > > > In our implementation we support inactive, but the server sends the > > attribute only if the client explcitly asks for it > > (<with-inactive>true</with-inactive>, similar to with-default). > > But it’s not only matter of whether the server sends the attribute or > not but rather whether the server applies the inactive parts, and this > decision must be the same for all clients.
Again, my point is really that what to do and what is a safe behavior depends on the attribute. This document should not try to solve that problem. (In our case, if the client doesn't ask for inactive nodes, we prune them from the result). /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
