> 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. 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. 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. 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
