> On 29 Jul 2015, at 14:57, Martin Bjorklund <[email protected]> wrote: > > Ladislav Lhotka <[email protected]> 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. > > The reason that the text about MAY ignore is there was to allow a tool > like pyang to function even if it finds an extension like yuma:root in > a model. pyang doesn't "understand" this extension, yet it can > process the module.
I think this is unnecessary. After all, I can write a tool that ignores everything in a module except the module name, so what? Is that tool illegal? RFC 2119 keywords should be primarily used where it matters to interoperability, i.e. client/server contract. > > I like Juergens analogy with text in the description statement - you > can write any rules in the description statement, or you can choose to > formalize it in an extension. Sometimes such rules are directed to a > client, sometimes to a server, sometimes to the YANG compiler > (e.g., code generation directives), and sometimes to humans reading > the module. But in order to determine whether a given extension is directed to a piece of software, I need to know the semantics of that extension. If I have no idea what yuma:root means, it may not be safe to ignore it. I think it is important to understand that all extensions in the data model advertised by the server are an integral part of the model. If an implementation or tool ignores an extension because it’s of no interest to it, then OK but it’s the implementor’s responsibility. Lada > > > /martin > > >> 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. >> >>> >>>>> 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. >> >> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
