Hi, [joining this discussion a bit late]
Ladislav Lhotka <[email protected]> wrote: > > > On 10 Aug 2015, at 18:46, Andy Bierman <[email protected]> wrote: > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <[email protected]> > > wrote: > > > > > On 10 Aug 2015, at 17:32, Andy Bierman <[email protected]> wrote: > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <[email protected]> > > > wrote: > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman <[email protected]> wrote: > > > > > > > > Hi, > > > > > > > > I am strongly against changing the contract on extensions. > > > > They MAY be ignored by any YANG tool. Period. > > > > That means they are far from mandatory. > > > > They are little more than a keyword and a description clause. > > > > > > So do you prefer my proposed solution -02 or -03? > > > > > > ** Solution Yxx-03 > > > > > > Make extensions optional. This means that extensions won't be > > > allowed to change YANG language, NETCONF protocol, and validity of > > > datastores and protocol messages. > > > > > > > > > This is how we use extensions to tag YANG data models > > > to drive automation tools. > > > > But that means, for example, that annotations cannot be defined via an > > extension statement as in draft-ietf-netmod-yang-metadata. > > > > > > > > Which means these statements should be real instead of extensions. > > If the statements are defining data that is exchanged between > > peers in a standard protocol, then YANG extensions are not > > appropriate. > > I agree, and -03 is my preferred solution, too. I strongly disagree. IMO the IETF usage of extensions so far (NACM, annotations) works well (in the case of NACM proven by multiple independent implementations), and follows how extensions were intended to be used, and obviously, how the WG has understood them up until now. If the sentence: If a YANG compiler does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 12), the entire unknown-statement MAY be ignored by the compiler. in 6020 can be interpreted to mean that an occurance of an extension is non-normative, we should fix it so that it matches what was intended and how it is used. Juergen suggested this replacement text, which I support. Maybe it can be improved even more. If a YANG parser does not support a particular extension, which appears in a YANG module as an unknown-statement (see Section 13), the entire unknown-statement MAY be ignored by the parser. Note that even in this case the semantics associated with the extension still apply (as if they were part of a description statement). However, I do agree that an extension cannot "undo" semantics defined by other YANG statements, just as you cannot do that in a description statement. For example, this would be illegal: leaf foo { type int32; description "The type is really a string."; } leaf bar { type int32; xx:real-type string; } It is also a Very Bad Idea (speaking from experience...) to define an extension that introduces new data nodes. The text about "MAY ignore" was meant to capture this. It's supposed to be like for a client that doesn't understand an augemntation; it can skip it. A client that doesn't understand nacm:default-deny-all works just fine and can safely ignore it. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
