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.
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 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.
> /martin
>
>
Andy
>
>
> >
> >
> >
> > > 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
