The question I asked is "how much simpler is it and does that saving
justify the introduction of a new rather limited format (that may risk
to grow over time and become a second citizen)".
So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports
from ietf-yang-types (at the time of publication that resolves to
ietf-yang-types@2013-07-15. So the YANG Library instance data would
roughly look this (please correct what I messed up, I am writing this
by hand):
<yang-library>
<module-set>
<name>m</name>
<module>
<name>ietf-netconf-acm</name>
<revision>2018-02-14</revision>
<namespace>uri1</namespace>
</module>
<import-only-module>
<name>ietf-yang-types</name>
<namespace>uri2</namespace>
<revision/>
</import-only-module>
</module-set>
<schema>
<name>s</name>
<module-set>m</module-set>
</schema>
<datastore>
<name>running</name>
<schema>s</schema>
</datastore>
</yang-library>
Yes, this is a bit longer, but it also conveys more information (note
that your datastore leaf in the header would likely not be needed
anymore).
I am concerned that we start creating another format to define schemas
that is very limited and people later come with extension proposals to
address some of the limits and at the end we have multiple formats to
maintain and deal with. So the question is whether people think this
is worth it. (Note that the felt overhead goes down with every
additional module used by your instance file, so the example above is
really the most extreme case. And if you have many modules defining
NACM rules, then you put the above into a separate file and use the
URI to point to the schema, no?
/js
On Thu, Jul 08, 2021 at 09:27:52AM +0000, Balázs Lengyel wrote:
> Hello Jurgen,
> Inline:
> This complex form of inline was requested and not objected earlier by other
> reviewers.
> Based on Rob's and others' proposal inline will be simplified to use only
> ietf-yang-library@2019-01-04 as you suggest.
>
> Simplified inline:
> In Ericsson we already use simplified inline a lot, it is the most common
> format.
> If you are providing data only for one or a few YANG modules and don't have,
>
> don't care about features/deviations it is the easiest, shortest method to
> use.
> Our most common use-case is to provide preconfigured access control rules
> for new nodes.
> When a YANG modeler designs a new module, he immediately provides a set of
> NACM rules
> for the readOnly and the SystemAdmin roles/groups.
> In this case you only need to specify "ietf-neconf-acm@2012-02-22" No
> deviations, no features to indicate.
> Regards Balazs
>
> Regards Balazs
>
> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
> Sent: 2021. július 7., szerda 21:26
> To: Andy Bierman <a...@yumaworks.com>
> Cc: Balázs Lengyel <balazs.leng...@ericsson.com>; Rob Wilton (rwilton)
> <rwil...@cisco.com>; netmod@ietf.org; Benoit Claise
> <benoit.cla...@huawei.com>
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
>
> On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> >
> > > Inline method is needed, if you want to indicate that the file was
> > > generated by someone who uses some YANG modules with deviations and
> > > some features are not-supported. There is no way to indicate
> > > feature-support and deviations with the simplified-inline method.
> >
> > The Inline anydata solution is very heavyweight.
> > Before the YANG library there was a simple URI that is easier to use
> > and takes up much less storage.
> >
>
> The inline content schema is super generic since it supports an open ended
> set of schema defining modules. While you can use it with say
> ietf-yang-library@2019-01-04, you can use anything else as well. In other
> words, two implementations supporting inline content schema may not
> interoperate. I do not think there is a schema format that is mandatory to
> implement for inline content schema.
>
> So here is my assessment of what we have in terms of interoperability:
>
> - Simplified-Inline comes with notable restrictions, interoperable
> - Inline is an open ended content schema, not necessarily interoperable
> - URI method pushes the problem to another instance file, interoperable
> - External is by desing not interoperable
>
> On the server side, we have YANG Library. Perhaps RFC 8525 has some
> complexity that is useful for supporting large servers with multiple
> datastores and not needed for small instance files (I understand that an
> instance file is always tied to a single datastore?).
>
> To me, it feels that reusing RFC 8525 design is actually a good thing. Being
> able to dump a live server datastore into an instance file seems like a very
> valid use case to me and ideally this is possible without having to rewrite
> the schema part. Well, you could go and trim unused datastore schemas and
> from there unused module sets etc but that can all be done by an external
> tool trimming the schema part, i.e., it does not need to be done by a tool
> that just dumps a server datastore.
>
> What is the actual value of simplified inline? How much do you really save
> compared to the simplest equivalent RFC 8525 representation? And does that
> saving justify to start engineering another schema specification format?
>
> I guess my choice would have been to just have
>
> +-- content-schema
> | +-- (content-schema-spec)?
> | +--: (yang-library)
> | +--: (uri)
>
> but others obviously want much more choice (but lets note that everything
> sits in a choice, so everything is extensible in case other schema
> definition formats are out there).
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103
> <https://protect2.fireeye.com/v1/url?k=fe85c8e6-a11ef1cd-fe85887d-866038973a
> 15-19e5dad375af0063&q=1&e=3637406d-f774-4073-80ee-a7431111e9bc&u=https%3A%2F
> %2Fwww.jacobs-university.de%2F>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
