On Mon, Aug 03, 2015 at 09:22:48AM +0200, Ladislav Lhotka wrote:
> Andy Bierman <a...@yumaworks.com> writes:
>
> > On Fri, Jul 31, 2015 at 8:37 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> >
> >>
> >> > On 31 Jul 2015, at 16:54, Andy Bierman <a...@yumaworks.com> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Jul 31, 2015 at 5:45 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
> >> >
> >> > > On 31 Jul 2015, at 14:40, Andy Bierman <a...@yumaworks.com> wrote:
> >> > >
> >> > >
> >> > >
> >> > > On Fri, Jul 31, 2015 at 1:12 AM, Ladislav Lhotka <lho...@nic.cz>
> >> wrote:
> >> > > Martin Bjorklund <m...@tail-f.com> writes:
> >> > >
> >> > > > Andy Bierman <a...@yumaworks.com> wrote:
> >> > > >> On Thu, Jul 30, 2015 at 10:41 AM, Martin Bjorklund <m...@tail-f.com>
> >> wrote:
> >> > > >>
> >> > > >> > Andy Bierman <a...@yumaworks.com> wrote:
> >> > > >> > > On Wed, Jul 29, 2015 at 10:51 AM, Martin Bjorklund <
> >> m...@tail-f.com>
> >> > > >> > wrote:
> >> > > >> > >
> >> > > >> > > > Andy Bierman <a...@yumaworks.com> wrote:
> >> > > >> > > > > Hi,
> >> > > >> > > > >
> >> > > >> > > > > I understand the intent is that an implementation of NACM
> >> > > >> > > > > has to understand these NACM extensions. I agree with Lada
> >> > > >> > > > > that the YANG text about MAY ignore extensions casts doubt
> >> whether
> >> > > >> > > > > this sort of NACM rule is enforceable or specified
> >> correctly.
> >> > > >> > > >
> >> > > >> > > > So do you agree that it would be a good idea to clarify this
> >> > > >> > > > according to Juergen's suggestion?
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > Not really.
> >> > > >> > > Pretending the extension is just another description-stmt
> >> > > >> > > does not really fix anything.
> >> > > >> > >
> >> > > >> > > A real YANG statement like config-stmt or a new statement
> >> > > >> > > called ephemeral-stmt can be modified with refine-stmt
> >> > > >> > > or deviate-stmt. This can never happen for
> >> > > >> > > an external statement.
> >> > > >> >
> >> > > >> > There are two separate issues here:
> >> > > >> >
> >> > > >> > 1) It seems we are in agreement that if a model uses an extension
> >> > > >> > statement, it is normative (like ietf-system's usage of
> >> nacm:*).
> >> > > >> >
> >> > > >> > Should we somehow clarify this in 6020bis?
> >> > > >> >
> >> > > >> > 2) Extensions cannot be refined or deviated.
> >> > > >> >
> >> > > >> > Actually, the *syntax* rules allows things like:
> >> > > >> >
> >> > > >> > deviation /x:foo {
> >> > > >> > deviate replace {
> >> > > >> > i2rs:ephemeral true;
> >> > > >> > }
> >> > > >> > }
> >> > > >> >
> >> > > >> > I agree that it not clear what this means, but we could also
> >> > > >> > clarify this in 6020bis.
> >> > > >> >
> >> > > >> >
> >> > > >>
> >> > > >> But this will take even longer than just defining the statements
> >> that
> >> > > >> are needed for ephemeral state, so no point in doing that.
> >> > > >>
> >> > > >> The text in 7.18.3.2 clearly does not support the example above at
> >> all.
> >> > > >
> >> > > > The grammar allows extensions everywhere, so the example is (as I
> >> > > > wrote) syntactically valid.
> >> > > >
> >> > > >> Only one of the keywords listed in the table are supported.
> >> > > >
> >> > > > The text doesn't say so, and anyway my point was that - regardless of
> >> > > > the outcome of the ephemeral dicussion - it might be a good a idea to
> >> > > > clarify that extensions can be deviated as well.
> >> > >
> >> > > +1
> >> > >
> >> > >
> >> > > So you are saying that a tool MAY ignore any extension, except
> >> > > inside a deviation-stmt? Then it becomes mandatory to support?
> >> > >
> >> > > Or do you mean:
> >> > >
> >> > > Yes you can put extension-stmts anywhere, but also, yes the tool
> >> > > MAY ignore every single extension (everywhere, including inside a
> >> > > deviation-stmt)
> >> >
> >> > I understood Martin’s proposal so that a device that doesn’t support an
> >> extension used in modules it advertises will have to put it in a
> >> “not-supported” deviation.
> >> >
> >> >
> >> > So features are all "not-supported" by default. but extensions,
> >> > which a tool MAY ignore, are all supported by default?
> >>
> >> I proposed to remove this “MAY ignore” text.
> >>
> >
> >
> > I do not support this change
> >
>
> The current "MAY ignore" formulation is unclear, and it doesn't matter
> whether it talks about compilers, parsers or tools.
>
> The problem with extensions is that they can mean virtually anything –
> in particular, they can change semantics of YANG or the management
> protocol.
Any description statement in principle can do this. We trust that sane
data model writers won't do bad things. And if they do, we hope that
people will not implement and deploy bad things.
> I think there are two possible approaches:
>
> 1. Treat all extensions appearing in the server's data model as
> mandatory parts of data model or protocol semantics.
>
> 2. Make extensions truly optional and irrelevant from the point of view
> of YANG language.
>
> With #1, a client that doesn't understand all extensions the server uses
> SHOULD terminate the session, because there are no means for negotiating
> support for extensions one by one.
>
> I am afraid this could have disastrous consequences for
> interoperability: we would have silos where servers only work with
> clients of the same provenience.
>
> #2 is what RELAX NG does: elements and attributes from foreign
> namespaces are allowed in a schema but they cannot affect the notion of
> RELAX NG validity because the specification of the validation procedure
> says: "Foreign attributes and elements are removed."
>
> With #2, protocols such as I2RS can still define their extensions
> provided that
>
> - there is some way for making sure that both the server and client
> understands it,
>
> - it doesn't affect servers and clients of other protocols, so they may
> safely ignore it.
>
> I would personally vote for #2, but then the NACM stuff or the
> "annotation" statement really cannot be extensions.
I continue to see extension statements as reusable and (in principle)
machine readable fragments of description statements. From this
perspective, it seems odd to make a difference between extensions and
description statements. I think the NACM extensions are just fine as
they are. I do not see anything broken about them.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
