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. 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? 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.
> 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
