On Wed, Apr 25, 2018 at 10:53 PM, Ladislav Lhotka <lho...@nic.cz> wrote:
> Ladislav Lhotka <lho...@nic.cz> writes: > > > On Wed, 2018-04-25 at 08:04 -0700, Andy Bierman wrote: > >> > >> > >> On Wed, Apr 25, 2018 at 7:05 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > >> > On Wed, 2018-04-25 at 15:55 +0200, Juergen Schoenwaelder wrote: > >> > > On Tue, Apr 24, 2018 at 04:36:01PM +0200, Martin Bjorklund wrote: > >> > > > Ladislav Lhotka <lho...@nic.cz> wrote: > >> > > > > Martin Bjorklund <m...@tail-f.com> writes: > >> > > > > > >> > > > > > Hi, > >> > > > > > > >> > > > > > I am not sure what this statement tells us re. the issue in > this > >> > email > >> > > > > > thread. > >> > > > > > >> > > > > It tells us that, in my view, the approach taken in this > document is a > >> > > > > bad idea. > >> > > > > >> > > > Do you mean that the WG shoud drop this document? And people that > >> > > > need yang-data should continue to use the version in 8040? Or > that > >> > > > people that need yang-data do not have a valid use case and they > >> > > > should do something else? > >> > > > >> > > One option is that people use yang-data as defined in RFC 8040 until > >> > > >> > IMO, people should use plain YANG. With the new YANG library it will > be > >> > possible > >> > to confine such non-NM schemas in a special datastore so that the > intention > >> > should be clear and multi-module schemas with all the additional data > >> > (versions, > >> > features, deviations) can be used. > >> > > >> > >> I don't see how yang-data interferes with "plain YANG" at all. > >> It is for data that is not in scope for plain YANG. > > > > My question is why this extension is needed in the first place. > > For example, RFC 8040 could have used two modules instead of > "ietf-restconf", one with the contents of grouping "errors" and the > other with the contents of grouping "restconf". No extension. > > This is true. We used to do this before yang-data was available. > What would be wrong with this solution? Instead, the reader is > overwhelmed with the complexity of the "yang-data" definition, and most > tools cannot process the module. > There are tools that can use yang-data. Not all use-cases involve a server to query for a yang-library. Offline tools need to know about the special data somehow. The yang-data extension prevents data-def-stmts from being treated as if they were configuration or operational data. I agree with you that unconstrained use of yang-data is questionable for a standard extension. The bar should be that all tools which choose to implement the extension should provide the user with the same behavior. Declaring that behavior out-of-scope does not help interoperability at all. > Lada > > Andy > > > >> A plain client can ignore yang-data and not affect and RPC, > notification, or > >> data > >> definitions in plain YANG. > > > > A plain (NC/RC) client should never see such data even if it is not > protected by > > yang-data in YANG. On the other hand, tools will be able to process such > schemas > > (generate the ascii tree, convert it to something else, generate sample > > instances etc.) without explicitly supporting yang-data. > > > > Lada > > > >> > >> > >> > Lada > >> > > >> > >> Andy > >> > >> > > there is a version of YANG that has a proper and complete integrated > >> > > solution. (If for example yang-data is used to declare error content > >> > > for RPCs, then more extensions are needed or a proper integration > into > >> > > YANG. Is it really good to introduce augment-yang-data (instead of > >> > > making augment work with say 'data' in YANG 1.2)? And then we do > >> > > uses-yang-data etc. > >> > > > >> > > /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 > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
