> On 17 Jun 2015, at 14:20, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> wrote: >> >>> On 17 Jun 2015, at 12:12, Martin Bjorklund <[email protected]> wrote: >>> >>> Ladislav Lhotka <[email protected]> wrote: >>>> Hi Martin, >>>> >>>> thanks for the review. >>>> >>>> Martin Bjorklund <[email protected]> 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. Lada > >> A conclusion of this may be that it makes no sense to define >> annotations through YANG extension after all. > > No I think this is the right way to do it. > > > /martin > >> On the other hand, I do >> see a value of having annotations defined in YANG modules. >> >> Lada >> >> >>> >>> (I also note that your requirement lists: >>> >>> 2. Syntax and semantics of annotations must be documented and the >>> documentation must be easily accessible. >>> ) >>> >>> >>> But I also don't want this document to go into all details of how >>> different annotations can be used; this needs to be carefully designed >>> for each annotation. >>> >>> I suggest something like this: >>> >>> OLD: >>> >>> By advertising a YANG module in which metadata annotation A is >>> defined using the "md:annotation" statement, a server specifies >>> support for the syntax of annotation A. This means that >>> configuration or state data, RPC messages and notifications will be >>> considered syntactically valid if annotation A is attached to any >>> data node instance, provided that all rules stated in this document >>> are observed. >>> >>> However, the semantics of an annotation, usage rules, and expected >>> behavior of clients and servers MUST be specified separately by other >>> means that are outside the scope of this document. >>> >>> NEW: >>> >>> By advertising a YANG module in which metadata annotation A is >>> defined using the "md:annotation" statement, a server specifies >>> support for the syntax and semantics of annotation A. This means that >>> configuration or state data, RPC messages and notifications will be >>> considered syntactically valid if annotation A is attached to any >>> data node instance, provided that all rules stated in this document >>> are observed. >>> >>> >>> and >>> >>> OLD: >>> >>> A server announces syntactic support for a particular >>> annotation by including the module in which the annotation is >>> defined among the advertised YANG modules (e.g., in NETCONF >>> hello message). >>> >>> Semantics and usage rules for an annotation MUST be specified >>> separately. The 'description' and/or 'reference' statements >>> SHOULD provide corresponding links. >>> >>> NEW: >>> >>> A server announces support for a particular >>> annotation by including the module in which the annotation is >>> defined among the advertised YANG modules (e.g., in NETCONF >>> hello message). >>> >>> >>> >>> >>> /martin >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
