Robert Wilton <rwil...@cisco.com> wrote: > > > 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?
The primary use case is not "generic RPC messages", but standalone instance documents, error-info structures, etc. > This doesn't seem to be a fundamental change in YANG's scope, or > architecture. I agree. /martin > > 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
