Andy Bierman <a...@yumaworks.com> wrote: > On Wed, Aug 19, 2015 at 10:49 AM, Martin Bjorklund <m...@tail-f.com> wrote: > > > 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? > > > > > > > No -- I agree with Randy's interpretation of MAY. > > However, IMO description-stmts are normative, so if plain text in > the NACM RFC says the nacm YANG extensions MUST be supported, > then I think that makes it mandatory. > > YANG conformance does not make it mandatory. > > We are in agreement if you mean the RFC or module > containing the YANG extension can define the conformance for the extension.
Yes, maybe this is what I am trying to say. I guess I can't see how that would be possible if you insist that all extensions always are truly OPTIONAL. > But I don't agree that statements related to data handling and > datastores should ever be extensions. IMO NACM extensions > should really be YANG 1.1 keywords and the extensions should > be deprecated. I don't understand why you think that. We agree that it is ok for the RFC/module for NACM to defined the conformance for the nacm extensions (and this apparently work in multiple implementations), so why should these be proper statements? > I like YANG extensions -- they are like the minor leagues for YANG > statements. :-) > But once they are stable and there is consensus they are useful, they should > probably be made mandatory by converting them to regular statements. This is probably true in some cases, but I also like the idea of extensibility and modularity. It's a feature, not a bug, that we could define NACM w/o revising YANG. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
