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