On 02/05/2018 08:25, Martin Bjorklund wrote:
Andy Bierman <a...@yumaworks.com> wrote:
On Mon, Apr 30, 2018 at 7:09 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
Andy Bierman <a...@yumaworks.com> writes:
On Fri, Apr 27, 2018 at 8:13 AM, Ladislav Lhotka <lho...@nic.cz> wrote:
On Fri, 2018-04-27 at 16:47 +0200, Juergen Schoenwaelder wrote:
On Fri, Apr 27, 2018 at 04:34:38PM +0200, Ladislav Lhotka wrote:
[...] define a special datastore for it, such as "error-messages".
This seems worse than using, well, RFC 8040 yang-data. The proper
Why it seems worse?
Because this is not part of the NMDA.
NMDA is extensible.
If your only tool is a hammer, then all your problems look like nails.
I fail to see how an "error-messages" datastore fits in with NMDA
IMO, the yang-data defined in RFC 8040 has a clear purpose, and it
is sufficient for that purpose, which is a YANG representation of
an instance document (such as a protocol message or file).
The same is basically true even without the extension. For example, I
fail to see any benefit from using yang-data in a module like
ietf-zerotouch-information.
I don't see the benefit of pretending all data-def-stmts represent
configuration or operational data.
Wrapping the data-def-stmts in an extension says "this is not configuration
or operational data". This is useful for tools that can process YANG in
other contexts.
I fully agree
YANG already models RPCs, and 7950 makes it clear that the input/output
parameters of those RPC statements are not configuration or state and
are not modeled in datastores. I.e.:
Since the input tree is not part of any datastore, all "config"
statements for nodes in the input tree are ignored.
Since the output tree is not part of any datastore, all "config"
statements for nodes in the output tree are ignored.
Isn't the YANG data extension just modelling fragments of YANG to be
used in generic RPC messages?
This doesn't seem to be a fundamental change in YANG's scope, or
architecture.
Thanks,
Rob
YANG is useful for defining data structures that can be represented in
different formats, yet it is independent of any 1 format.
Of course I see this potential. Unfortunately, YANG spec was explicitly
written for a very specific context. Using an extension for removing
this specificity is IMO an ugly hack that undermines the architecture.
I don't see the architecture as fragile or damaged if yang-data is used.
People are going to continue to push the boundaries of YANG capabilities.
This will happen with or without the IETF.
Yes, and it already happens.
/martin
Maybe this work should remain
proprietary or get moved to an opensource project.
I am in favor if keeping the yang-data in RFC 8040 and not
creating a new version of it that is unconstrained.
There does not seem to be consensus on how to do this,
or even consensus that it is a good idea.
If the extension is deemed necessary, I would also prefer this approach
to making the extension a Proposed Standard.
Lada
Andy
clear solution for RPCs and actions would be to enable the definition
of error details right in the rpc/action definition (input, output,
error).
Agreed.
But something like yang-data seems to have uses in other contexts.
So other datastores may be defined. I assume that YANG library data can
be
used
independently, not just on a NC/RC server, pretty much along the lines
of
draft-
lengyel-netmod-yang-instance-data.
Lada
Andy
/js
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
