On Sun, Oct 18, 2015 at 5:17 AM, Martin Bjorklund <[email protected]> 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. > > +1 Here is a concrete example -- the 'secret' leaf in the ietf-system module: http://www.netconfcentral.org/modules/ietf-system/2014-08-06#shared-secret.564 This is tagged as "nacm:default-deny-all". Does this mean that if an implementation supports the ietf-system "secret" leaf, it MUST also include an implementation of NACM? If yes, then Juergen is right. If no, then Randy's text is fine. But read the definition of "default-deny-all" carefully: http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#default-deny-all.74 Note the line: If present, and the NACM module is enabled (i.e., /nacm/enable-nacm object equals 'true'), Is the NACM module "enabled" leaf set to true in a server that does not implement NACM at all? I would say no. Note also that the extension does not define any behavior outside of NACM processing. It is not intended for every tool. It is only intended for an implementation of NACM. > > /martin > Andy
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
