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