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