> On 29 Jul 2015, at 16:14, Juergen Schoenwaelder > <[email protected]> wrote: > > On Wed, Jul 29, 2015 at 02:24:03PM +0200, Ladislav Lhotka wrote: >> >>> On 29 Jul 2015, at 13:47, Juergen Schoenwaelder >>> <[email protected]> wrote: >>> >>> On Wed, Jul 29, 2015 at 12:57:09PM +0200, Ladislav Lhotka wrote: >>>> >>>>> On 29 Jul 2015, at 12:25, Juergen Schoenwaelder >>>>> <[email protected]> wrote: >>>>> >>>>> On Wed, Jul 29, 2015 at 09:34:17AM +0200, Martin Bjorklund wrote: >>>>>> Hi, >>>>>> >>>>>> Andy Bierman <[email protected]> wrote: >>>>>> >>>>>>> I do not agree that YANG extensions should be used for IETF standards >>>>>>> track >>>>>>> modules. >>>>>> >>>>>> I strongly disagree. This was one of the two original ideas behind >>>>>> extension statements (the other was that vendors could add their own >>>>>> stuff). >>>>> >>>>> An extension defines certain semantics. For example: >>>>> >>>>> extension default-deny-write { >>>>> description >>>>> "Used to indicate that the data model node >>>>> represents a sensitive security system parameter. >>>>> >>>>> If present, and the NACM module is enabled (i.e., >>>>> /nacm/enable-nacm object equals 'true'), the NETCONF server >>>>> will only allow the designated 'recovery session' to have >>>>> write access to the node. An explicit access control rule is >>>>> required for all other users. >>>>> >>>>> The 'default-deny-write' extension MAY appear within a data >>>>> definition statement. It is ignored otherwise."; >>>>> } >>>>> >>>>> If a data model writer uses an extension, then the semantics >>>>> associated with the extension are embedded in the data model. The >>>>> extension can be seen as a shorthand for copying the semantics >>>>> directly into the description clause. In other words, an >>>> >>>> The difference is that YANG spec doesn’t say descriptions may be ignored. >>> >>> I do not get it, please help me. >> >> A client that ignores constraints expressed in a description statement >> should be considered broken. I am not sure it is also the case for a client >> that ignores an extension and the implied semantics, because sec. 6.3.1 >> seems to allow it. >> >> In fact, I think it can be applied to the server, too: An implementor may >> take a module, remove extensions he doesn’t want to implement (or let a >> “compiler” remove them) and implement the modified form of the module. >> > > As I tried to explain, I believe there is confusion between a tool > skipping over an extension statement and the semantics that are > applied to the data model. The text in 6.3.1 talks about the tool > (the 'compiler'). > >>>>> implementation has to implement the semantics no matter which >>>>> tool is used. >>>> >>>> I agree, but then I think the text you have in PS should be removed >>>> entirely. There is again the issue of old client support that IMO doesn’t >>>> hold water anyway: a client that doesn’t fully understand the semantics of >>>> the data model cannot be guaranteed to work, and is in fact dangerous. >>>> >>> >>> Again, I do not get it. There are non-machine readable semantics >>> anyway. A decent client better understands the semantics - otherwise >>> it is just a clueless yang browser. So why is there a problem with >>> extension statements (which are just a shorthand for semantics that >>> happen to be machine readable for those tools that are programmed to >>> read and understand them). >> >> As I said, it is unclear (to me at least) from the text in 6.3.1 whether >> extensions are an integral part of the contract expressed by the module. If >> I had a contract with an insurance company saying “Anybody who cannot read >> fine print may ignore it”, I would get quite nervous. > > I believe this is a mis-interpretation of the text in 6.3.1. and I > tried to propose new text that hopefully clarifies this. You agree > with the proposed text?
The first part about parser behaviour still doesn’t make much sense to me and may be misinterpreted. I think that even a parser that does understand an extension may ignore it. It all depends on what the parser output is used for. I would just say (somewhere) that descriptions and extensions are integral and binding parts of the data model. Unless I missed something, it is not clearly stated for descriptions either. Lada > > /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
