Hello, I would like to keep simplified inline. If I ask my developers (not experts) which one do they want? I am pretty sure they opt for the shorter/simpler one. <module>ietf-netconf-acm@2018-02-14<module>
OR
<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>
Regards Balazs
-----Original Message-----
From: Rob Wilton (rwilton) <rwil...@cisco.com>
Sent: 2021. július 8., csütörtök 12:59
To: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>; Balázs
Lengyel <balazs.leng...@ericsson.com>
Cc: Andy Bierman <a...@yumaworks.com>; netmod@ietf.org; Benoit Claise
<benoit.cla...@huawei.com>
Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format
Hi Juergen,
I believe that having the simple form is worth the extra complexity.
I think that you are right to be concerned that it should not expand into a
separate parallel format. Overtime, I would like the simple form to be able
to use revision labels instead of revision dates, but beyond this I think
that it should just be a flat list of modules that defines the schema. If a
subset of features, or datastores, or import-only modules are needed then
the YANG library version (or URIs) can and should be used.
Another example of where I expect it to be useful is in YANG packages.
Looking at the examples at the end of
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then
some of those files (which currently aren't defining any schema, but should)
would almost double in size if they represented the schema inline using YANG
library, which I think would make the files harder for humans to read/parse.
Using URIs could help mitigate this, but then we would need to find a place
to publish the file containing the YANG package schema (presumably somewhere
in IANA), and it not obvious to me that adding the dependency on the URL is
really as helpful.
Regards,
Rob
> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
> Sent: 08 July 2021 11:35
> To: Balázs Lengyel <balazs.leng...@ericsson.com>
> Cc: Andy Bierman <a...@yumaworks.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
>
> 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://protect2.fireeye.com/v1/url?k=7edafb8e-2141c2bf-7edabb15-86e2237f51
fb-eceadf4f1dc08461&q=1&e=09140141-b70c-44c9-9909-048d736efebf&u=https%3A%2F
%2Fwww.jacobs-university.de%2F>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
