Robert Wilton <[email protected]> wrote: > > > On 07/03/2017 17:03, Martin Bjorklund wrote: > > Robert Wilton <[email protected]> wrote: > >> in RFC 7950, The last paragraph, section 5.1.1 "Import and Include by > >> Revision" states: > >> > >> "If a module is not imported with a specific revision, it is undefined > >> which revision is used." > >> > >> But I was wondering if the above text is misleading, since section > >> 5.6.5: "Implementing a Module" has the following two paragraphs: > >> > >> If a server implements a module A that imports a module C without > >> specifying the revision date of module C and the server does not > >> implement C (e.g., if C only defines some typedefs), the server MUST > >> list module C in the "/modules-state/module" list from > >> "ietf-yang-library" [RFC7895 <https://tools.ietf.org/html/rfc7895>], > >> and it MUST set the leaf > >> "conformance-type" to "import" for this module. > >> > >> If a server lists a module C in the "/modules-state/module" list from > >> "ietf-yang-library" and there are other modules Ms listed that import > >> C without specifying the revision date of module C, the server MUST > >> use the definitions from the most recent revision of C listed for > >> modules Ms. > >> > >> The reason for these rules is that clients need to be able to know > >> the specific data model structure and types of all leafs and > >> leaf-lists implemented in a server. > >> > >> This seems to imply that import without specifying the revision would > >> mean that the latest revision listed in ietf-yang-library must be the > >> one that is imported. Is that correct, or am I misinterpreting the > >> text? > > This is correct. > > > >> Hence, should the last paragraph of section 5.1.1 be deleted? > > No I don't think it should. From the perspective of a given module > > that imports another module w/o revision, it is undefined which > > revision is used - however in any given server the revision used is > > deterministic. > I'm not sure what it really means for a YANG module to import another > module outside the context of a client/server, it seems somewhat > abstract.
It just means that the importing module has access to defintions in the imported module. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
