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