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
