On Sun, Oct 18, 2015 at 03:07:22PM +0200, Ladislav Lhotka wrote: > > > On 18 Oct 2015, at 10:53, Juergen Schoenwaelder > > <j.schoenwael...@jacobs-university.de> 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 < > >> j.schoenwael...@jacobs-university.de> 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. >
I am talking about implementation of data models. You all seem to be thinking about tools only or some intermediate formats. DSDL likely ignores descriptions - all fine with me. But an implementation of a data model I think is not allowed to simply ignore extensions (as it is not allowed to simply ignore descriptions). /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
