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). > 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 > > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
