On Mon, May 9, 2016 at 6:27 AM, Martin Bjorklund <[email protected]> wrote:
> Andy Bierman <[email protected]> wrote: > > On Thu, May 5, 2016 at 7:44 AM, Balazs Lengyel < > [email protected]> > > wrote: > > > > > Hello, > > > > > > 1) Will mounted YANG modules be listed in the base ietf-yang-library? > Even > > > the mounted ones? > > > > > > > Does the server providing the mounted modules claim conformance > > to those models? > > No, which is why they are not listed in the base ietf-yang-library. > > > IMO YANG mount breaks the "YANG API contract" if even 1 tiny > > property is ignored, due to mounting. > > Agree. > > > I asked for a conformance enum of 'none' or 'other' for this exact > purpose > > but > > the WG did not think it was possible for a server to do anything > > other than implement or import a YANG module. > > > > E.g, we are building a special server "library-mode" that just > > provided\s the library and get-schema for every module. > > They will all be listed as 'imported' (so that enum essentially > > becomes 'other') > > > > > > > 2) What does conformance to a YANG module e.g. ietf-system mean now? > Do we > > > need to load the module at the top level, or is it enough to mount it > > > “somewhere” in the containment tree? > > > > > > > > > It means the same if the server returns "implement" > > Yes. > > > Mounting the module violates the contract because the > > module clearly defines /system as a top-level node. > > No, mounting doesn't break the contract, since the contract (base > ietf-yang-library) doesn't mention these modules. > > > Any other location is non-compliant. > > I agree it would be non-compliant to list a mounted module in the base > ietf-yang-library. This is why mounted modules are not listed. > > OK -- good. > > > 3) If the answer to 2) is it can be mounted anywhere, which modules > must be > > > present at the top level? E.g. ietf-yang-library? > > > > > > > IMO the YANG contract only supports the data placement explicit > > in the module. > > Agreed. > > > > 4) If a new list entry is created can it introduce a completely new > module > > > never heard of before in the network element? > > > > > > > ?? > > > > this is fine for "anydata" > > > > > 5) IMHO allowing such dynamic introduction of new YANG modules into a > > > network element, with flexible mountpoints, flexible set of modules at > each > > > mountpoint, a flexible set of deviations and features for each mounted > > > module makes discovery actual available schema tree difficult. I think > we > > > are providing to much flexibility, over-complicating the issue. Some > more > > > static mounting solution that can be read from YANG modules instead of > > > run-time data would be easier. > > > > > > > mount is way over-engineered > > What do mean when you write "mount"? > > > but schema-defined mount-points don't really > > help. > > A nested "root" works and has a use-case. > > This is all the current schema mount does. > > This is the only variant I support. Renaming or relocating data (changing the ancestor path to the first root) is way too complicated and not relevant to a programmatic interface. This can be done in the presentation layer of the controller or application. > > Everything else is extra > > and an implementation choice without any real use-case. YANG is already > > complicated and slow. mount and sym-links makes it worse. > > > /martin > > > Andy > > > > > regards Balazs > > > > > > > > > > > > > Andy > > > > > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > Mobile: +36-70-330-7909 email: > [email protected] > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
