Andy Bierman <a...@yumaworks.com> wrote: > On Wed, Aug 19, 2015 at 5:49 AM, Martin Bjorklund <m...@tail-f.com> wrote: > > > Hi, > > > > [joining this discussion a bit late] > > > > Ladislav Lhotka <lho...@nic.cz> wrote: > > > > > > > On 10 Aug 2015, at 18:46, Andy Bierman <a...@yumaworks.com> wrote: > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 9:37 AM, Ladislav Lhotka <lho...@nic.cz> > > > > wrote: > > > > > > > > > On 10 Aug 2015, at 17:32, Andy Bierman <a...@yumaworks.com> wrote: > > > > > > > > > > > > > > > > > > > > On Mon, Aug 10, 2015 at 4:24 AM, Ladislav Lhotka <lho...@nic.cz> > > > > > wrote: > > > > > > > > > > > On 10 Aug 2015, at 12:17, Andy Bierman <a...@yumaworks.com> 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). > > > > > > I strongly disagree with this change. > This would mean that every tool is required to support the > semantics of every extension ever defined.
No. It means that if a server advertises module that uses some extension to define some behaviour, the server supports that behavior. Just as we expect a server to support the text in description statements. For example, the nacm: extensions do not apply unless ietf-netconf-acm is advertised (and nacm is enabled). I expect most extensions to work this way. Another example is if we actually defined i2rs:ephemeral; this would have no effect unless the "i2rs" capability (whatever that is) is also advertised. The text also means that it is perfectly ok for a client to ignore the extension if it doesn't understand it. For example, if the client has no idea what the ephemeral datastore it, it doesn't matter that a node is marked with i2rs:ephemeral true. > For example, > we have our own extensions that cause the server to > perform internal tasks certain ways (like ywx:sil-delete-children-first). > > According to the text you propose, all servers would have to > provide the behavior embodied in the syntax of this extension > statement? Yes, all servers that advertise such a module. B/c as you note below it is "well-behaved". So the defintion probably says something like "if the server implements SIL, then it will delete the children before it deletes the node itself". > This extension does not alter any protocol behavior > at all, so it is "well-behaved". > > A server MAY skip over the entire extension and completely ignore it. > Other servers are not required to provide the behavior described > in the extension semantics. Yes. Aren't we in agreement here? /martin > > > > > 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 > > > > > Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod