Hi Martin, Thank you for your reply. If module-A and modul-B are 1.0 modules, are they should be presented in <hello>?
-----邮件原件----- 发件人: Martin Bjorklund [mailto:[email protected]] 发送时间: 2017年11月7日 20:08 收件人: Zhuzhiguo <[email protected]> 抄送: [email protected]; Liquan (Liquan, NOS CSD) <[email protected]> 主题: Re: [netmod] (no subject) Zhuzhiguo <[email protected]> wrote: > Hi, > > I have one question about how to implement YANG module that import > other-module which is NOT be implemented? > > For example, module-A import module-B, but any nodes that depend on B > are not-supported > > Module A { > import module-B; > } > > There are two way to mark module-B is not really in use: > > Option-1: refer conformance-type in RFC 7895 (ietf-yang-library), mark > module-A as "implement", module-B is "import" This is correct. But if A augments some node in B, you have to implement B as well. -----////all these augments are deviated > This way seems work, but some teammates think it may not comply with > RFC. Why wouldn't it? ------////client can get module-B, but can't do any operation on module-B > And we also argue about what module-B should be presented in <hello> > > <capabilities> > <capability>module-A</capability> > <capability>module-B</capability> ===>should any "import" module MUST > be sent by server to client also? > <capabilities> Assuming A and B are YANG 1.1 modules, they should NOT be listed in <hello> - yang-library is used instead. > Option-2: mark module-B as "implement" also, but mark all-nodes as > deviated This way seems work also, but it will cause NETCONF-client > and NETCONF-server load module that have NO node that can be accessed There's no reason to do this. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
