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. > > 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. > 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 > > 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
