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