On Fri, Jul 9, 2021 at 1:58 AM Balázs Lengyel <[email protected]> wrote:
> Hello Andy, > > In the name of simplification, I will add the following to the URI method: > > > > Referenced files using "inline" or the "simplified-inline" methods MUST > be supported. > > Referenced files using the "URI method" MAY be supported. > > > This is a good compromise. Although it may seem that mandating everything will increase interoperability, it actually has the opposite effect. Companies decide to implement everything, but "in phases". This is code for "phase 1 will implement the parts we need. Phase 2 will never happen." There is plenty of implementation experience with the first 2 methods, and good reason to think they will be supported. The draft details for the URI method clearly lack any meaningful implementation feedback. There are so many problems with this approach, especially for the reader. Storing passwords in cleartext is just the easiest to spot. > This means the tool does not need to be prepared for chains or loops. I > think chains and loops are something we should discourage. > > (Referenced files using the “external Method” make no sense anyway. If I > don’t tell you the schema of the referenced file, there is no sense in > referencing them) > One purpose of a standard is to assign blame when it doesn't work. If the writer generates a series of URIs that form a loop, then the reader will not be able to find the file that has the Simplified Inline or Inline info. That is clearly the fault of the writer, not the reader. Regards Balazs > Andy > > > *From:* netmod <[email protected]> *On Behalf Of *Balázs Lengyel > *Sent:* 2021. július 9., péntek 9:39 > *To:* Andy Bierman <[email protected]>; Rob Wilton (rwilton) < > [email protected]> > *Cc:* [email protected] > *Subject:* Re: [netmod] AD review of > draft-ietf-netmod-yang-instance-file-format > > > > Hello Andy, > > See below. > > Balazs > > > > *From:* Andy Bierman <[email protected]> > *Sent:* 2021. július 8., csütörtök 18:55 > *To:* Rob Wilton (rwilton) <[email protected]> > *Cc:* Juergen Schoenwaelder <[email protected]>; > Balázs Lengyel <[email protected]>; [email protected]; Benoit > Claise <[email protected]> > *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > > > On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) <[email protected]> > wrote: > > Hi Juergen, > > I believe that having the simple form is worth the extra complexity. > > > > > > I believe it is the only option that does not have too much complexity. > > > > The inline form seems to imply that the NMDA version of the YANG library > is used. > > Only 1 module set is ever shown, but of course the actual schema allows > > for much more complex instances than that, which the reader must support. > > > > Does this mean NMDA must be used or else a YANG data file cannot be saved? > > So the reader is expected to look for the 'current' /yang-library and then > the 'deprecated' /modules-state? > > And then fish the anydata for whatever non-standard solution is in use? > > The procedures should be explained better so there is a better chance of > interoperability. > > BALAZS: No NMDA is not required. If it would there would be a clear > statement about it. Even in section 2.2.1. Documentation of server > capabilities the new (NMDA compatible) yang-library is used, but the simple > (non- NMDA) modules-state branch. > > > > For the URI method, the reader must check for a broken chain of reference > and loops. > > The draft should say the uri references across N files MUST NOT create a > loop > > (similar language is in YANG wrt import loops). > > BALAZS: Someone (don.t know who) asked for longer reference chains. > However, I don’t see them as a common use-case. IMHO the most common > use-case for the URI method will be, when the consumer knows the > content-schema apriori, it only needs a reference to check that the schema > is what it expected. > > > > For conformance purposes, I think YANG features are appropriate. > > IMO simplified-inline is mandatory-to-implement but the rest should > > be optional. This way a tool can claim conformance and also the standard > > will provide a minimum level of interoperability. > > BALAZS: There are very different views about the preferred/required > methods. Also the needs of different use-cases are different. That’s why we > need all 3. > > > > > > Andy > > > > > > > > > > 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. > > > > This can be done with augment if and when the versioning draft reaches RFC > > > > 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 <[email protected]> > > Sent: 08 July 2021 11:35 > > To: Balázs Lengyel <[email protected]> > > Cc: Andy Bierman <[email protected]>; Rob Wilton (rwilton) > > <[email protected]>; [email protected]; Benoit Claise > > <[email protected]> > > 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 <[email protected]> > > > Sent: 2021. július 7., szerda 21:26 > > > To: Andy Bierman <[email protected]> > > > Cc: Balázs Lengyel <[email protected]>; Rob Wilton (rwilton) > > > <[email protected]>; [email protected]; Benoit Claise > > > <[email protected]> > > > 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 > <https://protect2.fireeye.com/v1/url?k=fe25a02c-a1be992c-fe25e0b7-86fc6812c361-d087929e1674b3a3&q=1&e=198aaef7-64f6-438e-b4c8-3c84f231abe4&u=http%3A%2F%2F2fwww.jacobs-university.de%2F> > %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/ > <https://protect2.fireeye.com/v1/url?k=ebc4e571-b45fdc71-ebc4a5ea-86fc6812c361-21325e0a2fa737df&q=1&e=198aaef7-64f6-438e-b4c8-3c84f231abe4&u=https%3A%2F%2Fwww.jacobs-university.de%2F> > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
