lada, See below.
On 12/15/2017 8:59 AM, Ladislav Lhotka wrote: > Hi, > > unfortunately, using an action for querying embedded YANG library data > (needed for the "inline" case of schema mount) doesn't work either > because now under NMDA actions can be used only on instances in the > <operational> datastore. but the inline/embedded library would (only) be present in the in the operational datastore, so what's the issue? > However, a good alternative seems to be a metadata annotation along the > lines of RFC 7952, for example with the alternative B of the newly > proposed YANG library schema: > > md:annotation schema-ref { > type leafref { > path "/yanglib:yang-library/yanglib:schema/yanglib:name"; > } > } > > In other words, all inline mounted schemas would be included in the > top-level YANG library, and mount point instances in all datastores > would be annotated with leafref pointing to the actual schema. > > Unlike regular state data, it is IMO no problem to permit such > annotations in configuration datastores. > > Opinions? I'm not sure this will work for all architectures of LNEs as well as other possible future use cases. In short, this seems *very* restrictive. Lou > > Thanks, Lada > > Ladislav Lhotka <lho...@nic.cz> writes: > >> Hi, >> >> the following text in sec. 3.2 of schema-mount-08 is wrong for traditional >> datastores, and even more so for NDMA: >> >> In case 1 ["inline"], the mounted schema is determined at run time: every >> instance of the mount point that exists in the parent tree MUST >> contain a copy of YANG library data [RFC7895] that defines the >> mounted schema exactly as for a top-level data model. A client is >> expected to retrieve this data from the instance tree, possibly after >> creating the mount point. Instances of the same mount point MAY use >> different mounted schemas. >> >> An instance of the mount point in any *configuration* datastores cannot >> contain >> YANG library (being state data), and so the MUST cannot hold. >> >> It is not clear to me how to repair this without considerable complications >> and/or a lot of handwaving. There is actually one good solution but it has >> impact on YANG library: the server could provide it in a reply to an >> operation, >> say "get-yang-library" rather than as state data. Then everything would be >> fine >> - this operation would turn into an action for the mount point, and it can be >> used equally well for config true and false mount points. >> >> So my proposal is to move from YANG library as state data to an operation. It >> could be done along with changing the YANG library structure, so there will >> be >> little extra impact on implementations. >> >> Lada >> >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod