Juergen Schoenwaelder je 3.8.2015 ob 10:18 napisal:
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.
Why not simply make this impossible by ensuring that description
statements cannot change what has already been agreed upon in RFC6020
(aka YANG semantics)? I would have no problem with descriptions being
normative, if this would be the case.
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 still disagree that description statements should be more powerful
than any other YANG statement.
I think the NACM extensions are just fine as
they are. I do not see anything broken about them.
I agree. Both NACM extensions and "annotation" are examples of what the
best practice for extension usage should be. Standardize first, then
use. I don't mind implementing something (in a generic client) that was
widely agreed to be useful. There are cases like this for other
languages. EXSLT for XSLT, for example. In time, extensions should
become proper YANG keywords.
FWIW, I prefer #2, since that is how I always understood YANG
extensions. Don't mind #1 for standard extensions only.
Jernej
/js
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
