Hi Balazs, Balazs Lengyel <[email protected]> writes:
> Hello, > > 1) Will mounted YANG modules be listed in the base ietf-yang-library? > Even the mounted ones? Currently, they aren't. However, I sent it as an open issue to the mailing list (no response so far): https://www.ietf.org/mail-archive/web/netmod/current/msg15737.html I do see a value in being able to determine the overall schema outside any management protocol context. > > 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? I think this would depend on whether the client supports schema mount or not. If it does, then it must iteratively construct the data model, and the conformance will then be relatively strict - unless we use anydata at a mount point. > > 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? It's not that any module can be mounted anywhere, the server specifies the schema. Yes, yang-library has to be present, then schema-mount module, and all modules listed at the top-level YANG library. > > 4) If a new list entry is created can it introduce a completely new > module never heard of before in the network element? I *think* that if the list is a mount point, then yes - a new instance of YANG library can be provided for the new entry. > > 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. I fully agree, that's why YSDL was much more conservative in this respect: all modules need to appear in the top-level YANG library, and there is just an extra specification of the hierarchical organisation of subschemas. Lada > > regards Balazs > > -- > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
