Juergen Schoenwaelder <[email protected]> wrote: > On Sun, Oct 18, 2015 at 02:17:46PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder <[email protected]> wrote: > > > On Sun, Oct 18, 2015 at 01:50:12AM -0700, Andy Bierman wrote: > > > > On Sun, Oct 18, 2015 at 1:31 AM, Juergen Schoenwaelder < > > > > [email protected]> wrote: > > > > > > > > > On Sat, Oct 17, 2015 at 07:49:06PM -0700, Randy Presuhn wrote: > > > > > > Hi - > > > > > > > > > > > > > From: Andy Bierman > > > > > > > Sent: Oct 17, 2015 10:42 AM > > > > > > ... > > > > > > > Subject: Re: [netmod] 6020bis extensions > > > > > > ... > > > > > > > > > > > > Andy Proposed: > > > > > > > > > > > > > If a YANG parser does not support a particular extension, which > > > > > > > appears in a YANG module as an unknown-statement (see Section > > > > > > > 14), > > > > > > > the entire unknown-statement MAY be ignored by the parser. > > > > > > > Note that > > > > > > > this only applies to a generic YANG parser. A tool which is > > > > > > > required > > > > > > > to implement the particular extension MUST NOT ignore such an > > > > > > > unknown-statement. > > > > > > > > > > > > I'd suggest a slightly different wording: > > > > > > > > > > > > The processing of extensions depends on whether support for those > > > > > > extensions is claimed for a given YANG parser or the tool set in > > > > > > which it is embedded. An unsupported extension, appearing in a > > > > > > YANG module as an unknown-statement (see Section 14) MAY be > > > > > > ignored in its entirety. Any supported extension MUST be > > > > > > processed > > > > > > in accordance with the specification governing that extension. > > > > > > > > > > > > > > > > I am not happy with either of these. It is important for me to state > > > > > that the semantics associated with an extension statement apply, > > > > > irrespective of the tool being used to implement a module. You can't > > > > > simply ignore nacm:default-deny-write just because your tool skipped > > > > > over this extension statement. So what about this: > > > > > > > > > > If a tool does not support a particular extension, which appears in > > > > > a YANG module as an unknown-statement (see Section 14), the entire > > > > > unknown-statement MAY be ignored by the tool. Irrespective of this, > > > > > the semantics associated with an extension MUST be implemented > > > > > whenever an extension statement appears in a YANG module. > > > > > > > > I like Randy's text. I don't really think any text is needed, > > > > because the differences between "conformance to YANG" > > > > and "conformance to a module written in YANG" are quite clear to me. > > > > There is no way that all tools have to support some vendor extension > > > > that is intended for 1 proprietary tool. > > > > > > I dislike Randy's text since it essentially says you can ignore any > > > extensions such as nacm:default-deny-write - all you have to claim is > > > that your tool does not support it. > > > > I think it *is* ok to ignore this statement for a server that doesn't > > implement NACM. I think Randy's text is fine. > > I disagree with the idea that extensions can be ignored arbitrarily > just because a tool did skip over them. I thought we agreed that > nacm:default-deny-write can't be ignored (if you implement NACM). ^^^^^^^^^^^^^^^^^^^^^
Absolutely! It seems we agree on the idea, but not the words to describe this. > I actually think it is up to the extension to define when and how it > applies. The definition of nacm:default-deny-write actually does say > when it applies. Agreed. /martin > I could copy the text of the nacm:default-deny-write description > verbatim into the description of every object marked with > nacm:default-deny-write. Using an extension is just a shorthand for > this (with the added bonus that it is machine readable for tools). I > do not think such an extension can be arbitrarily ignored just because > a certain tool skipped over it. > > /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
