Hi, -----邮件原件----- 发件人: netmod [mailto:[email protected]] 代表 Acee Lindem (acee) 发送时间: 2015年8月28日 21:29 收件人: Martin Bjorklund 抄送: [email protected] 主题: Re: [netmod] Motivations for Structuring Models
On 8/28/15, 9:24 AM, "Martin Bjorklund" <[email protected]> wrote: >"Acee Lindem (acee)" <[email protected]> wrote: >> >> >> On 8/28/15, 8:55 AM, "netmod on behalf of Martin Bjorklund" >> <[email protected] on behalf of [email protected]> wrote: >> >> >Rob Shakir <[email protected]> wrote: >> >> >> >> Hi Martin, >> >> >> >> Thanks for the reply. >> >> > Martin Bjorklund <mailto:[email protected]> August 28, 2015 at >> >> > 02:33 So the idea is that this structure is defined in one >> >> > module, ietf-something-structure, right? >> >> > >> >> > And then different oam protocol modules augment this structure? >> >> > >> >> > How does this help you find the modules that augment this >>structure? >> >> Yes, this is the intention. By then generating the tree of the >>overall >> >> structure, then I can see what different containers are created >> >> there. It's not perfect (and hey, this suggestion is a *draft* for >> >> a reason - but yet again, there are not alternatives) - but the >> >> fact that the modules augment a common path adds some information >> >> that >>they >> >> are grouped to providing the same functionality, not disparate. >> >> ietf-routing does the same thing, it gives me the fact >>that >> >> at /routing/routing-instance/routing-protocols there are a bunch >> >> of control-plane protocols that are related to routing. >> > >> >Ok. So your proposal doesn't help with the problem of locating >> >relevant YANG modules, but once their located, it is easier to find >> >the ones related to a specific function, b/c they would augment a >> >common path. Is this what you mean? >> >> Why doesn’t it help? In the next revision of the Routing YANG DT >> model, we’ve switched from including specific models to defining >> classes of models with identities. For example, >> >> grouping oam-protocols { >> container oam-protocols { >> list oam-protocol { >> key "type"; >> leaf type { >> type identityref { >> base oam-protocol-type; >> } >> mandatory true; >> description >> "The Operations, Administration, and >> >> >> Maintenance (OAM) protocol type, e.g., BFD, >> >> >> TWAMP, CFM, etc."; >> } >> description >> "List of OAM protocols configured for a >> >> >> networking instance."; >> } >> description >> "Container for list of OAM protocols configured for a >> >> >> networking instance."; >> } >> description >> "Grouping for OAM protocols configured for a >> >> >> networking instance."; >> } >> >> >> Then the grouping is include the networking-instances. By doing >>this, the intent is that it would be evident as to where a particular >>model would be found. > >Now I am a user of YANG models. I am searching for the YANG module >that defines OAM for BFD. How does your model above help me find it? If one can envision a function to list the schema rather than the actual config data, you could retrieve the schema for the oam-protocols container. It would seem reasonable to support such a function. [Qin]: Sorry to chime in, To be honest, I think the above example gives a list of OAM protocol models we can identify and but doesn't provide relationship among these OAM related models, e.g., which model is a basic model, which model is extension to basic model. Figure 1 of draft-tissa-lime-yang-oam-model-06 provides such relationship just like what draft-ietf-netmod-routing-cfg-19 did, ietf-routing is a basic model, ietf-ipv4-unicast-routing and ietf-ipv6-unicast-routing are two example of model extension to ietf-routing. Thanks, Acee > > >/martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
