> On 18 Oct 2015, at 10:53, 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.
It is the role of RFC 6536 to make sure the extension is supported where necessary. On the other hand, other applications such as translation to DSDL schemas have nothing to do with NACM, so they can ignore the extension. 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/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
