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://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
